I you have an account with an encrypted home folder, you can't access the user's plain text data in their home folder if that user hasn't logged in, yet, since the system last booted up. This is what I expected because it should in fact not be practically feasible to access a user's home folder without their password being entered.

However, I found that when a user with an encrypted home folder logs in and then logs out, the plain text data in their home folder still is accessible to other users. Sufficient access privileges are required, of course.

w doesn't list the user and the output of sudo pgrep -u <username> is empty, indicating that the user doesn't have any running processes.

What is the reason for this behavior? Why not just lock the user's home folder after they logged out?

  • Could you please include the output of grep -Fe ecryptfs /var/log/auth.log from around the time the user logged out? Apr 30, 2017 at 14:25
  • The command yields this output: pastebin.com/jZXdahbJ According to Emacs, the only lines which contain the string "ecryptfs" are the lines which were produced when I ran that command.
    – UTF-8
    Apr 30, 2017 at 14:37
  • The result is as expected just the lines which Emacs already showed me: pastebin.com/VtV7iCDg
    – UTF-8
    Apr 30, 2017 at 14:44
  • Ok. It was worth a look. Apr 30, 2017 at 14:55
  • I have noticed this bug in persistent live systems too (in an attempt to create a second user with encrypted home).
    – sudodus
    Jul 6, 2017 at 4:31

6 Answers 6


Known bug

If I understand correctly, this is a known bug.

See this link: wiki.archlinux.org/index.php/ECryptfs

Scroll down to the pink paragraph

Warning: Unfortunately the automatic unmounting is susceptible to break with systemd and bugs are filed against it ...


As it is now, you had better shut down or reboot in order to remove the traces (It is not enough to log out).

  • What do you mean by "logout will leak the information between the users"? Do you mean that anything happens, other than that a different user with sufficient privileges can access the plain text data in the first user's home directory? (This is already possible before the logout, of course.)
    – UTF-8
    Jul 9, 2017 at 13:55
  • 1
    Trying to explain better: 'It is not enough to log out'. (Logout does not remove the clear-text instances of the files, that have been used by the user with encrypted home. So information can leak from this user to another user, who logs in, at least if this other user has sudo privileges. But if you shut down or reboot, the clear-text instances of the files disappear.
    – sudodus
    Jul 9, 2017 at 15:04

I have been researching this issue for quite some time, i.e., unecrypted file system remains mounted after user logout.

I used "ecryptfs-migrate-home -u user" to create mount. followed directions and all works except no auto-unmount at logout.

I compared the config files in /etc/pam.d/ to pam_ecryptfs documentation and found the some differences. ecryptfs was in 4 of the pam.d config files whereas the pam_ecryptfs docs indicate just 2 files need/should/support ecryptfs, e.g.,

              auth    required        pam_ecryptfs.so unwrap
              session optional        pam_ecryptfs.so unwrap

So, I commented out the other 2 instances, rebooted, and it all worked, auto-mounts at login and auto-unmounts on logout for both graphical and console logins. (I used alternate tty's to verify from root account)

This is on 18.04 Lubuntu on laptop, desktop and virtualbox guest (windows host).

I am interested in others experience.

edit_1: improved wording. edit_2: added desktop and VB test results.

  • Did disabling / commenting out any of those lines cause any problems? Does changing your password still re-wrap the eCryptfs keyfile?
    – Xen2050
    Oct 2, 2018 at 7:13
  • This worked for me on Linux Mint 19. To add some more detail for others: the four config files in /etc/pam.d that refer to ecryptfs are: common-auth, common-password, common-session, common-session-noninteractive. Commenting out the lines in common-password and common-session-noninteractive led to the desired behavior of unmounting on log out. Also, the entry in common-auth was set to "optional" instead of "required" as it is supposed to be according to the documentation. However, I left this as is.
    – evencoil
    Oct 14, 2018 at 19:45
  • @Xen2050, sorry for late response. I did not detect any problems after changes commenting out lines and I have not tried changing password as yet.
    – redrock
    Jan 3, 2019 at 21:47
  • The changing password might be important to test, it should re-wrap the encryption key with your new password automatically, so logging in the next time works. If it doesn't work, then just changing the password back to the previous one should work... [it's always good to have a backup though]
    – Xen2050
    Jan 4, 2019 at 4:00
  • 1
    @Xen2050, I did the test of changing password. it worked.
    – redrock
    Jan 4, 2019 at 8:16

I can't test or confirm this, but assuming that you are using ecryptfs (which is what Ubuntu offers during install, IIRC), the encrypted data is stored in a hidden folder /home/.encryptfs/$USER and mounted to your actual home folder's location using the ecryptfs driver when you log in.

Most likely, then, what is happening is that when you log out, it fails to automatically unmount that directory, so the files are still accessible. This could be caused by...

  • a bad config (perhaps it was supposed to be configured to unmount on logout but wasn't)
  • unexpected logout type (sometimes these solutions work for the DM login/out but don't work well otherwise)
  • if the unmounting is handled by a logout script (not necessarily the case), something preceding the unmount command could fail and cause the script to exit early.

One thing that can help you check this would be to run sudo mount | grep home before login, after login, and after logout to see if anything involving home is being mounted. You could also look in /etc/fstab for relevant entries. Finally, there is some config in /home/.ecryptfs/$USER/.ecryptfs/ with pertinent settings to automounting/unmounting.

Useful information about ecryptfs can be found in this answer and in the ever-helpful ArchWiki.

  • I tried what you told me: pastebin.com/DrmEXQPV I don't log out in any weird way but in the standard GUI way. The FS is still mounted, as you can see. The config files you mentioned are empty. There is nothing in my /etc/fstab except 1 entry saying that my only data partition should be mounted to / and 1 entry which is about some university-related network resource. Should I try logging out in any different way? If so: How?
    – UTF-8
    Jul 3, 2017 at 21:09
  • The logging out in a different way comment was a bit of a guess--desktop managers add a lot on top of logging in and logging out that complicates the notion and makes it hard to tell which events are triggered. I was wondering because there may have been some script or event that wasn't being run. Based on the other answers, it's not that kind of problem, but something to do with ecryptfs itself. On that note, though, do you use ssh or log in via the text terminals? It may be possible to write a script that will take care of unmounting on logout if we find where to put it.
    – krs013
    Jul 6, 2017 at 18:21

Edit /etc/systemd/logind.conf and set KillUserProcesses=yes

Note that this breaks background programs, screen, tmux, and similar...

This question here goes into it in more detail. I find defining a new systemd service unnecessary (or more accurately, not the desired behavior, as it's invoked as a shutdown hook, not when the user session terminates).


  • I will check if your method works for a persistent live system with a second user, which has encrypted home.
    – sudodus
    Jul 6, 2017 at 4:33
  • Sorry, but I could not make this method work in a persistent live system with a second user, which has encrypted home. (I have not tested your solution in an installed system, I will leave that to @UTF-8 who asked the original question.)
    – sudodus
    Jul 6, 2017 at 11:23
  • I'm not interested in fixing this on my own computer. I'm the only one who uses it anyways but want to use 2 accounts with encrypted home folders and no one else knows the password to either account. I'm interested in why it doesn't unmount the encrypted volumes automatically by default. Couldn't it just check for active background processes running in the user's context and unmount it if there aren't any?
    – UTF-8
    Jul 6, 2017 at 12:49
  • @UTF-8, I agree with you, that it should work like you want it to work. If I understand correctly, this is a known bug. See this link , wiki.archlinux.org/index.php/ECryptfs . Scroll down to the pink paragraph 'Warning: Unfortunately the automatic unmounting is susceptible to break with systemd and bugs are filed'. -- As it is now, you had better shut down or reboot in order to remove the traces (logout will leak the information between the users.)
    – sudodus
    Jul 6, 2017 at 14:48
  • @UTF-8 it's a bug in systemd/session interaction since at least wheezy (I'm perfectly comfortable just hanging it on systemd) - the /etc/systemd/logind.conf change works for me on 16.04 (tested with three different users, different sessions, etc...) Jul 6, 2017 at 18:55

I do it with a script in rclocal


while true; do
    if [ ! -d /run/user/1000 ]; then
        if [ -f /home/momo/.mounted ]; then
            umount /home/harry

    if [ ! -d /run/user/1001 ]; then
        if [ -f /home/vm/.mounted ]; then
            umount /home/maud

    sleep 10
exit 0
  • How you get the userid? Nov 11, 2019 at 0:04

If you do not need access from cron or at jobs (non-interactive tasks) to ANY home directories then you just need to comment out the line

session  optional        pam_ecryptfs.so unwrap

in /etc/pam.d/common-session-noninteractive.

This will cause all encrypted home directories to be unmounted when the user logs out.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .