Using ecryptfs with opensuse 12.3

I have been using ecryptfs with the early milestone releases, the beta releases, the release candidates and the final release of 12.3.  It has worked very well.  The only problem I have seen, is that some of the ecryptfs utilities do not properly load the ecryptfs module.  I have rarely encountered this problem, though it can occasionally arise.

Installing ecryptfs

All it takes to make ecryptfs available on your system, is to install “ecryptfs-utils”.  I did that with Yast software management, though it could also be done with zypper (at a root command line) or with Apper.

That’s it.  Just install that one package (it will bring in several other packages), and you are done.  If you used a root command line to install, then you might want to also run the command:

# modprobe ecryptfs

at the same time.  That will ensure that the kernel module has been loaded for this session.

Well, okay, that’s not quite it.  The general recommendation is that encrypted swap should be used.  This is because, while private files are encrypted on disk, an unencrypted copy of part of the file content might exist in swap.  The root user can setup encrypted swap with

# ecryptfs-setup-swap

I will note, however, that I have never tried using this command.  I setup encrypted swap myself during system install.

Setting up ecryptfs for a user

What ecryptfs does, by default, is provide a directory Private for the user.  All files in the Private directory are stored encrypted on the disk.  When the user is logged in, software automatically encrypts/decrypts the files for the user.  When the user is not logged in, the unencrypted content of the files is not available.

In order for a user to have such a Private directory, there is one setup step.  It can be performed by the user, who need only run the command:


If this command generates a weird error message, then the ecrypfs module has not been loaded, and the “modprobe” command (see previous section) will be needed.

The “ecryptfs-setup-private” command will request the user’s login password, and that will be used as part of the encryption.

Once the encrypted private directory has been setup, the best advice is for the user to logout, and then login again.  That should make the private directory available (automatically encrypt/decrypt).

In normal use, when the user logs in, the ecryptfs pam library kicks in to setup the automatic encryption/decryption for the session.  When the user logs out, the automatic encryption/decryption of this user’s private directory is turned off.  On slower hardware there might be a slow delay for login due to the needed processing.

This arrangement will not work as well for a user setup for automatic login without password.  The ecryptfs pam library normally works with the password that the user has entered for login.

If a user has logged in without password (automatic login, or perhaps public key authentication with an ssh login), the private directory can still be made accessible with the command:


This command will ask for the user login password.  It is possible that this command will not quite work properly, due to the ecryptfs module not having been preloaded.  The symptom is that file names in the private directory look garbled.  In that case, use:


The login password will be requested a second time, and the setup should now be correct.  This problem should be rare – at most once per boot.  It has happened to me only once during all of my use of ecryptfs with 12.3 (including the beta testing phase).

Under the hood

Here’s how it all works.

When a user sets up an ecryptfs private directory, an almost empty directory “$HOME/Private” is created.  Two additional directories, “$HOME/.Private” and “$HOME/.ecryptfs” are also created.  The “$HOME/.ecryptfs” directory is for settings.  The “$HOME/.Private” directory is where the encrypted files are stored.

The actual encryption uses a generated random key.  That key is encrypted with the user login password (this is called “wrapping”), and then stored in the “$HOME/.ecryptfs” directory.  When a user logs in, the pam library uses the login password to unwrap the encryption key, install that in the kernel, and mount a virtual unencrypted version of the files on top of “$HOME/Private”.  That allows the user to deal with the unencrypted version of the files, while the permanently stored files are encrypted at all times.

Encrypted home directory

It is actually possible to use ecryptfs for an encrypted home directory.  I plan a future post on how to set that up.  The first step is to setup a private directory.

Module loading woes

As mentioned above, some of the ecryptfs utility programs fail to load the ecryptfs module.  I rarely see that because the pam library, that mounts the user private directory on login, does handle this correctly.  You will only meet this problem if the first use of ecryptfs after a reboot is with something other than pam.

I have seen the problem show up in two different ways:

  • When setting up a private directory (“ecryptfs-setup-private”);
  • When manually mounting a private directory (“ecryptfs-mount-private”).

The first of these problems will require root action (the “modprobe” command listed near the beginning of this post).  The user can recover from the second by unmounting and remounting, as described previously.

Another option is to setup your system to automatically load the “ecryptfs” module.  I have not done that with opensuse 12.3, because this problem arises only rarely.



Tags: ,

About Neil Rickert

Retired mathematician and computer scientist who dabbles in cognitive science.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: