eCryptfs with dropbox: must remount for synchronized changes to be visible

Question

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?

Answer 1

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

EncFS/Dropbox setup tutorial

Answer 2

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.

Answer 3

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.

#!/bin/bash

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

xhome=${HOME}

# HOWTO
#
# 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/dropbox-mount.sh
#
# Add to /etc/sudoers line:
#
# YourUserName  ALL=NOPASSWD: /bin/mount
#
# Run this script: ${HOME}/bin/dropbox-mount.sh
#
# 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.
#
# IMPORTANT
# Turn off Dropbox autostart in Dropbox preferences.
# Add this script to system autostart (Setting->Startup Applications)

xdropbox=".mount/dropbox"
xdropbox_dir="${xhome}/${xdropbox}"
xdropbox_img="${xhome}/${xdropbox}.img"

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

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

exit 0