How to keep using Dropbox even if you don’t use unencrypted ext4 (workaround)

Dropbox has recently announced that they will be dropping support for all file systems that do not mount as plain ext4, that includes btrfs, zfs, xfs and ecryptfs (the home encryption shipped with many popular Linux distributions). Poop-emoticon! Luckily, it seems like ext4 on top of cryptsetup/LUKS is not affected by this awful business decision.

Unfortunately, many users are locked in with Dropbox for various reasons.

  • Using an app, that only synchronizes through Dropbox via their api
  • Sharing with peers that will only use Dropbox
  • Paid annually and does not want to forfeit the storage
  • Working for a company or organization that has long approval processes

Luckily, for the time being there is a workaround, as shown by this step-by-step guide. Proceed with caution and have backups. One wrong step and you might find yourself with an empty Dropbox. If you use home folder encryption, please read this before continuing.

Regardless of your success with this workaround, you might want to check out alternatives like pCloud (Disclaimer: Affiliate Link. One month free through this link)

Introduction

We will use a technology called loopback mounting, where you can treat a file like a block device and mount it to a specific location. It has usually been used in the past to mount .iso files, but it is perfectly capable of mounting any file system your Linux is capable of mounting. You can read more about it here.

Kill it with fire!

First, quit Dropbox. We hate what they did, so we are killing the poop out of it. Open a terminal, and type:

~ $ killall dropbox

Use ps x to verify dropbox is not running anymore.

Backup!

(not really a backup, but we make way)

~ $ mv Dropbox Dropbox.bak
~ $ mkdir Dropbox

Verify the contents of Dropbox.bak! A backup is only a backup if you can restore your data.

Create your loopback file

I am sizing it 150% of my Dropbox allowance, 3072MB, since I am only using the free version. This might be tougher if you are using a paid version with lots of potential storage. It is possible to expand this file later, a Google search for expand ext4 loopback should yield viable results.

~ $ dd if=/dev/zero of=~/.dropbox/storage bs=1M count=3072

create an ext4 filesystem

Become root, which is usually done by issuing sudo su or su and enter the appropriate password. It should be obvious that you replace <username> by your actual username from this moment on.

mkfs.ext4 /home/<username>/.dropbox/storage

optional: prevent writes when not mounted

As Jason Lewis pointed out in the comments, you can prevent accidental writes to /home/<user>/Dropbox, when the loopback device is not mounted. This is completely optional, but probably a smart thing to do. To set the “immutable”-bit, still as root, do:

chattr +i /home/<user>/Dropbox

mount it

To mount the filesystem, add this line to your /etc/fstab.

/home/<username>/.dropbox/storage /home/<username>/Dropbox ext4 defaults,user_xattr,loop 0 0

and mount with:

~ # mount /home/<username>/Dropbox/

Fix permissions

The folder might belong root, we can fix that by executing:

~ # chown -R <username>:<groupname> /home/<username>/Dropbox
~ # exit

Please note, that <groupname> is usually your username, but it might differ. To find out what to put there, simply execute ls -l in your homefolder and examine the results.

Restore your Dropbox contents

~ $ cp -a Dropbox.bak/* Dropbox/

Profit

You’re all done, you can now restart your dropbox client. Keep your Dropbox.bak folder and reboot. Check, if everything works as expected before you get rid of your file. Luckily, even if you lose them, you can restore them in your Dropbox account as a last resort. Let me know in the comments below, if it worked.

I am still getting the error

It might be that even after applying this workaround, you still get the message, that your filesystem won’t be supported. If you have set up your loopback device properly, you can safely ignore it.

If you received a notification, but are running one of the supported file systems, it’s possible that you may have recently had a computer linked that was running an unsupported file system but have been since upgraded, or that computer is no longer being used. (source)

Remove the awkward entry from nautilus/nemo

Because of how we implemented this workaround, new devices called Filesystem xxGB might show up in the file managers. We don’t want these, at best, we want our workaround to be as transparent as possible. You can remove it by creating a udev rule. I have tested that on Gentoo Linux, details might be different in your distribution.

Find out the UUID for your loopback image:

# blkid
/dev/loop0: UUID="e0036b9d-7f49-473e-9296-47c8b0e273e1" TYPE="ext4"

Create /etc/udev/rules.d/99-hide-disks.rules

ENV{ID_FS_UUID}=="e0036b9d-7f49-473e-9296-47c8b0e273e1",ENV{UDISKS_IGNORE}="1"

And reload the rules

udevadm control --reload-rules && udevadm trigger

The entry should be gone and you should now only see a mounted “Dropbox” device.

Prevent accidental ejecting through nautilus/nemo

On my desktop, I get a little eject-symbol next to my drive entry in nemo, clicking it will immediately remove the loopback device and Dropbox will think you delete ALL THE FILES. To prevent that, please remove this line from any file in /etc/polkit-1/rules.d/

action.id == "org.freedesktop.udisks2.filesystem-unmount-others" ||

Depending on your Linux distribution and security settings, it might not be necessary to do this. To test if you can accidentally eject with the arrow, kill Dropbox first!

A word on home folder encryption

Technically, it is possible to create the dropbox filesystem image within your home folder, keeping it encrypted whenever your device is powered off (basically the same level of security as you get from ecryptfs). The problem however is, that by the time /etc/fstab gets parsed on boot time, your home folder is not unlocked, therefore it won’t be able to find the file and fail the mount. In that case, you will have to add noauto,user to your mount options (after loop in /etc/fstab). That way, the filesystem is not mounted automatically on boot. You then have to remove Dropbox from your autostart and create a script, that is executed on login instead, which executes

mount /home/<username>/Dropbox/
dropbox &

to first mount and then start the daemon. In cinnamon, you could also set a 30s start delay for dropbox and add a script that only does the mounting without a start delay. The ways to get this working are limitless and may depend on what distribution and windowmanager you use, so in case you need help, find it within your distribution’s community. Good luck!

22 thoughts on “How to keep using Dropbox even if you don’t use unencrypted ext4 (workaround)”

      1. Unfortunately, Dropbox is playing dirty, because it does look at the underlying file system. It will only accept ext4 on a physical partition. Or maybe only anything encrypted; after all, you managed to get ext4 on btrfs. Try putting ext4 on ecryptfs or LUKS, and it’s a no-go. My system is already ext4 on ecryptfs, and Dropbox doesn’t accept it. The only rational explanation that I can think of is that Dropbox wants to drop Linux entirely, but isn’t being honest about it. I hope that I’m wrong.

        1. It seems like you are wrong on this one. First of all, you can’t “put ext4 on ecryptfs” (except through a loopback device). ecryptfs always resides on another file system, not the other way around. And regarding LUKS:

          However, contrary to @JinHadah’s post here, I can confirm that ext4 with full disk encryption (e.g. LUKS) is supported. We’re sorry for the confusion in that chat.

          (source)

  1. Obviously Dropbox is on the way out, Just think of it. People are moving to handhelds, they have access to iCloud and Google drive. Dropbox has an edge in that it works like a charm, but it is unclear if Dropbox will be private, safe, and secure going forward. This will not improve.

    Time to move to other sync software, e.g. NextCloud.

    1. Some users might not be able to move away. There are discontinued applications that use the Dropbox API on mobile and rely on the desktop client on your pc. Sadly, I use such a program, so no matter how many workarounds it takes, as long as I can keep it running, I will.

  2. Told you so! Not you, personally of course…

    Anyone who relies on convenient but proprietary tools deserves what’s coming to them! This rather elaborate workaround is evidence of that. When will people learn? And don’t give me that “there was no alternative” (at the time). If so, one still shouldn’t use this crap, for it is only a matter of time until it bites you in the butt. And if vendors get customers with their proprietary shit, they will keep selling it and people, not only their users, will be worse off for it.

    BTW and FWIW, there are some minor improvements to be made here:

    # killall -9 dropbox
    # THE END

    … just kidding, but killing something with -9 is not very nice and shuts the application down hard. A simple kill would suffice and gives the application the chance to perform a graceful shutdown, including any cleanup, which -9 would prevent, since it literally kills it.

    # cp -R …
    make that
    # cp -a
    you do want all the file attributes, like timestamps etc., to stay the same, right?

    And also BTW, since you never delete the original “Dropbox” directory and mount the loop file over it, it still consumes the same space, you just can’t see where the precious space has gone!
    Which is why, in this case a simple

    # mv Dropbox Dropbox.bak && mkdir Dropbox
    is what is *way* quicker (provided the target is on the same filesystem) *and* saves you 2 GiB of disk space (according to your example).

    And why do you have to run these commands as root? Is this because of dropbox? It shouldn’t be. Not running as root saves the final chown.

    Anyway, whoever hasn’t got hard dependencies on dropbox: This is the time to pull the rip cord! Or, maybe tomorrow they will change their terms of service to “your first born as compensation”: https://www.theguardian.com/technology/2014/sep/29/londoners-wi-fi-security-herod-clause ! I am pretty sure one of the conditions of dropbox says, they can change them anytime they see fit. Of course you can always cancel your contract, or can you? Or inform them that you don’t agree to these changes and they will cancel your contract for you!

    Food for thought. Some deep thought, I would hope.

    Best,
    Peter

    1. Hey Peter,

      thank you for your input on this. I wrote this up quite quickly, the reason for becoming root is, that /sbin/mkfs.ext4 is not accessible to me as user, but that might also differ from distribution to distribution.

      Regarding the necessary chown – that is probably because I made the ext4 file system as root? I’d rather leave it in the guide so I don’t get tons of support comments.

      I incorporated your proposed changes into the guide.

      And I do agree: everyone without dependencies, move on!

      1. I think, creating the mount point (“Dropbox” directory) as a normal user should be enough to not have to run a chown after mounting, but to be honest I am too lazy to test this right now. 😉 Anyway, since chown is run before the “backup” is restored, the directory is empty and chown should return rather quickly. 🙂

        But I just now noticed a potentially fatal flaw with creating the loopback file in a user writable directory. This way you might accidentally delete or damage that file, losing data in the contained filesystem. Make the directory containing the loop file and the file itself only writable by root. After mounting, you can still write to the filesystem inside of it.

        # mkdir -p /somewhere/maybe/even/outside/your/home/
        # cd !$
        # dd …

        Best,
        Peter

        1. I am sure there are good reasons for a crapton of variations, I chose the .dropbox folder because for the “average user”, these folders are hidden from their file managers. After all, all the data is still available on the dropbox, that’s why I am not too worried about the user accidentally deleting the loopback file.

  3. Hi, I have a question to all:
    Will current dropbox in linux work when syncing a veracrypt container (assuming the container itsself is located in an ext4 file system)? I think it is called incremental syncing, so that not the entire container (some GB big) has to be transmitted everytime. I remember that it worked a view years ago with truecrypt under windows.

    1. Dropbox hasn’t changed what files it is going to sync. It only changed the system requirements. Dropbox should still sync your veracrypt container that you have inside your Dropbox folder. I hope that helped.

  4. Why not use sparse files to save space on disk rather than taking up the entire space beforehand?

    I used the following on my system:
    truncate -s 3072M ~/.dropbox/storage

    or I guess this is an option as well:

    dd if=/dev/zero of=~/.dropbox/storage bs=1M count=0 seek=3072M

    1. Because running out of actual disk space while claiming to have space left in your loopback device I assume is undefined behavior for Dropbox. As I said in another comment, there are probably a ton of other ways to restore Dropbox functionality, such as LVM-resize + creating new volume, using “Ultra-Fit” USB-sticks and whatever your brain can come up with.

      This guide shows one method that works, so the not-so-advanced user can get it working with as few pitfalls as possible, while people like you probably have figured out a solution before even coming to this page.

      Don’t get me wrong, I appreciate all comments, but I have to find a balance between keeping it simple and listing all choices.

  5. Great instructions, thanks for putting this together.

    Consider adding:
    sudo chattr +i /home//Dropbox

    This makes the directory immutable and means you cannot accidentally write files in the directory if the loopback failed to mount correctly.

  6. so is microsoft somehow behind this? now that win 10 is supposedly using a linux kernel are they trying once more to squeeze linux out of existence?

Leave a Reply

Your email address will not be published. Required fields are marked *