Been using my Dropbox account for years on a Lubuntu system. Now, my new company has made a Business account available to me.

However, Dropbox insists that this folder should be called:

~/Dropbox (firm-name)/

And there seems to be no way of changing it. I'm by no means a linux or cli expert, but one thing is renaming all my different absolute paths to something else, that's a one-time effort, but another thing is renaming it into something else with spaces. I'm foreseeing a lot of minor annoyance in my workflow if all filepaths I use suddenly includes a space by default.

So one possible way around this is to either symlink or mount --bind the ~/Dropbox (firm-name)/ as ~/Dropbox/.

This question seems to be concerning the same issue, and suggests using mount to bind the directory. by doing that, I would:

sudo mount --bind '~/Dropbox (firm-name)/' ~/Dropbox/

And then put it in /etc/fstab so it doesn't disappear when rebooting.

However, I'm basically unsure of wether that is a very bad idea that will lead to all sorts of issues. I don't understand the mount command well enough to feel comfortable using it for something so important as this without guidance.

Symlinks in dropbox have worked fine for me when placing a symlink outside dropbox pointing to a file or folder in Dropbox, but symlinks inside the Dropbox folder has led to issues in the past, that seems to have changed, however. This use-case is different, in the sense it is the entire dropbox folder that should be synced, like so:

ln -s '~/Dropbox (firm-name)' '~/Dropbox'

So I'm asking: what -if any - is a safe, reliable way of linking ~/Dropbox (firm-name)/ to ~/Dropbox/? It seems like a mount --bind or a symlink are the two best possibilites, but even though I've read about the differences, I don't know which of the two I should choose for this scenario. Is it even possible to do in a reliable way, or should I just pay up for my own account (seems so redundant though!). the symlink-way seems to have worked for this guy, but it's not a very detailed answer and I'm afraid of the unforeseen consequences and the loss of data and work.

note: It could be argued that the question I link to is the same question, but the original author never accepted the only answer. Also, there are some differences in his circumstances with a headless server, and being not an advanced user, although I've been using linux for years, I don't know if our premises are the same. I will argue less advanced users would benefit from a question and answer to this that had a very basic use-case premise.

  • At the moment it doesn't answer your question, but I suggest you use the FOSS Maestral instead of the Dropbox official client. See Maestral#347 for your issue Apr 1 '21 at 8:27

Both ways are safe (personally, I prefer and use the bind mount alternative). There are a few minor differences, which may or may not be relevant to you:

  • By default, file indexers (e.g. updatedb) tend to skip symbolic links and not to skip bind mounts. E.g. if ~/Dropbox is a symlink, locate a_file_in_Dropbox would find the file in ~/Dropbox (firm-name)/ only; it will instead find the file in both ~/Dropbox (firm-name)/ and ~/Dropbox if ~/Dropbox is a mount point.

  • Other programs may as well slightly change their behavior when operating on symlinks. A bind mount is more likely to ensure a seamless experience.

  • In the bind mount case, failing to mount ~/Dropbox (firm-name)/ to ~/Dropbox may cause processes to write files in the ~/Dropbox directory (the mount point), and not, as intended, in ~/Dropbox (firm-name)/. On the contrary, writing something in a broken symbolic link will just fail with an error.

My advice is to create the /home/your_user/Dropbox directory and add

/home/your_user/Dropbox\040(firm-name) /home/your_user/Dropbox none bind 0 0

to /etc/fstab. (It will be mounted on next boot or by running sudo mount --all).

Given that, in fstab, spaces and tabs are used to separate fields, literal spaces and tabs in mount points — and, where appropriate, as in the case of bind mounts, also in the first field — have to be replaced with the \040 and \011 escape sequences respectively.

Note that the tilde (which is not special as a path) is only expanded by your shell if unquoted. The command:

ln -s '~/Dropbox (firm-name)' '~/Dropbox'

tries to create a symbolic link named Dropbox in a directory (literally) named ~, located in the current working directory (which is unlikely to exist, causing an error). And that link will point to a file named Dropbox (firm-name) locate inside that same ~ directory.
It should be:

ln -s ~/'Dropbox (firm-name)' ~/Dropbox
  • I will try mounting, and see how it goes, and approve your answer as the right one if it works- could take a little time, however, need to test it properly. thank you for the correction about the symlinks.
    – emilBeBri
    Apr 7 '21 at 9:42
  • I just did it and will report back with results. Note however on a Lubuntu 20.04 machine you can't use quotes in fstab and get the space understood properly as a space. You need to use \40 instead like so: /home/your_user/Dropbox\40(firm-name) This is the exact reason why want to do this to begin with, to avoid all the bullsh*t with spaces :D superuser.com/questions/527495/…
    – emilBeBri
    Apr 12 '21 at 10:19
  • @emilBeBri Right, thanks. Answer fixed.
    – fra-san
    Apr 12 '21 at 10:53
  • it is working without issues so far, in a dropbox with ~ 75 GB and symlinks pointing into the "mount bind" folder (though haven't tried the othe way around)
    – emilBeBri
    May 4 '21 at 10:48
  • Symlinks placed outside a Dropbox directory and pointing to files (and directories) inside a Dropbox directory are safe. To minimize headaches, my advice is to just avoid symlinks placed inside a Dropbox directory, regardless of what they point to. Being designed to sync between incompatible operating systems, Dropbox can't easily preserve every kind of file (not just symlinks: think about FIFOs, block/character special files, sockets).
    – fra-san
    May 4 '21 at 17:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.