Child Item

Can't un-exclude directories with `dropbox.py exclude remove <directory>` on Ubuntu 20.04.2

I have a Linux machine (running Ubuntu 20.04.2 LTS, "Focal Fossa") upon which I am running a "headless" Dropbox daemon as per here: https://www.dropbox.com/install-linux

The Dropbox daemon is up to date:

```

$ dropbox.py version
Dropbox daemon version: 125.4.3474
Dropbox command-line interface version: 2020.03.04

```

This machine is truly "headless", so I am doing everything on the command line. Installation of the daemon and initial sync seemed to work fine, though autostart isn't working for me.

I've found that I can exclude directories with `dropbox.py exclude add <directory>` just fine. When I run that command for a directory in my Dropbox, the directory briefly appears in the list output from `dropbox.py exclude`. However, once the directory is actually deleted from the local Dropbox directory, it disappears from the list too. For example, I do have a bunch of directories excluded, and they are not present in the local Dropbox directory. However, the tool incorrectly reports no excluded directories:

```

$ dropbox.py exclude
No directories are being ignored.

```

This is fine, if a bit weird, but the problem is that I can't add excluded directories back (un-exclude them?) with `dropbox.py exclude remove <directory>`. That command outputs nothing and has no effect.

Why not? How can I get this to work? It seems totally broken right now.

Find more posts tagged with

Desktop

Sync

Insightful

Closed - Partially Delivered

Comments

Walter

Hey @caconym, thanks for using Dropbox and welcome aboard!

Since the app isn't behaving well when it comes to selective sync through the CLI, could you try re-installing it and let me know if it improved matters?

Regarding the option to auto-start the app, note that this command may only work on currently supported Ubuntu distributions.

Keep me posted with your results!

caconym

I tried a full reinstall (including removal of the entire Dropbox directory), and this time I didn't change any selective sync settings until the initial sync was finished, but I'm still having the same problem. I probably should have clarified that this is a relatively fresh and clean Ubuntu installation (of the latest LTS distro, compliant with the listed Dropbox requirements) and a totally fresh and clean "headless" Dropbox daemon installation (as of this afternoon an hour or two before I posted here):

```

$ cd ~ && wget -O - "https://www.dropbox.com/download?plat=lnx.x86_64" | tar xzf -

[...]

$ wget https://www.dropbox.com/download?dl=packages/dropbox.py

```

As I mentioned above, everything else seems to work, including the initial `dropbox.py exclude add <directory>`. It's worth noting that on my earlier installation `dropbox.py exclude` did show excluded directories until the daemon finished removing them; I tried to reproduce this after the second install, but this time I think the daemon was faster than me since it wasn't busy with sync tasks.

Since the last nautilus-dropbox release (of which the Python CLI script is a part) was over a year ago, I was wondering if some more recent change in the daemon might have broken compatibility, so I tried talking to the daemon's command socket directly using the "protocol" documented by the open-source CLI code. I was able to reproduce the same bad (or at least unexpected) behavior without running the CLI at all.

First, check the status of an existing, synced directory (with a file in it):

```

<redacted>@<redacted>:~/.dropbox$ nc -U command_socket
icon_overlay_file_status
path /home/<redacted>/Dropbox/test_dir_3
done
ok
status up to date
done

```

(Everything up to and including the first "done" is my input; the rest is the response from the socket, with the first line ("ok" in this case) being the overall response status.)

Next, add that directory to the ignore set:

```

ignore_set_add
paths /home/<redacted>/Dropbox/test_dir_3
done
ok
ignored /home/<redacted>/Dropbox/test_dir_3
unrecognized
done

```

The "ok" status is a good sign, and the "ignored" line indicates that the directory has been added to the ignore set. However, the daemon claims the ignore set is still empty:

```

get_ignore_set
done
ok
ignore_set
done

```

But the directory has been removed:

```

icon_overlay_file_status
path /home/<redacted>/Dropbox/test_dir_3
done
notok
The 'path' argument does not exist
done

```

`ls` in the shell confirms the same.

