Archive for May, 2010

ecryptfs automount a (somewhat) easier way

May 3, 2010

So I’ve been messing with transparent file encryption lately because it’s a good way to easily add some protection to private files, and if you use an online backup service or cart around a laptop you’d be crazy not to encrypt your files.

For laptops, there are tons of options, and I’ve previously used full disk encryption via TrueCrypt on windows and dm-crypt on Ubuntu (via alternate install cd).

For online backup services like Ubuntu One/Wuala/Dropbox/etc, these aren’t as useful as per-file encryption. The main reason is that the encrypted disk is actually a single file, and any change to any file on the encrypted disk requires the entire block file to be re-uploaded to the online service.

Fortunately there are some very good (and open source) per-file encryption file systems. With these systems, when one file is changed, only that file needs to be re-transmitted to the backup service. The two I’ve tried are ecryptfs and encfs.


encfs is an extremely simple to use transparent per-file encrypted (FUSE) filesystem. The website has more than enough information to get it setup.  There are also plenty of guides on using it, including this clever one that uses the GNOME keyring.


ecryptfs is effectively the same as encfs with a different implementation.  The most important difference (imo) is that ecryptfs is a kernel mode filesystem, where encfs is a FUSE filesystem.

The Goal:

I wanted to put some documents on Ubuntu One as an off-site backup and to make them accessible from a laptop on campus if needed. Additionally, I would like to have a separately encrypted directory (or mountpoint) that is not sync’d online. This will be used for application data folders that I’d like to encrypt (like ~/.mozilla).


Using ubuntu, the first part is extremely easy.  I just followed the Ubuntu Guide, then created a symlink that put the encrypted data in the ‘Ubuntu One’ directory:

ln -s ~/Ubuntu\ One\private ~/.Private

The second part is a little more work.  Ubuntu’s automatic setup scripts are great for creating a single encrypted mountpoint, but the second one has to be created and setup manually.

This is easy with encfs, but I chose to do it with ecryptfs because:

  • ecryptfs is already built into the kernel and the utilities are already installed (I’m already using it for ~/Private)
  • encfs is a FUSE model, so I expect ecryptfs performance to be a little better.
  • I wanted to use the same directory for both encrypted and unencrypted data (overlay) which encfs doesn’t seem to support.

I liked how the blog post that I keep linking used python+gnome keyring to implement automount, so I wanted to try and do the same with ecryptfs.

There are a few changes I had to make to the encfs guide to make it work with ecryptfs:

  • Add an fstab entry to allow non-interactive, non-root mounting of the directory
  • use pexpect module instead of subprocess module in automount script


First things first, create the encrypted mountpoint:

mkdir ~/.appdata
sudo mount -t ecryptfs ~/.appdata ~/.appdata
Passphrase: <enter passphrase>

Then select appropriate options or use defaults (the only one I change is to turn on filename encryption).

Now, to make it mountable as non-root, I add an entry in fstab.  An easy way to see what should go in fstab, is to check mtab:

cat /etc/mtab |grep ecryptfs

Now I copy this to fstab and add the following options:

  • users,noauto – standard mount options
  • key=passphrase – not sure if this is necessary, might be the default
  • no_sig_cache – don’t check the sig cache (needed for non-interactive mode)
  • ecryptfs_passthrough=n – don’t know why this isn’t in mtab, not including it makes it prompt

/home/bjp/.appdata /home/bjp/.appdata ecryptfs users,noauto,rw,key=passphrase,no_sig_cache,ecryptfs_unlink_sigs,ecryptfs_fnek_sig=####,ecryptfs_key_bytes=16,ecryptfs_cipher=aes,ecryptfs_sig=#####,ecryptfs_passthrough=n 0 0

NOTE: Because of a bug with ecryptfs, you have to setuid mount.ecryptfs to do this as a normal user:

sudo chmod +s /sbin/mount.ecryptfs

Now we should be able to mount it as a user with “mount ~/.appdata” (after sudo umount ~/.appdata). To make it automount, we will modify the encfs python script.  I tried for a couple hours to try and get it to work with the subprocess module, but for some reason I couldn’t get ecryptfs to take the password from stdin.  I don’t know if it’s a bug or what, but none of the options (even the passwd=stdin option) would make it accept a passphrase from stdin.

To get around this, I used the pexpect module.

Also, don’t forget to add the passphrase to the gnome keyring (I used lp:gkeyring):

python --set -n "Ecryptfs Passphrase" -p ecryptfs=appdata --keyring login
Password: <enter password here>

The modified script is:


import os.path
import subprocess
import sys
import gtk
import pexpect
import gnomekeyring as gk

# paths constants:
PATH_FSTAB = os.path.expanduser("~/.appdata")

# get passphrase from keyring:
    items = gk.find_items_sync(gk.ITEM_GENERIC_SECRET, {"ecryptfs": "appdata"})
    item = items[0] # clean up your keyring if this list has multiple items
except gk.NoMatchError:
    print("no entry in keyring")

# run encfs:
cmd = ['mount %s' % PATH_FSTAB]
	p = pexpect.spawn(cmd[0])
	#p.logfile = sys.stdout

    print 'Error mounting %s.' % cmd[0]

print 'Mount successful'


  • Using the same directory for both ‘source’ and ‘destination’ isn’t really necessary, and if you want access to the encrypted data (like for an online service) you should use different directories.
  • Using a generated key (from ecryptfs-manager) is much more secure than using a passphrase, but if you’re going to save it on the hdd (kinda necessary for non-interactive mode), than it’s not good for laptops (whats the point if they steal the key with the ecrypted files) but fine for online services… as long as you don’t upload your key.