From ArchWiki


Just a short remark which took me several hours to figure out:

I tried to follow 3.2 manual setup without ecryptfs-utils and it worked very well until I tried to get my encrypted directory mounted on login.

It is now working and two crucial steps seemed to be: 1. besides use also 2. put an empty file "auto-mount" into /home/USER/.ecryptfs

Especially figuring out 2. has taken a lot of time. It would be good if the article would mention this fact. If someone who really knows ecryptfs can verify that I have done the right things, then one should add remarks about this to the page.

Kind regards DaAlx (talk) 21:20, 25 March 2015 (UTC)Reply[reply]

Hi, can you please put a link here which section you followed? Did you use the ecryptfs-simple package (section 3.2)? Section 3.1 mentions the points you make (ECryptfs#Auto-mounting). Sections 3.2 and 3.3 dont. I assume you refer to 3.3 ECryptfs#Without_ecryptfs-utils, please confirm. --Indigo (talk) 06:56, 26 March 2015 (UTC)Reply[reply]
Hi, oh sorry for the imprecise section reference (must have been too tired) So I started my setup with 3.3.2 and followed up to Ecryptfs#Auto-mounting_2 -- DaAlx (talk) 08:22, 26 March 2015 (UTC)Reply[reply]
Thanks. I now re-tried the section 3.3.2 again. My results for the described pam_mount are different though, i.e. I did not need your points (1) and (2) above at all. It mounts like it should, but tor some reason the directory is user-mounted twice and does not unmount on logout.
Not sure what to make of that, maybe someone else has an idea. How do you login (console, gdm, kdm, slim,...)? Did you use the ecryptfs-utils default directory name (~/.Private,~/Private) or another one? Have you modified /etc/pam.d/system-auth for other reasons before? --Indigo (talk) 19:06, 26 March 2015 (UTC)Reply[reply]
Edit: Now I figured why I had different results and was able to confirm yours. The reason was that I had an old /etc/modules-load.d autoload for ecryptfs and fuse (needed for other reasons) which I forgot about. Removing that I arrive at your results. The problems described above remain though. I have adjusted the section with [1], does it reflect your experience now correctly? --Indigo (talk) 20:06, 26 March 2015 (UTC)Reply[reply]
Hi! Yes, your changes exactly make the right points. Thank you very much. By the way, in the pam mount article there is a remark that auto-umount does not work currently. I also noted the double mounting thing on login --DaAlx (talk) 22:20, 26 March 2015 (UTC)Reply[reply]
Ok, good. Yes, the auto-umount does not work consistently with just as well:[2] The double-mounting I only noticed with configured pam_mount. Let's keep this item open a bit, maybe someone has an idea about the cause. --Indigo (talk) 23:19, 26 March 2015 (UTC)Reply[reply]
With reference to this talk I received a suggestion of a different approach via email. It employs pam_exec instead of pam_mount and it is suggested not to have the unmounting problem. See the short write up - see below comment. Note it is used on systemd-based debian Jessie and I have not looked into porting/testing it to Arch yet. If someone does, please give some input on your results. Thanks. --Indigo (talk) 16:36, 14 February 2017 (UTC)Reply[reply]
Hi I am the person responsible for the link Indigo posted I have made a second guide which corrects a very bad issue of your password ending up in the journal log, PLEASE MAKE SURE to update the code mentioned in my guide, new guide and make sure to WIPE YOUR JOURNAL if you did use the previous guide. Sorry for the bad error. I will when I am not tethering for Internet spin up an Arch VM and test this on Arch but thus far I have only tested it on Debian. Improvements and reviews of the guide and its code are more than welcome! KonomiKitten (talk) 09:38, 10 March 2017 (UTC)Reply[reply]
In any case thanks for reporting it! --Indigo (talk) 15:06, 10 March 2017 (UTC)Reply[reply]
I forgot to mention you can of course just rewrap with the new passphrase after you ran passwd; more effective than wiping the journal. --Indigo (talk) 20:41, 17 March 2017 (UTC)Reply[reply]
Hey Indigo, concerning auto-umount of ecryptfs, I've been adapting the solution proposed in the Pam_mount talk, and it works fine with console, lightdm and gdm logins (meaning the encrypted dir gets cleanly unmounted on logout, provided there are no process left using this dir), at least if one uses Ubuntu tools to encrypt the dir. It involves a different setup of /etc/pam.d (moving calls to a separate conf file, so as to stop being interfered by systemd --user). I am willing to expose it in lieu of the actual warning on auto-umounting ; just thought I could to tell you first. la Fleur (talk) 00:06, 13 October 2018 (UTC)Reply[reply]
Hey, thanks for the heads up. Sounds like great news, though I faintly remember the ecryptfs was always arguing that systemd does not warrant respecitve processes accessing the dir being stopped on user logout. Anyhow, please go ahead and share - it sure is something like a show-stopper for Arch usage of the package in some system environments. --Indigo (talk) 22:27, 14 November 2018 (UTC)Reply[reply]
Well; I did it at last. Now it seems pretty clear to me, as I tested the setup on 2 machines of daily use. One way or the other, the systemd-logind process can't quit on user logout if it did reach session in system-auth. la Fleur (talk) 22:13, 14 September 2020 (UTC)Reply[reply]

Changes to /etc/pam.d/system-auth for auto-mounting

Section explains the changes to /etc/pam.d/system-auth that are required for auto-mounting. As the contents of this file have changed, the guide needs to be updated. The following works for me, however, I do not use systemd-homed. So, this needs to be verified / corrected:

Open /etc/pam.d/system-auth and after the line containing auth [default=die] authfail add:

auth    required unwrap

Next, above the line containing -password [success=1 default=ignore] insert:

password    optional

And finally, after the line session required add:

session    optional unwrap

Bananana (talk) 13:09, 19 August 2020 (UTC)Reply[reply]

Msoulier (talk) 13:13, 10 March 2022 (UTC) So I tried the changes in auto-mount, and the corrections here, and in both cases my login fails. I nearly locked myself out of my laptop. Thankfully I kept a login in a virtual terminal so that I could undo the changes. The ecryptfs-migrate-user script seems to have already set up auto-mounting without modifying pam, as it worked on my first login. Are the pam changes needed?Reply[reply]

You were right ! It was corrected (maybe you did) la Fleur (talk) 22:32, 14 September 2020 (UTC)Reply[reply]

Updating pam.d files used

Why do we modify system-auth ? pam_mount actually modifies system-login for session and auth instructions, and password for password instructions. It seems indeed adapted to process home-mounting sequences on login procedure. And I can really understand that su fails for the reason that it can't access home directory if nobody has logged in. la Fleur (talk) 22:13, 14 September 2020 (UTC)Reply[reply]

Key wrapping in Manual Setup

( stty -echo; printf "Passphrase: " 1>&2; read PASSWORD; stty echo; echo 1>&2; head -c 48 /dev/random | base64; echo "$PASSWORD"; ) \
| ecryptfs-wrap-passphrase /home/username/.ecryptfs/wrapped-passphrase >/dev/null

For some reason (?) the wrapped passphrase that's currently generated only uses [0-9][a-f] (not sure why) and is only 60 characters long instead of the maximum of 64.

Using base64 would be a better solution in this case: With [0-9][a-f] you only have 32 bytes of "randomness" in a 64-byte passphrase. With base64 you can squeeze 48 bytes in there.

Andrej (talk) 12:24, 18 October 2020 (UTC)Reply[reply]