Child Item

dropbox filestatus unwatched for all files in Dropbox directory

Ubuntu 19.10
Dropbox daemon version: 93.4.273
Dropbox command-line interface version: 2020.03.04

Dropbox is keeping up to date -- up and down. But file status reports as unwatched

$ /home/stephen/Dropbox: dropbox filestatus
.dropbox:                    unwatched
.dropbox.cache:              unwatched
.metadata:                   unwatched
20190904_173012.jpg:         unwatched
20190904_173020.jpg:         unwatched
20190904_173025.jpg:         unwatched
...
and so on for all files/folders in directory

I have restarted Dropbox, restarted device...

What's up?

Find more posts tagged with

Desktop

Insightful

Accepted answers

Здравко

Hi @Stephen B.25,

In you particular case symlink or binding - doesn't matter. The issue comes from the fact that the Dropbox daemon make a literal comparison between queried path and watched files/folders path, not inode comparison! That's why, even the same, a file could be shown with different status because beginning of the path is different. :nerd:

If you want to, can try mount a partition, you use in your home and move Dropbox folder there, if is more convenient for you. Be very careful, in such move! Take care not to left Dropbox application without available actual Dropbox folder place, even for a moment; this can lead to data loss!

Good luck.

All comments

Здравко

At the beginning, is Dropbox application running? :thinking:

What is the result from:

dropbox status

Try:

dropbox start

Stephen B.25

Dropbox status is "Up to date"

System restarted. Dropbox restarted. No change.

Здравко

Hi @Stephen B.25,

What's the result from:

cat ~/.dropbox/info.json; echo

Is the resulting Dropbox folder matching?

Stephen B.25

<SSH>stephen@acer:~/Dropbox$ cat ~/.dropbox/info.json;echo
{"personal": {"path": "/mnt/3T/acer.dropbox/Dropbox", "host": 61868442032, "is_team": false, "subscription_type": "Pro"}}

/mnt/3T is the second HDD in the system. System is a SSD with limited space.

/mnt/3T/acer.dropbox/Dropbox is then bind mounted to /home/stephen

Здравко

Aha... And what's the result from:

cd /mnt/3T/acer.dropbox/Dropbox
dropbox filestatus

Meanwhile, ".dropbox.cache" is permanently unwatched. This is hardcoded in the Dropbox application. You can't change this! Actually you can, but on next launch, the application will force the ignoraning again, this is the application local cache.

Stephen B.25

Ah! The filestatus from the original directory /mnt/3T/acer.dropbox/Dropbox reports 'up to date' -- as expected.

So ... good enough.

Would it be better to symlink rather than bind mount?

ln -sf /mnt/3T/acer.dropbox/Dropbox /home/stephen

I may have already tried that because that would be my first try. The bind would not be the first try but perhaps I had some other issue at the time I was installing.

Здравко

Hi @Stephen B.25,

Good luck.

Stephen B.25

I'm okay with things as they are so I'll just leave it now that I understand.

Thanks for your help.

jbiskofski

Hey, Ive been struggling with this for a few days. I think I finally found the solution,

In my case, this is what fixed the problem.

1. Quit Dropbox completely

2. manually run dropbox inside a terminal : ~/.dropbox-dist/dropboxd

3. when running it like this, you can see some additional errors. in my case it said, my dropbox had so many files, i was exceeding the inotify watch limit, and even gave me the exact command I needed to run to increase this limit: echo fs.inotify.max_user_watches=100000 | sudo tee -a /etc/sysctl.conf; sudo sysctl -p

4. Restart dropbox

Здравко

Hi @jbiskofski,

All right, since you have find out a solution working for you. Symptoms in your case are slightly different, for sure. 🧐 Your case is different, definitely, so don't mess them!

Good luck! 😉

netmarine

Ok I'm experiencing this same issue. running cat ~/.dropbox/info.json; echo results in

{"personal": {"path": "/persist/Dropbox", "host": 67560646000, "is_team": false, "subscription_type": "Pro"}}

If I cd to /persist/Dropbox and run dropbox filestatus

I get that everything is unwatched.

I have also run ~/.dropbox-dist/dropboxd in a terminal and have added the line fs.inotify.max_user_watches=10000 to /etc/sysctl.conf

and then ran sysctl -p.

This does not change the result of running dropbox filestatus from the root of local Dropbox tree. Which I don't really care about,, the problem is that any new files or directories I create on this system do not get sync'd up with the cloud or my other devices.

Здравко

Hi @netmarine,

Are you sure that the watches number is enough? How many files have you in your Dropbox folder? You can try the following to check If your selection is fine:

 echo -n "Your Dropbox folder entries approximate count is "; tree -a "/persist/Dropbox" | wc -l; sysctl fs.inotify.max_user_watches

What's the result? You may need install "tree", If not yet.

netmarine

So your suggesting that the watches value should exceed the number of files I have in Dropbox? Yeah, I'm certain it's several million. roughtly 334 GB of a huge mix of file types including a large volume of source code.

netmarine

You know what? I upped the watches to 10,000,000 and restarted Dropbox and a little while later I ran dropbox filestatus in the root of the Dropbox directory and I got good results, some directories are syncing and some are up to date. Thanks for your help.

bfmaier

This worked for me too. It's kinda mind-boggling that this number is so low per default and that the App doesn't tell you what's going on when you hit the limit and instead just "unwatches" all files and remain in "syncing" forever. @Dropbox, you should at least address that in the FAQ for Linux.

Здравко

@bfmaier wrote:
... It's kinda mind-boggling that this number is so low per default and that the App doesn't tell you what's going on when you hit the limit and instead just "unwatches" all files and remain in "syncing" forever. ...

Hi @bfmaier,

I agree that Dropbox application should tell user what's going on in more details when any error happens. Hitting the watches limit is only one of many such cases, unfortunately. 🤦 Proper information for any unwanted events (including logs availability) is a pain for Dropbox.

About the per process watches number, it's not so low. They're used to monitor eventual changes in configuration files, files that the application currently use, etc. Such a mechanism is NOT designated for syncing (generally); Dropbox use them rather as something like workaround, unfortunately. There are much better ways and Dropbox refuses to use them (don't ask me why). The same mechanism (with watches) can be used for syncing too, but as a distributed system for large entries number (something Dropbox application doesn't do).

Let's hope Dropbox designers will improve their system stricture at some point (but better don't relay on).

bfmaier

Interesting, thank you for these insights!