Syncing is stuck on my Linux devices, what can I do?

[holf]

It seems I have the same problem as mentioned in above posts. I am running Dropbox on a pc and laptop, both having Linux-Lubuntu as the os. After a "one time update" on both systems, Dropbox is stuck indexing/uploading/downloading a small number of files. In addition, I noticed that when I rename a file on my hard disk, the name of that file is not always changed in the cloud. I tried the two fix options and did a complete reinstall of the dropbox client, but no success. I would appreciate any help.

[Jaidan B.]

Thanks for your help @Здравко 

"dropbox stop; dropbox start". makes no change.

I have found the files in the web browser that do not appear in the local PC. I think these are the 83 missing files. I have tried copying and renaming and even downloading. COpy and rename just adds to the "Downloading" count. If I download manually and place in the correct directory, it has a sync conflict yet the original file cannot be seen.

How can I heck the files in the web browser for the reason they are not syncing?

[Здравко]

Hi @Jaidan B.,

Hmm... 🤔 That sounds like you have triggered some bug. It's known that Dropbox application isn't the most stable one. 🤷

Try to workaround by downloading missing files while the application is off. In  addition you can clear the cache. Start with following in terminal:

dropbox stop
rm -rf ~/Dropbox/.dropbox.cache

Above command points to default Dropbox folder place. If you have moved it somewhere else replace tilde (~) to the actual path. Now try to download missing files into proper directories using your web browser. At the end, run Dropbox application anew using:

dropbox start

Is everything Ok now? 🧐

[Jaidan B.]

Sorry about the multiple posts - it marked them as spam when I first posted them. It looks like that has been fixed.

Thanks again @Здравко for your ideas. They are clever ones. I chose 3 files which were missing. I stopped dropbox. Cleared the cache. Checked with `dropbox status` and then downloaded the files to the correct location. They looked like they copied correctly.

Then I started Dropbox. Dropbox renamed the 3 files as conflicted copies. The original files are still not there and Dropbox now says "Uploading 3 files, downloading 87 files". It is stuck again. The 3 new conflicts appear in the web browser also.

When I deleted the three new conflicts form the web browser, they deleted from my PC. Still stuck at "Uploading 3, downloading 87".

This is really puzzling. Do you have more ideas please?

[Здравко]

Hah.. 🤷 Really puzzling!

Ok, try off repeat the same as above, but just before starting Dropbox application anew remove all already copied to local Dropbox folder files from Dropbox online using your browser. Let's hope when  there is only one copy to sync (from local to online), won't be any conflict condition.

Let's see...

[Jaidan B.]

This is bizarre. I tried as you said and yes that worked however, the number of "Downloding files" did not reduce by the missing number of files I moved across. It was less, but it still reduced.

Interestingly, if I download from web, then delete from web, the "Downloading X files" reduces a little. When I then copy the downloaded files into the local copy, it syncs perfectly.

This will work for me for now however, I won't know if I will stop all stuck downloading files until I make my way through everything. Some folders have 800 photos in them so checking line by line will take some time.

Thanks for your help @Здравко .

Do you know what the correct way to report this behavior to Dropbox would be?

Oh and an interesting thing, when I download multiple files from the web, the zip file contains a folder called __MACOSX and files with ._ as the second and third letters. These aren't shown in my Dropbox folder or in the web view.

[Здравко]

Hi @Jaidan B.,

All Dropbox moderators are able to see our conversation and forward to development if they decide to. The only more thing you can try open a support ticket, but... don't rely too much. 🤷 There are almost same persons. Do as you decide.

Dropbox folder ZIP compression isn't consistent and that's why you should be careful! The bug was signaled multiple times, but seems this isn't a Dropbox priority. It's so for years, so don't rely for this also. All actual files are compressed and exist properly, but folder structure does NOT match reliably the real one! May be different "distortions", starting from misscapitalization up to parallel folders structure, as well as the note by you and so on.

Let's hope someday all this will get fixed.

PS: By the way, why are you checking line by line:

---

@Jaidan B. wrote:

... Some folders have 800 photos in them so checking line by line will take some time.

...

---

You can filter the `dropbox filestatus` output for the particular folder and... 🤷 it's ready. 😉 (as I have done in my script above)

Another way to check for missing entries in particular folder is using a single line script like:

VAR=`curl -X POST https://api.dropboxapi.com/2/files/list_folder --header 'Authorization: Bearer <your token>' --header 'Content-Type: application/json' --data '{"path":"<path realtive to Dropbox>"}'`; for i in $(seq 0 $((`echo $VAR | jq -r '.entries | length'`-1))); do E=`echo $VAR | jq -r '.entries['$i'].name'`; if [[ -f "$E" || -d "$E" ]]; then echo "E->$E"; else echo "M->$E"; fi; done

To use above script you have to take a short time token from Dropbox API Explorer for example. Click "Get Token" button there and replace <your token> above to the actual token. Get in folder you want to check (i.e. the folder have to be PWD). Replace <path relative to Dropbox> to ... that value (i.e. if you have a folder like "~/Dropbox/My folder" between the quote above should be "/My folder"). All existing entries on the server folder will be listed and prepend with "E->" (i.e. Exists) when particular entry exists locally in PWD or prepend with "M->" (i.e. Missing) otherwise. 🙂

[barefootcoder]

> The only more thing you can try open a support ticket, but... don't rely too much.

Good advice.  Before I found this thread and solved my own problem, I had Dropbox "support" close my ticket 4 times without ever coming remotely close to solving my problem.  They should be paying Здравко; they'd solve more issues.

[cnelsonak]

I had this same issue with my Linux Dropbox (Dropbox daemon version: 144.4.4491, Dropbox command-line interface version: 2020.03.04). Certain files in Linux would not show up even though they were available online and on other computers. Trying to copy them did not resolve and trying to recreate them would cause sync errors. Only downloading, removing from online, and re-uploading seemed to fix. I tried all the other remediation steps (max_user_watches; rm .dropbox folder; complete reinstall) without any luck.

In the end, this post helped me identify the culprit -- all the files in question had a __MACOSX folder when I downloaded and I realized that they were synced from a very old Mac computer. So, I dusted it off and checked the files for extended attributes, and all of the files that were not syncing had a com.apple.ResourceFork as an extended attribute. If I removed the ResourceFork attribute, the file would immediately sync and appear on the Linux Dropbox folder. Since I was missing 3K+ files, I decided to bulk remove the attribute for the entire Dropbox directory and now all my files are showing up again on the Linux workstation. The only downside to removing the attribute this way (using xattr -d) was that it updated the timestamps.

I hope this helps anyone who has this odd issue. It appears that there is a bug or incompatibility between the Linux client and the old Mac ResourceFork file attribute.

[Jaidan B.]

Good find! Come to think of it, all the files I had that were stuck syncing were on an old iBook. Hopefully Dropbox can use this info to provide a permanent fix.

[Walter]

Hi all - I'm sorry for the late response here. Are you still having issues with this?

If you do, note that files won't sync if the device's filesystem does not support the particular xattr (size) or if doesn't support xattrs at all. 

You can take a look at this page for additional details on xattr limitations on Linux filesystems. 

I hope this helps!