Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am experimenting with using eCryptfs on top of dropbox, and I am encountering some issues.

My system is GNU/Linux, openSUSE 12.2 to be exact.

My setup is thus: I have set up two instances of VirtualBox running openSUSE 12.2, lets call them VM1 and VM2. Dropbox, as usual, is synchronizing everything in ~/Dropbox. To create my eCryptfs setup I do the following on both the VMs:

mkdir -m 500 ~/ecryptfs_upper
mkdir -m 700 ~/Dropbox/ecryptfs_lower
sudo mount -t ecryptfs Dropbox/ecryptfs_lower/ ecryptfs_upper/

I configure eCryptfs with:

key type: passphrase
cipher: aes
key bytes: 16
plaintext passthrough: no
filename encryption: yes

If I now proceed to create a file in ~/ecryptfs_upper on VM1, it will show up correctly on VM2 as well. However when I then change this file on one VM it sometimes (often but not always for some reason) will not appear to be updated on the other VM.

If I inspect the underlying files in ~/Dropbox/ecryptfs_lower on the two VMs they are identical (sha256sum produces the same hash), so dropbox has correctly managed to synchronize them. But the corresponding files in ~/ecryptfs_upper are still different! I have to umount then again mount eCryptfs to have the changes show up correctly.

The problem seems to be that when dropbox updates a file in the eCryptfs lower directory, eCryptfs doesn't notice the change. Presumably eCryptfs is assuming that all changes will go through the mount. For most use cases that is obviously a fair assumption, but when using eCryptfs to encrypt synchronized cloud storage like dropbox, it is obviously a big problem.

I've seen several people advocating using eCryptfs with dropbox, but I haven't seen this problem mentioned. Does anyone know of a fix (a way to turn off the cache that eCryptfs seems to be using for example), or of some alternative to eCryptfs that would not suffer from this problem?

share|improve this question
up vote 3 down vote accepted

Look at encfs as an alternative to eCryptfs. It does not suffer from the problem you describe.

EncFS/Dropbox setup tutorial

share|improve this answer
EncFS does indeed seem to not suffer from this problem, making it much more suitable for this task. I also found, which provides a nice conflict handling mechanism to the dropbox+EncFS combination, making it a very nice solution indeed. – Quantumboredom Feb 3 '13 at 19:23
On Windows, Mac, and mobile, you can use BoxCryptor to make it easier to access the encrypted data. – hrunting Feb 3 '13 at 19:43
Be aware of the cryptographic weaknesses in EncFS if you are relying on it for something critical ( There's work underway on a 2.0 version which may or may not address those, but no releases as yet. – darrend Nov 4 '15 at 0:56

You've stumbled on a design flaw in eCryptfs on Linux. There's no mechanism to inform eCryptfs that a change has been made to the lower page cache, so it doesn't know if a page has changed out from under it. Changing the lower encrypted files on an active eCryptfs mount is sort of like flipping bits on the block device while it's mounted EXT4. EXT4 has its own idea about the state of the block device because it assumes it's the only thing messing with the block device, and if that's changed out from under it, things can go south pretty quick.

share|improve this answer

It's not a solution but its way around. Tested on Linux Mint 17 and works perfectly, but should also works on other Linux distributions.


export PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"


# Remove previous installation of Dropbox - all directories (~/.dropbox, ~/.dropbox-dist, ~/Dropbox) and in command line type:
# mkdir -p ${HOME}/.mount/dropbox
# dd if=/dev/zero of=${HOME}/.mount/dropbox.img bs=4K count=2M # for 8GB
# mkfs.xfs ${HOME}/.mount/dropbox.img # for XFS, but you can use your prefered FS, eg. EXT4
# mkdir ${HOME}/bin
# Put this script to ${HOME}/bin
# chmod 0755 ${HOME}/bin/
# Add to /etc/sudoers line:
# YourUserName  ALL=NOPASSWD: /bin/mount
# Run this script: ${HOME}/bin/
# chown ( id -u ):( id -g ) ${HOME}/.mount/dropbox
# Next start Dropbox App and select ${HOME}/.mount/dropbox/ as a base directory,
# Dropbox automatically will create ${HOME}/.mount/dropbox/Dropbox.
# Turn off Dropbox autostart in Dropbox preferences.
# Add this script to system autostart (Setting->Startup Applications)


if [ `mount | grep -c "${xhome}/${xdropbox}"` -eq 0 ]; then
    sudo mount -o loop ${xdropbox_img} ${xdropbox_dir}

sleep 10 && dropbox start &>/dev/null

exit 0
share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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