21

Some time ago Dropbox began to warn me about supporting ext4 as FS only. As a happy BTRFS user I wasn't happy, but have done this:

dropbox stop
dd if=/dev/zero of=~/dropbox.img bs=1M count=4096
mkfs.ext4 ~/dropbox.img
echo "${HOME}/dropbox.img ${HOME}/Dropbox ext4 rw,async 0 2" | sudo tee -a /etc/fstab
rm -rf ~/Dropbox/*
sudo mount "${HOME}/Dropbox"
sudo chown "${USER}:" "${HOME}/Dropbox"

Everything worked without errors, but Dropbox still says that I should use ext4 for its folder. What am I doing wrong?

  • What is the output of df ${HOME}/Dropbox --output=fstype – Ravexina Oct 25 '18 at 11:55
  • @Ravexina Type ext4 – val Oct 25 '18 at 12:12
  • 2
    I am very curious what feature in ext4 they depend on, which isn't also present in btrfs. – kasperd Oct 25 '18 at 12:37
27
+50

There are three things in total that Dropbox requires to continue working on Linux, and only one is properly documented. What I'm summarising here worked for Dropbox 59.4.93 on Ubuntu 18.04.1 (amd64).

You've already cleared the first hurdle:

  • The base file system needs to be ext4, and specifically not ecryptfs. i.e. if your home folder is encrypted, you need to put the Dropbox folder someplace else, eg. a separate ext4 partition.

The other things to check are these:

  • The ext4 file system needs to be formatted with ext_attr on. This is the default behavior, but you can confirm by running debugfs -R features /dev/sda1 (or whatever your device file is called -- if you're using LVM it might be something like /dev/mapper/computername--vg-partitionname)
  • The ext4 partition needs to be mounted with the user_xattr option set (You can check for and add the option in GNOME disks or edit /etc/fstab directly)
  • The target folder (or Dropbox sync folder) needs to be at least two levels beneath the mountpoint, as described in this post. This is obviously a facepalm-worthy bug.

Once I fixed all these things, Dropbox finally allowed me to move the target folder and the error messages about "unsupported file system" disappeared.

  • 3
    According to this thread, it seems that user_xattr option is set by default in the kernel for ext4 file system since 2.6.39. – Willie Robert Oct 30 '18 at 9:26
  • Re the third point about depth below mountpoint - I found that /var/data/dropbox did not work when picking a new location using the Dropbox GUI client v60.4.107 and /var/data/dropbox/d did work when selecting a new location via the GUI client. / is my mount point for /dev/sda1 which is ext4. And this creates /var/data/dropbox/d/Dropbox as the sync folder 0_o – jamesc Nov 6 '18 at 14:51
  • Thank you especially for the last point. I'm using Dropbox v60.4.107 on Linux Mint 18.3 64b and had problem with setting /partiton_for_dropbox as a Dropbox home. The error dialog still said something like "the partition is not ext4". What did work was choosing /partiton_for_dropbox/Dropbox. So yeah, the data is actually at /partiton_for_dropbox/Dropbox/Dropbox. – rzehan Nov 7 '18 at 10:39
  • 1
    All four requirements are fulfilled in my case. But Dropbox is still complaining. It should be something else. – djhurio Nov 7 '18 at 19:07
  • 1
    Just to expand on this, for checking ecryptfs, run df -T and look for a line that starts with /home/USER/.Private ecryptfs .... If you have that, your home directory is encrypted and you'll have to move Dropbox somewhere else. (I used /opt/dropbox/Dropbox, which worked.) Second, although user_xattr is set by default, you may need to add the word defaults to your /etc/fstab. – MikeTwo Dec 12 '18 at 3:38
5

There's an alternative to your solution - a GitHub repository called dropbox-filesystem-fix. This makes your Dropbox folder appear as if it's on an unencrypted Ext4 filesystem, no matter what filesystem you use, and you don't have to mount anything, you just have to run Dropbox with with a dropbox-filesystem library (LD_PRELOAD).

You'll need to grab the code from GitHub, compile the library (make) and replace the Dropbox startup entry with the dropbox_start.py script provided by dropbox-filesystem-fix.

If you need complete step by step instructions, check out this page.

4

I managed to fix this by using gnome-disks to format the ext4 partition instead of initially using GParted, as well as ensuring the Dropbox directory was placed at a 2-level depth of the mount point of the partition. On 64-bit Ubuntu 18.04.1 LTS with Dropbox v60.4.107.

The full storyline:

  1. To begin with I created my dedicated ext4 with GParted which also was used to resize the old partition to allow room for the new ext4.

  2. Then I tried to ensure that my setup fulfilled everything described by Florian's answer, but that did not solve my problem.

  3. Then after many tries at combining different solutions, I decided to erase the whole partition and reformat it to ext4 with Ubuntu's native disk manager (just called Disks or gnome-disks) leading to Dropbox accepting the partition as ext4!

I used the following line in /etc/fstab to mount the partition:

UUID=ext4_partition_UUID    /media/dropbox  ext4 defaults 0 2

(where ext4_partition_UUID represents the UUID found with ls -l /dev/disk/by-uuid/)

Notice that I do not specify the user_xattr option here.

My Dropbox folder is now located at /media/dropbox/data/Dropbox - but did not check if the depth of 2 was really necessary.

It seems something went wrong when formatting the ext4 partition with GParted instead of the native software - no idea why or what the difference between them would be. If anyone knows I would be happy to learn more about it.

  • In fact, GParted calls native software. – val Dec 28 '18 at 7:32
  • This may have been useful to see why the old formatting didn't work: debugfs -R features /dev/sda1 – Jonathan Jan 7 at 17:42
2

My Lubuntu 18.10 installation laptop started complaining about the Dropbox some time back, but it wasn't until last week that I found that it did not have the package attr installed. Once I had installed that, Dropbox appears to be happy…

I had happened upon the article at https://unix.stackexchange.com/a/475253 and attempted to check the file attributes within the Dropbox directory on the laptop. I was surprised to discover that the getfattr command wasn't available, that led me to installing the package.

This might be a way forward for you, or it could be a completely different problem, but I hope it's worth flagging up.

  • 1
    attr is installed. – val Oct 25 '18 at 12:12
2

Dropbox has brought back support for ZFS, XFS, Btrfs and eCryptFS

Dropbox has brought back support for ZFS, XFS, Btrfs and eCryptFS on Linux. A Dropbox client update brings back support for ZFS and XFS on 64-bit Linux systems, and eCryptFS and Btrfs on all Linux systems.

Links:

  • Good to know! I bet that "support" is change in code checking for fs compatibility. – val Jul 26 at 12:18
0

Check if you are using ecryptfs which is not supported:

ecryptfs is not supported, but Dropbox will continue to sync with supported file systems that are encrypted via full disk encryption (e.g. LUKS)

  • 2
    You see, there is only ext4 in fstab line... and I mount on btrfs. – val Oct 24 '18 at 3:53
0

There's a disputed bug in Dropbox Linux that won't let you put Dropbox in a folder even near ecryptfs

For example, I had ecryptfs /home/user/Dropbox, and I moved it to ext4 /home/user-unencrypted and it still failed. I had to move it to ext4 /dropbox/ for it to work. I contacted their support team but they continued to argue with me saying ext4 /home/user-unencrypted was ALSO ecryptfs because they both began with /home/ Perhaps I'm mistaken in how ecryptfs works but I didn't see any evidence to suggest everything under /home/ was encrypted when I ran file system debugging tools.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.