Ytdyklly

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?

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.

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.

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.

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.

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)

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.