Dropbox on Linux unlinks after restart

[Leeon]

Thank you @adreampuppet for testing, so seems type of connection doesn't matter? But you at least reproduced the issue, so far noone was able to confirm this issue.

[Leeon]

For now a quick workaround sprint, which waits, till internet is accessible. This script I'm running on start instead of regular dropbox start. It checks every 5 secs internet availability (loops forever) and after internet is online, dropbox launches. So far this works, till Dropbox fixes that issue in app itself.

#!/bin/bash
while $(wget -q --spider http://google.com); ret=$? ; [ $ret -ne 0 ];
do
    sleep 5
done
dropbox start -i

[fullmakt]

I'm not sure what you guys mean by unlinking account, but I have an issue where, after rebooting server, some folders containing a lot of files gets deleted on the server. dropbox then proceeds to sync this and the files gets deleted in the cloud, and subsequently deletion gets synced to other devices. 

I haven't been able to nail down, when exactly the folders gets deleted, but it happens every time I reboot my server it seems.

[grawity]

Leeon, can you check if the output of this command keeps changing across reboots:

stat -f -c %i ~/.dropbox/instance_db

(Keep the output secret, just check whether it changes or remains the same.)

This shows the statvfs().f_fsid, which Dropbox on Linux uses as part of the config encryption key. The developers apparently thought it is persistent, but it really isn't. For example, on XFS partitions, the fsid can change if partitions are moved around, it can change if you boot with a USB stick connected, it can even change randomly on every reboot. Every time it changes, Dropbox becomes unable to decode its configuration and just deletes it.

(I really wish they had used something more stable, but I don't even know where to submit a bug report about it.)

[Leeon]

@grawity Yes! You are right. When Dropbox starts normally, that ID is same as in previous boot, however when it disconnects, ID is different:

fe0300000000
fe0400000000

I need to say, that I'm not moving partitions nor connecting any USB drives etc. It just drifts by itself.

[fullmakt]

I will check this the next time folders are deleted to see if it has changed. thanks.

[Leeon]

I contacted support, unfortunately I got not so positive reply:

I have received a reply from our specialized team,

Unfortunately, this does not meet the minimum requirements for the Dropbox application. OpenSUSE along with the file system is not supported.

Please review our recommended minimum requirements on the following page:

https://www.dropbox.com/help/3

We are of course always looking for user input when creating the next version of the Dropbox app. I will make sure your comments are passed along to our development team.

[Leeon]

Seems I at least found a nice workaround for the issue:
My laptop has 2 disk drives - SSD and HDD. On SSD I have home with ~/.dropbox folder on XFS partition. However HDD is 1TB of ext4 mainly for data and media. So I moved whole ~/.dropbox/instance_db folder from home to HDD ext4 drive and created symlink back to home.
Dropbox is now happy as ext4 does not change inode IDs at all.

[Leeon]

Update to possible workaround: moving and symlinking ~/.dropbox/instance_db is not enough, it lasted for a day and resets again. Now I moved whole ~/.dropbox folder. So far so good after one day.

[grawity]

Yes, both ~/.dropbox/instance_db and ~/.dropbox/instance1 have separate keys, so at minimum you would need to move both.

And of course there's no guarantee that Dropbox won't change the layout in the future, so moving the whole ~/.dropbox/ is the best choice (for now).