The command socket obviously isn't an officially documented API (confirmed by your team here), but all I'm doing here is imitating the commands the Python CLI sends to it. The socket is accepting these commands and giving sensible responses that match what I get when I use the CLI to do the same things (and don't return any error statuses), so my guess is that this is a bug in the daemon. A permissions or other configuration problem seems unlikely given that all the other features I've tested are working fine.

Walter

Thanks for keeping me in the loop on this one and sorry for the late reply @caconym.

If you're still having issues with this, may I reach out via email to investigate a bit further?

jwvjwvjwv

I'm also experiencing this exact same issue (and have been for the last couple months) on Fedora 34. Someone else has posted about it on stackoverflow as well. The only thing I've found that could reset my exclude list was removing the Dropbox application, the Dropbox daemon, and the nautilus extension. After reinstalling, all of my folders sync again, but once I exclude any of them again, I can't un-exclude them without uninstalling and reinstalling everything again.

caconym

Hey Walter, sorry I didn't see this until now. I'm happy to discuss the issue over email, DM, or whatever else.

SGuo

I can confirm, the exclude is useless at this point, the behavior is so random and this is so frustrating. When you add a folder to the exclude list, what dropbox seems to do, is to download that folder fully, and then delete it, and eventually, that folder's name will disappear from the exclude list out of no reason, even though it indeed is not being synced, and you can no longer sync that folder ever again without reinstalling the whole thing. Who invented this mechanism? He/she single-handedly wasted all these resources of network and time of ours.

linux000001

BUMP

I installed from source and experience the same issue.

@Walter...a DM doesn't help anyone else on this forum...you got some ideas share them.

cvmls

Same problem here, reinstall and update didn't solve anything.

Directly after excluding a folder and until the local deletion is complete, the command "exclude list" still shows those folders. After the operation is applied they are gone and there is no way to get them back.

drkivid

Same problem here.

Buckets

I'm also having this issue on Debian 10 and would love to know when a fix is available. Thanks!

linux000001

I'm a paying customer and contacted support. I informed them of this forum thread and the multiple users facing the same issue. I'll update everyone if I hear a resolution, but I hope Dropbox addresses the issue here.

UPDATE:

A couple weeks ago I got a reply back from Dropbox support saying:

"I've raised this with our engineering teams, and will be back in touch with any updates or information."

Well, 2 weeks later and still no update 😒

verpr

Just unlink your device in the https://www.dropbox.com/account/security and add them again in the system. It start sync again with all files (existing files won't be touched, just re-sync it). No need to re-install! (Then If needed you can again exclude some files/folders.)

linux000001

I would call this more a trivial hack than a solution. If I could down vote, I would.

verpr

Do you have simplier solution? Or even another one solution? Re-install system completely it's better?

I'm not defending developers, on the contrary, they are leave bad bug and still not fix! But thankfully we have one more solution than completely re-install OS.

hildenae

I just came over this problem on a new 20.04 installation, and the realised I have the same problem on a 18.04 installation I just reinstalled Dropbox on. My debugging says the same as other posts here - the daemon responds that there are no folders excluded

hildenae

Same problem with newest Dropbox Daemon
```
hildenae@ember ~/Dropbox $ dropbox exclude list No directories are being ignored.
hildenae@ember ~/Dropbox $ dropbox ls <empty>
hildenae@ember ~/Dropbox $ dropbox version Dropbox daemon version: 130.3.4940
Dropbox command-line interface version: 2020.03.04
hildenae@ember ~/Dropbox $
```

OneTokeOver

Same problem here running Ubuntu 20.04.3 via WSL2.

ReeceBenson

Same problem here, reinstall and the update didn't solve anything. The only thing I've found that could reset my exclude list was removing the Dropbox application, the Dropbox daemon, and the nautilus extension.
When you add a folder to the exclude list, what dropbox seems to do, is to download that folder fully, and then delete it, and eventually, that folder's name will disappear from the exclude list out of no reason,,, even though it indeed is not being synced, and you can no longer sync that folder ever again without reinstalling the whole thing.

Mark C.49

This bug is hitting me as well. The workaround to remove the device from your account, then add it back won't work for me. My currently exclude directories are large. I can't add them fully back to some of my devices. I need to selectively fine tune the exclude list. This has worked for years just fine for Dropbox. Something's broken which affects this API.

Please Dropbox, fix this regression.

sarke

Same issue here, very frustrating. We've been paying Business Team account for almost a decade.

@caconym, do you (or anyone else) know what the correct syntax is for ignore_set_remove on the command socket? Specifically the paths argument, is there a certain array/list format?

ignore_set_remove
paths   /opt/dropbox/Dropbox/somefolder
done
ok
removed
unrecognized    /opt/dropbox/Dropbox/somefolder
done

EDIT: So the paths are tab separated. ignore_set_add seems to work but not ignore_set_add.

sarke

Reverting to 123.4.4832 fixes the problem. It seems 124.4.4912 introduced the bug.

lassamaria

Thank you sarke! Reverting to 123.4.4832 fixed it for me. It's sad that Dropbox won't fix the bug they introduced at that point, but at least old versions are still available. No idea what new features were added after that version but they don't seem to be worth this serious bug.

iqvoice

I also have this problem. Would be nice to see a fix.

alanpaulkwan

How does one revert back to 123.4.4832?

Edit: This is a bit of a band-aid solution, but a workaround to this problem is just to use the GUI from Linux. However, I surmise Dropbox crashes on GUIs that don't support the Dropbox icon in the system tray (e.g. whatever the jazzy Ubuntu 20 default is) but works fine on XCFE.

So I launched a VNC session, which on my machine defaults to xcfe (which is compatible). And the GUI permits you full visibility into your folders.

HallwaySail

I'm having the same issue:

```

Dropbox daemon version: 132.4.3800

Dropbox command-line interface version: 2020.03.04

```

I've followed the advanced reinstall instructions and even tried setting up a new machine with the same result every time. This is having a major ongoing impact on our business.

jwvjwvjwv

I got fed up waiting for anything to come of this thread and contacted Dropbox support (which maybe I should have done all along... I thought they monitored the forums). This will probably get resolved sooner if more of us contact support: https://www.dropbox.com/support/email

jwvjwvjwv

Update from support: Lucky us! We're low priority!

October 14, 2021, 10:12 AM PDT:
We have received a word back from the engineers and they have informed that this is a known issue which is currently being investigated by their team.
It has been set to low priority from the team so it may take a while for it to be fixed. We apologise for any inconvenience.

linux000001

It's literally the only thing I can observe that is broken! Otherwise, Dropbox is working as expected. Now I'm sure there's other fish to fry, but how does something that is so obvious get pushed to "low priority"? It's like driving w/ a flat tire...sure you'll get from A to B but boy would it be better if you had a new stereo system!

JuhaPalomaki

Funny - I was just last week wondering how I had managed to setup the selective sync on one of my Linux machines without using the exclusion list. As the list was empty, I was assuming it was not in use.

Now I hit the problem on another machine as well. The main problem is that this also seems to make it impossible to remove folders form the exclusion lists.

I'm a bit surprised this kind of regression is labeled as "low priority". This file syncing stuff is kind of key feature of the product. Re-installation etc. are not a cool workaround when you have some hundreds of thousands of files.

cf_0001

Very frustrating. I have paid for many years.