Need to see if your shared folder is taking up space on your dropbox 👨💻? Find out how to check here.
Forum Discussion
Linux... move the Dropbox Folder
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 ...
I just spent 11 days with dropbox support because I recently tried solving the symlink problem by using a bind mount. Putting a bind mount in your dropbox folder will break the dropbox daemon and prevent it from syncing.
Unfortunately, there are no solutions for those of us that relied on symlinks to backup data outside of the dropbox folder.
nullptr wrote:
...Unfortunately, there are no solutions for those of us that relied on symlinks to backup data outside of the dropbox folder.
Hi nullptr,
Your statement isn't true actually! The symbolic link might be most convenient for many users, but isn't the only one.
nullptr wrote:... Putting a bind mount in your dropbox folder will break the dropbox daemon and prevent it from syncing.
...
😏 Actually, your statement could be true here (partially). Directory binding is additional layer between underlying file system and users programs. Such a layers interface, on Linux, always have nature of FS interface. In this context - binding falls in FS restrictions of Dropbox (bind interface isn't inside Dropbox "white list"). The truth in your statement is up to here. There is relatively easy way, developed long time ago in context of FS limitation introduction, which just overcome this limitation. Such method could be used and there is example for use here (just change device mount to binding). 😉 That's it.
Enjoy!
Здравко wrote:
(just change device mount to binding). 😉 That's it.I looked at the code in that post. It looks like it hard-codes filesystem type to EXT4 for stat calls and passes extra mode parameters in open calls. I don't see how this helps. Since I'm already using a bind mount on an EXT4 filesystem unsuccessfully are you saying that a solution is to change the hard-coded file system type? To what? The magic number for directory binding (does this exist)?
nullptr wrote:
...I looked at the code in that post. It looks like it hard-codes filesystem type to EXT4 for stat calls and passes extra mode parameters in open calls. I don't see how this helps. ...
Hi nullptr,
Yes, you are (almost) right. There isn't "extra mode", just parameters forward. I'm not sure what's not clear enough.
nullptr wrote:
... Since I'm already using a bind mount on an EXT4 filesystem unsuccessfully are you saying that a solution is to change the hard-coded file system type? ...Yes, exactly!
nullptr wrote:...
To what? The magic number for directory binding (does this exist)?
I noted already in previous post. FS-type (and corresponding "magic number"), not directory!
nullptr wrote:
...Or are you saying that when you use a bind mount, that the fs type passed to stat calls is something other than ext4?
Yes, exactly!
Hope this adds some clarity.
I suppose it might be worth a try to move the Home folder instead of doing tricky things with symlinks and mounting drives in the dropbox folder. Even so think you would need to uninstall dropbox, move the Home folder, or reinstall Linux and designate a Home partition of your choice. Then install Dropbox and everthing would be hunky dory. I will try that some time but for now I have giving up on Dropbox for my work. Currently I am just running rsync -a Lol.
Lol... I really does! Well maybe not but sometimes it is better than doing too many trix and side steps.
I guess its my lack of understanding of C++ and Ubuntu but I could not understand what you meant by "(just change device mount to binding)"
Does it require change in the source code? Which line? to what?
I tried ad-hoc fixes based on what I could understand
For example, I tried changing EXT4_SUPER_MAGIC to BINDERFS_SUPER_MAGIC but got the error
<stdin>: In function ‘statfs’:
<stdin>:21:19: error: ‘BINDERFS_SUPER_MAGIC’ undeclared (first use in this function)
<stdin>:21:19: note: each undeclared identifier is reported only once for each function it appears in
<stdin>: In function ‘statfs64’:
<stdin>:32:19: error: ‘BINDERFS_SUPER_MAGIC’ undeclared (first use in this function)undoing the change says
Your Dropbox is already patched.
So I'm doing something wrong.
cipherguru wrote:I guess its my lack of understanding of C++ and Ubuntu but I could not understand what you meant by "(just change device mount to binding)"
...Hi cipherguru,
Actually, there isn't any C++ code! Where you see it? API layer functions are C functions, not C++! Other (biggest) part is a shell-script ('bash' - more precise).
cipherguru wrote:...
Does it require change in the source code? Which line? to what?
...No actually. What make you think that any changes are needed?
cipherguru wrote:
...For example, I tried changing EXT4_SUPER_MAGIC to BINDERFS_SUPER_MAGIC but got the error
...I can't see any reason for such change, but if you want see what FS magic numbers are available for your system, take a look on "/usr/include/linux/magic.h". In my case I can't find "BINDERFS_SUPER_MAGIC". Where you find this from (and more important why - isn't Ext4 enough, though)?
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. :wink: "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.
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
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 0Hi 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.
