Linux... move the Dropbox Folder

[MHBoise]

I have been looking but not finding anything... can anyone point me in the right direction for moving the Dropbox folder?  I have Ubuntu Server (no Gui) installed and the Dropbox folder (and the two symlinks Dropbox Business created) is located in the home directory.  My data is in another directory (seperate hard drive) called Shares.  With the receint Dropbox update The symlink I created no longer work and I am dead in the water... Everything I do must be via Command Line... 

[cipherguru]

I believe the example does not work anymore.

In more details, I had some folders in my dropbox linked via mount -o bind. These stopped syncing sometime in Feb 2020. The client now does not sync files in those folders and the command line tells me `<filename>: unsyncable` for every such file.

I tried running the script as-is (after the fix mentioned in the original post).. however situation is same. Does this not work anymore?

Are there other alternatives to dropbox that work on ubuntu and dont have this illogical bug. 

[Здравко]

Hi @cipherguru,

I have no idea what exactly you are doing, but I can show you what's going on in my case. "Workaround" script is installed and Dropbox runs. Follows some commands executed exactly in sequence (and the corresponding results):

$ mkdir ~/ATestDir ~/Dropbox/ATestDir
$ echo "Just some text for test. ;)" > ~/ATestDir/test.txt
$ ls -l ~/ATestDir
> общо 12
> -rw-r--r-- 1 zdravko zdravko 28 мар 11 15:30 test.txt
$ ls -l ~/Dropbox/ATestDir
> общо 0
$ sudo mount --bind ~/ATestDir ~/Dropbox/ATestDir
$ ls -l ~/Dropbox/ATestDir
> общо 12
> -rw-r--r-- 1 zdravko zdravko 28 мар 11 15:30 test.txt
$ dropbox filestatus ~/Dropbox/ATestDir/test.txt 
> /home/zdravko/Dropbox/ATestDir/test.txt: up to date

Is this not working?! i.e. a file created and existing outside Dropbox directory (file test.txt in "~/ATestDir" in particular) is mapped to and in sync in the Dropbox directory ("~/Dropbox/ATestDir" in particular), very similarly to a symbolic link. Review what you are doing! The only thing which have to be corrected is the forum bug (I emphasize here "FORUM") related to one variable name (which you declare done). That's it, nothing more.

Good luck.

[cipherguru]

I'm unable to use this from outside the home folder

tim@hn:~$ mkdir ~/BTest ~/Dropbox/BTest
tim@hn:~$ echo "Just some text for test" > ~/BTest/test.txt
tim@hn:~$ sudo mount --bind ~/BTest ~/Dropbox/BTest
tim@hn:~$ dropbox filestatus ~/Dropbox/BTest/test.txt
/home/tim/Dropbox/BTest/test.txt: up to date

tim@hn:~$ mkdir ~/CTest ~/Dropbox/CTest ~/DTest
tim@hn:~$ echo "Just some text for test" > ~/DTest/test.txt
tim@hn:~$ sudo mount --bind ~/DTest ~/CTest
tim@hn:~$ sudo mount --bind ~/CTest ~/Dropbox/CTest
tim@hn:~$ dropbox filestatus ~/Dropbox/CTest/test.txt
/home/tim/Dropbox/CTest/test.txt: up to date

tim@hn:~$ mkdir ~/ETest ~/Dropbox/ETest /mnt/74bcf733-f29b-42db-bedd-1882056fb822/FTest
tim@hn:~$ echo "Just some text for test" > /mnt/74bcf733-f29b-42db-bedd-1882056fb822/FTest/test.txt
tim@hn:~$ sudo mount --bind /mnt/74bcf733-f29b-42db-bedd-1882056fb822/FTest ~/ETest
tim@hn:~$ sudo mount --bind ~/ETest ~/Dropbox/ETest
tim@hn:~$ dropbox filestatus ~/Dropbox/ETest/test.txt
/home/tim/Dropbox/ETest/test.txt: unsyncable

tim@hn:~$ mkdir ~/Dropbox/GTest /mnt/74bcf733-f29b-42db-bedd-1882056fb822/GTest
tim@hn:~$ echo "Just some text for test" > /mnt/74bcf733-f29b-42db-bedd-1882056fb822/GTest/test.txt
tim@hn:~$ sudo mount --bind /mnt/74bcf733-f29b-42db-bedd-1882056fb822/GTest ~/Dropbox/GTest
tim@hn:~$ dropbox filestatus ~/Dropbox/GTest/test.txt
/home/tim/Dropbox/GTest/test.txt: unsyncable

[Здравко]

What are these intermediate mount point for (i.e. "~/CTest" and "~/ETest" in your examples)? They are meaningless. Only increases the load to some extent, nothing more. Are you sure the owning and access rights are set as needed on the other storages (i.e. to you)? I can't see a result from commands like:

ls -al /mnt/74bcf733-f29b-42db-bedd-1882056fb822/FTest
ls -al /mnt/74bcf733-f29b-42db-bedd-1882056fb822/GTest

And to be sure what exactly gets mapped, check too:

ls -al ~/Dropbox/ETest
ls -al ~/Dropbox/GTest

[cipherguru]

Here is the info you need plus a bit more.. hope some clue here. Intermediate mount points to show that nested bind mount works in certain cases and not others.

tim@hn:~$ ls -al /mnt/74bcf733-f29b-42db-bedd-1882056fb822/FTest
total 12
drwxrwxr-x  2 tim tim 4096 Mar 12 01:24 .
drwx------ 22 tim tim 4096 Mar 12 01:25 ..
-rw-rw-r--  1 tim tim   24 Mar 12 02:07 test.txt

tim@hn:~$ ls -al /mnt/74bcf733-f29b-42db-bedd-1882056fb822/GTest
total 12
drwxrwxr-x  2 tim tim 4096 Mar 12 01:25 .
drwx------ 22 tim tim 4096 Mar 12 01:25 ..
-rw-rw-r--  1 tim tim   24 Mar 12 02:07 test.txt

tim@hn:~$ ls -al ~/Dropbox/ETest
total 48
drwxrwxr-x   2 tim tim  4096 Mar 12 01:24 .
drwxrwxr-x 440 tim tim 32768 Mar 12 02:07 ..
-rw-rw-r--   1 tim tim    24 Mar 12 02:07 test.txt

tim@hn:~$ ls -al ~/Dropbox/GTest
total 48
drwxrwxr-x   2 tim tim  4096 Mar 12 01:25 .
drwxrwxr-x 440 tim tim 32768 Mar 12 02:07 ..
-rw-rw-r--   1 tim tim    24 Mar 12 02:07 test.txt

tim@hn:~$ cat /mnt/74bcf733-f29b-42db-bedd-1882056fb822/FTest/test.txt
Just some text for test

tim@hn:~$ cat /mnt/74bcf733-f29b-42db-bedd-1882056fb822/GTest/test.txt
Just some text for test

tim@hn:~$ cat ~/Dropbox/ETest/test.txt
Just some text for test

tim@hn:~$ cat ~/Dropbox/GTest/test.txt
Just some text for test

tim@hn:~$ mount | grep 74bcf733
/dev/mapper/luks-60d82ae3-53f5-4e69-adea-98fa841b015c on /mnt/74bcf733-f29b-42db-bedd-1882056fb822 type ext4 (rw,nosuid,nodev,relatime,data=ordered)

tim@hn:~$ cat /etc/fstab | grep 74bcf733
/dev/disk/by-uuid/74bcf733-f29b-42db-bedd-1882056fb822 /mnt/74bcf733-f29b-42db-bedd-1882056fb822 auto nosuid,nodev,nofail 0 0

[Здравко]

Hi @cipherguru,

Yes, you are right. Unfortunately seems Dropbox had changed their way to check used FS. Some time ago the check was independent for every one FS element (file or folder). Now seems full FS check is performed only for the Dropbox folder, itself; further, the folder content is checked to be part of the same block unit. This second check is something new and will affect any mount of something outside current block unit (real or virtual), don't even need to be another drive or partition. Dropbox doesn't try extend application feature set, but make users life heavier instead, again! Long time I hadn't used such type of mounts. Have to be considered this case (current workaround still work, but should to be extended to cover the case). If you have a time, while keep current solution, try find and reimplement other "guilty" functions (in the same way as those already swapped). I will try take a look when possible.

Good luck.

[rjk]

Having a real hard time figuring out if I can move the Dropbox folder to anywhere other than my home directory on a headless ubuntu server install - can it be done? If not, why not and are there any workarounds?

My home directory is on a smaller SSD, but I want my Dropbox archives to live on my larger redundant ZFS pool. The location I want to use is /pool/dropbox/ but I have been unable to get it to work whether by symlinking to my home dir or changing a bunch of parameters in my systemd service definition for Dropbox.

Help!