RIP Dropbox on Linux
Yesterday, Dropbox has finally pulled the plug on its Linux support. Let us keep a silent minute for the deceased.
Of course, Dropbox does see this differently, but their explanation that ext4 is the only reasonable file system (and be aware, not in all combination and encryption), and also the only that supports extended attributes, is so ridiculously stupid that it is vain to even discuss it.
Yes I know, as OSS enthusiast I should (and I am) using NextCloud. But integration-wise Dropbox is still the best, and many of my applications only offer Dropbox integration (or, God forbid, OneDrive integration).
For those desperate one like me:
git clone https://github.com/dark/dropbox-filesystem-fix.git- make the script
dropbox_start.pyexecutable - call make there to build the shared library
- disable auto-start in the Dropbox application
- add the
dropbox_start.pyto your list of autostart programs
It is not a perfect, and surely not a solution that will work forever, but for now until I have moved all my files out and somehow converted to different applications, it does its job.
RIP Dropbox on Linux, and I hope this company will disappear as punishment for their stupidity.
If you don’t need the synchronisation part, then try this – https://github.com/rianhunter/dbxfs
Yes I know that project, and it works nicely, but not what I need. I’m often working on trains or airplanes without access, and thus this doesn’t help. Thanks anyway.
The irony of the extended attributes argument is that, as I discovered when trying to copy files to/from macOS, the space allocation for extended attributes on ext4 is set and fixed at filesystem creation time and is too small for the volume of attributes macOS uses in practice. And our tooling will silently strip the attributes rather than error out. Contrast XFS, which can resize it.
The encryption argument on the other side though I don’t get. I thought it was generally agreed that ecryptfs, encfs and similar were now approaches with too many flaws conceptually and plenty of crippling bugs practically. Putting ext4 (or whatever) on top of LUKS/LVM seems the only practical way to do it these days, which is totally transparent to the filesystem or dropbox.
It looks like a Dropbox update broke this: https://github.com/dark/dropbox-filesystem-fix/issues/4
Oh no, bastards.
I found rclone to be a nice alternative to installing the Dropbox client. It is usually run manually to sync. And it’s even packaged in Debian.
https://rclone.org/
I successfully migrated all my Dropbox installations to Syncthing running on my own server, for several months now. No problems. I highly recommend it.
https://github.com/syncthing/syncthing
If you’re looking for a Dropbox alternative on Linux, you can try Insync. It’s a Google Drive syncing tool and requires a one-time payment, but the ease of use and dedicated support team makes it worth it. If you’re thinking about migrating your Dropbox files to Google Drive, it’s easy to do so and they made a blog post about it here: https://www.insynchq.com/blog/dropbox-linux-filesystem/