An encrypted home directory with ecryptfs

In a recent post, I reviewed how to setup ecryptfs for providing a private directory.  In that scenario, the directory “$HOME/Private” is the private directory.  The files in that directory are stored on disk as encrypted files, but you see them as if unencrypted.  The actual encrypted files are stored in “$HOME/.Private”, and what you see is a virtual unencrypted version of those files, mounted on “$HOME/Private”.  The virtual unencrypted file system is only mounted while you are logged in.  If properly setup, it is automatically mounted on login and automatically umounted on logout.

In this post, I want to describe how to have your actual home directory encrypted in this way.  That amounts to having the virtual unencrypted file system mounted as “$HOME” instead of as “$HOME/Private”.

Initial setup

In order to set this up, there are a few steps where the root user must set things up.  But most of the work can be done by an ordinary user.  And note that I have tested this out, and it seems to work well.

The best way to set this up is to have a place outside of your home directory, where the encrypted files are kept on disk.  One suggested place for this is in a directory “/home/.ecryptfs” and that is what I have used.  I sometimes wonder whether it might have been better to make that “/home/ECRYPTFS”.  But then it is just a directory name.

As root, create the directory “/home/.ecryptfs”.  Inside that directory, create another directory for the specific user – give it a name like “/home/.ecryptfs/user”.

In my case, I normally login as user “rickert”.  So, as the root user, I did:

# mkdir /home/.ecryptfs
# mkdir /home/.ecryptfs/rickert
# chown rickert:users /home/.ecryptfs/rickert

Those are the only steps that need to be done by the root user. The last two of those commands need to be repeated for each user who will want an ecryptfs home directory.

User planning

The first step for a user is to setup an ecryptfs private directory, as described in my earlier post.

The basic plan is that what you see as “$HOME/Private” will become what is the home directory.  So files currently in your home directory must be moved into the Private subdirectory.  However, there may be a few files that you do not want to move to the Private directory, so a little advance planning is needed.

You must not move “.ecryptfs” or “.Private” to the Private directory.  They need to be outside the Private directory in order for ecryptfs to work.  I also decided to keep “bin” (a directory of mostly shell scripts), “lib” and “.ssh” outside of the Private directory.  I wanted those scripts (from “bin” and “lib”) to be available even when the ecryptfs home directory is not mounted.  In the case of “.ssh”, I sometimes login using ssh, with public key encryption, and I want that to work even when the ecryptfs home directory is not mounted.  So I wanted to keep that out of the ecryptfs mounted directory.

User setup

Having made my plans, the next step was to move the files and directories appropriately.  It is important to not be logged into a graphic desktop while doing this.  For example, I would need to move “.kde4” to “Private”, and that would cause problems if I were logged into KDE.

So logout from the desktop.  Use CTL-ALT-F2 to get a virtual console prompt, and login there.  Your ecryptfs private directory should be mounted, and you can check that with

ls Private

My first step was to deal with the Private directory itself.  I am used to having a directory named “Private”, so I wanted to continue with that practice.  For one thing, it helps when synchronizing files (backing up over the network) where I am synchronizing with a system where I have a Private directory.  So I did:

cd Private
X=`echo * .??*`  ## make a list of files
mkdir Private
mv $X Private
cd ## back to home directory

These few commands won’t work if there are files in “Private” with spaces in their names.  I made the list of file names before creating “Private”, so that “Private” would not be part of that list.

With that done, the next step is to move files and directories from my home directory to “Private”.  Use the command “ls -a” to list all files.  Ignore “.”, “..”, “.Private” and “.ecryptfs” as well as any files that you have chosen not to move.

mv .kde4 Private
mv .g* Private

You can do a bunch together, as the second of those commands suggests.  Repeat until done.  Occasionally use “ls -a” to see what remains.  When done, you should see only the files and directories that you did not want to move.

The next step is to unmount the Private directory


With that done, make a list of what remains.  In my case, that was:

X=".Private .ecryptfs bin lib .ssh"

The list should be small enough to do manually.  Do not include “Private” in that list.  Then move those files to the space provided in “/home/.ecryptfs/user”:

mv $X /home/.ecryptfs/$USER/.
for file in $X
  ln -s ../.ecryptfs/$USER/$file .

This should move those files, and then create a symbolic link to them, so that they will still appear (by virtue of the symlink) to be in the home directory.

The next step is to edit the file “.ecryptfs/Private.mnt”.  That file should contain one line.  It specifies where the ecryptfs directory is to be mounted.  You must remove the characters “/Private” from the end of that line, so that it now gives the path to your home directory.

You are almost done.  To test it:

cd /
ecryptfs-mount-private  ## remount the ecryptfs directory

That should have mounted the ecryptfs directory as your home directory.  And you should now be able to see the files there.  However, the files that you did not move to the Private directory will be missing, so create symlinks for those.  “$X” should still be a list of those files.

for file in $X
  ln -s ../.ecryptfs/$USER/$file .

