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.

[profkruse]

Same here - the max_user_watches setting on my Linux Mint was 8192 "out of the box", I have 128k files on Dropbox - a bit of a mismatch.  Set it to 250,000 for now and Dropbox resumed syncing.

[profkruse]

Btw, the way I set up that change consistent with the design of Debian config files is to create a file "local.conf" in /etc/sysctl.d with the content "fs.inotify.max_user_watches=250000". Something like 

sudo echo "fs.inotify.max_user_watches=250000" >> /etc/sysctl.d/local.conf

should do the trick. (Or sudo to root and use your favorite editor, which is what I did).

[rwalker1501]

Hi, thank you so much for the very clear, systematic answer. It was a life-saver!

I went through your suggestions in order until I found the solution. In my case it was the number of watched files that was wrong - I had a max limit of 8000, when I needed 250000. The horrible side-effect was that random changes on my disk (even outside the dropbox folder) caused (or sometimes caused) dropbox to go into the forever sync loop. Upping the limit on watched files resolved the problem. 

A suggestion: your recipe was perfect - but it required your expert knowledge.  Most of us could never have worked it out for ourselves. It would be wonderful if you could write a short description of the way Dropbox interacts with Linux and the linux file system (files locations, permissions needed,  reasons why particular parameter settings affect performance). That way we could form our own mental model of the system and avoid some of the frustration.

A hint for dropbox technical support: a lot of user problems are not  due to Dropbox technology (which many of us love) but to lack of clear documentation. Note: we don't just want recipes to resolve problems. We want explanations and diagrams so we can understand the root cause of the difficulties we are experiencing.

[MartinHeroux]

I tried the second step looking for symbolic links

ls -alR ~/Dropbox | grep " -> "

And inded there were several symbolic links.

In fact, when I tried to run

sudo chattr -R -i "$HOME/Dropbox"

this is why I got a bunch of errors like this:

chattr: Operation not supported while reading flags on [...]

Does this mean I need to somehow remove these symbolic links in order to get my Dropbox synching unstuck on my Linux machine?

If so, how does one do this, and how do I do it without breaking stuff?

For a bit of context, most of my symbolic links are associated with Python env. For example:

$ ls -alR ~/Dropbox | grep " -> "
lrwxrwxrwx 1 martin martin    3 Oct 27 14:48 lib64 -> lib
lrwxrwxrwx 1 martin martin    9 Oct 27 14:48 python -> python3.8
lrwxrwxrwx 1 martin martin    9 Oct 27 14:48 python3 -> python3.8

Any assistance with this would be appreciated.

[Здравко]

---

@MartinHeroux wrote:

...

this is why I got a bunch of errors like this:

chattr: Operation not supported while reading flags on [...]

Does this mean I need to somehow remove these symbolic links in order to get my Dropbox synching unstuck on my Linux machine?

...

---

Hi @MartinHeroux,

Not actually. If the other 2 line in same code block are working without errors, no problem:

sudo chown -R "$USER" "$HOME/Dropbox"
chmod -R u+rw ~/Dropbox

It's important no any link points to a place outside Dropbox folder, which seems covered by your examples (have to be for all).

What about possible unwatched entries? Did you check that? Alternatively you can use something like:

db_path=`jq -r '.personal.path' ~/.dropbox/info.json`; echo -n "Your Dropbox folder $db_path entries approximate count is "; tree -a "$db_path" | wc -l; sysctl fs.inotify.max_user_watches

What's the result? 🤔 The actual entries count should fits in the border (maximum)!

If need, give some time to the entries not in sync yet. Is there some 'move' in result of:

dropbox status

🤔

And finally, is there some "deviation" in the result of:

(IFS=$'\n';for i in `ls -R1 $(jq -r '.personal.path' ~/.dropbox/info.json)`; do if [[ "$i" =~ ":" ]]; then cd `echo "$i" | sed "y/:/\//"`; echo -n "In folder: "; pwd; dropbox filestatus; fi; done) | grep -vi "up to date" | grep -vi ".dropbox:" | grep -vi ".dropbox.cache:"

🤔

[MartinHeroux]

Dear Здравко,

Thank you for the quick reply and for helping us linux folks with Dropbox issues.

I went over your previous instructions:

If no any change, check the needs for watchable entries:

i=0; IFS=$'\n'; for a in `ls -R1 ~/Dropbox`; do ((++i)); done; echo $i

The above will give you some estimation. The current upper border could be received using:

sysctl fs.inotify.max_user_watches

If the estimation above don't fit in last result, try extend the border using something like:

sudo sysctl -w fs.inotify.max_user_watches=100000

I mis-read what was the estimate and what was the upper border.

I did indead have an issue here. I changed the max_user_watches and upon a restart my Dropbox synched everything!

Thank you for the various things to try, and for providing me with what in the end solved my issues.

Incidently, some of the symbolic links do point outside of dropbox, but that does not seem to be a problem as everything synched fine after I fixed the max_user_watces limit.

[Здравко]

---

@MartinHeroux wrote:.

...

Incidently, some of the symbolic links do point outside of dropbox, but that does not seem to be a problem as everything synched fine after I fixed the max_user_watces limit.

---

Be careful, @MartinHeroux!

Such links get in sync, but the content they point to not. ☝️ If this is not a problem... 😦 Ok.

[donvercety]

Hello did have the same problem.

Than I ran manually the dropbox daemon "dropboxd" located at "/.dropbox-dist" and saw that error: "Unable to monitor entire Dropbox folder hierarchy. Please run "echo fs.inotify.max_user_watches=100000 | sudo tee -a /etc/sysctl.conf; sudo sysctl -p" and restart Dropbox to fix the problem."

Just run the command and all works fwallesly!

P.S. it loud be great to show this error on the GUI side of the dropbox program, some users don't use the terminal.

[Mace68]

i=0; IFS=$'\n'; for a in `ls -R1 ~/Dropbox`; do ((++i)); done; echo $i

This gave me a value of 36784

sysctl fs.inotify.max_user_watches

This value was set to 8192. Way too low looking at the value needed above.

sudo sysctl -w fs.inotify.max_user_watches=100000 

Setting it to 100000 allowed my Dropbox to successfully start syncing immediately when i restarted it.

Thanks very much for this solution!

[DokterChaos]

For years I've been trying to get this to work on Debian. Maybe at some point the dropbox headless deamon worked on Debian, now not anymore. I've connected an account with only 1500 files and 2GB of data. On Debian I can copy new files to the Dropbox folder and they will sync, but Dropbox will not download new files that are added to the account.

Permissions are correct. Maximum watched files is at 8000. I've spent too much time trying to install the dropbox daemon as a system service, hoping I could get it to write  to the syslog. I simply can't get it working on Debian. 

This guide just gives me a dead service: 

https://www.jamescoyle.net/how-to/1147-setup-headless-dropbox-sync-client

This guide gets me stuck on the fact Debian doesn't have "/etc/rc.d/init.d/functions", and also there is no "/etc/sysconfig" folder.

https://www.techrepublic.com/article/how-to-install-and-run-dropbox-from-a-headless-linux-server/

(IFS=$'\n';for i in `ls -R1 ~/Dropbox`; do if [[ "$i" =~ ":" ]]; then cd `echo "$i" | sed "y/:/\//"`; echo -n "In folder: "; pwd; dropbox filestatus; fi; done) | grep -vi "up to date" | grep -vi ".dropbox:" | grep -vi ".dropbox.cache:"

this won't run because "dropbox" isn't a valid command on my Debian install. 

---

@Здравко wrote:

Hi @holf,

At the beginning you can try fix possible permission errors:

sudo chown -R "$USER" "$HOME/Dropbox"
sudo chattr -R -i "$HOME/Dropbox"
chmod -R u+rw ~/Dropbox

Also, existing symbolic links could be found using:

ls -alR ~/Dropbox | grep " -> "

If no any change, check the needs for watchable entries:

i=0; IFS=$'\n'; for a in `ls -R1 ~/Dropbox`; do ((++i)); done; echo $i

The above will give you some estimation. The current upper border could be received using:

sysctl fs.inotify.max_user_watches

If the estimation above don't fit in last result, try extend the border using something like:

sudo sysctl -w fs.inotify.max_user_watches=100000

Tune the value according your needs (with some reserve, of course).

If nothing helps yet, try to find out the exact files making troubles (which will give you chance investigate further), using something like:

(IFS=$'\n';for i in `ls -R1 ~/Dropbox`; do if [[ "$i" =~ ":" ]]; then cd `echo "$i" | sed "y/:/\//"`; echo -n "In folder: "; pwd; dropbox filestatus; fi; done) | grep -vi "up to date" | grep -vi ".dropbox:" | grep -vi ".dropbox.cache:"

Last command assume you have installed properly 'dropbox' command, either using debian package or by hand. Otherwise "command not found" will be signaled. Will be enumerated all folders in Dropbox and signaled problematic files inside, if any. Be patient, could take some time, depending on your content size. Once found out problematic entries, you can use different techniques for investigate, like see current file's classic attributes (the simplest one):

ls -l ~/Dropbox/Troublesome/file.ext

Good luck.

---