And you are done.

It is probably a wise idea to take a backup before you start any of this.  As the saying goes, to err is human.


Tags: ,

About Neil Rickert

Mathematician and computer scientist who dabbles in cognitive science.

9 responses to “An encrypted home directory with ecryptfs”

  1. Sjoerd says :

    Thanks for your clear explanation. I am just trying out openSuse 12.3 (coming from Ubuntu) and the missing encrypted home option from the start is a big bummer. It’s or full disk encryption (which is not convenient for multi-user systems) or use a container kind of way as I understand it. Anyway I am going to try your procedure to get it back 🙂


  2. Sjoerd says :

    Hmmm sometimes I think that something should be easier to do and in this case that’s true:

    why not use the root command: ecryptfs-migrate-home -u

    to do all the work for you? Don’t need to make directories nor copying stuff 🙂
    I just remembered I used it before on Ubuntu, so just tried it with openSuse and it works like a charm! 🙂


    • Neil Rickert says :

      Thanks. I didn’t think of checking for automated scripts.

      In my case, I probably would have made the change manually anyway, because that’s the way to learn. But, for most users, it will be easier and perhaps safer to use the script.

      Personally, I am still preferring an encrypted partition — actually an encrypted LVM — on my primary home system. But the ecryptfs home directory is great on a machine at work, where I want it to be able to be rebooted when I am not there to enter the password.


      • Sjoerd says :

        I agree it’s the best way to learn, but automating things after understanding it won’t hurt either 😉 For explanations, blogs like yours are helpfull 🙂

        I would prefer full disk encryption like you myself too, but that’s indeed not convieniant if sharing the machine with someone else or indeed remote rebooting, which I also use from time to time.

        After testing opensuse with ecryptfs, I think I will go to full disk encryption after all, since as you mention yourself in another posting with remote access with public keys not all works well. I encountered that too, since I can’t log in remotely all the time via ssh with public keys. Sometime it works sometimes it doesn’t 😦 Googling about it I encounter several links to a an old bug in ubuntu (2009) with the ecryptfs package. And indeed with Ubuntu it worked just fine. So maybe opensuse ecryptfs package still has the bug…don’t know..


        • Neil Rickert says :

          After testing opensuse with ecryptfs, I think I will go to full disk encryption after all, since as you mention yourself in another posting with remote access with public keys not all works well.

          Here’s how it works for me. I’ll use my work machine to illustrate. That’s where I have en encrypted home directory using “ecryptfs”

          When I am at home, and want to login to my work machine, I use “ssh” with public key authentication. That works without a problem. However, my home directory on the work machine is not mounted, so I don’t see most of the files.

          To correct that, I can use:


          That prompts me for my login password. I give that. Then I must use “cd” to get to the mounted home directory. And, thereafter, everything is fine. When I logout, the ecrypfts pam module unmounts the home directory.

          I don’t see the extra step of “ecryptfs-mount-private” as a problem.

          To make this work, I did have to ensure that my subdirectory $HOME/.ssh is accessible whether or not the home directory is mounted. That’s why I have the real “.ssh” directory in “/home/.ecryptfs/rickert” with symlinks in $HOME. That takes two symlinks. One of the symlinks has to be put there when the ecryptfs home directory is not mounted, and the other has to be put there when it is mounted.


          • Sjoerd says :

            Hmm after some further digging the problem with my ssh public key authentication was permissions on the home-dir, the .ssh dir and the authorized_keys file. Strangely enough my ubuntu didn’t give me a hard time with while openSuSe did…or something went wrong with copying the data back…Anyway it works now.

            I just keep my .ssh keys in my encrypted files, since I only wanted public keys to work when I was already logged in (don’t know why I wanted it anymore though 😉 )

            But why use symlinking? Why not place the user’s authorized_keys outside your home and change the sshd configuration? There’s the option like:

            AuthorizedKeysFile %h/.ssh/authorized_keys

            to tell ssh where to look for the file…


          • Neil Rickert says :

            But why use symlinking? Why not place the user’s authorized_keys outside your home and change the sshd configuration?

            Yes, that’s another way of handling it. It did not seem necessary, so I kept things simple.

            The usual reason for putting authorized_keys elsewhere, it to have them under strict root control, so that a user cannot change his authorized_keys without getting approval.


  3. William Visser says :

    Hi Neil,

    I’m considering using ecryptfs again. What is your experience in OpenSUSE leap 42.1?

    And an other question: will ecryptfs take a lot of speed when I use it for the whole home partition (750 GiB)?

    Thank you for your reply in advance.

    Kind regards,


    • Neil Rickert says :

      Ecryptfs is working fine with 42.1. Up through Beta1, the software wasn’t there. But in the last month or so, they really got things together.

      With ecryptfs, in effect each file is individually encrypted. But it is only decrypted as needed (when a file is used). I am not noticing any speed cost.


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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s

%d bloggers like this: