ecryptfs-mount-private fails to initialize ecryptfs keys

[Tomas Hlavacek]

ecryptfs-mount-private fails to mount the ecryptfs after the 1st reboot after creating the ecryptfs by ecryptfs-setup-private.

After the unsucessful attempt dmesg contains:

[ 1265.695388] Could not find key with description: [<correct key ID>]
[ 1265.695393] process_request_key_err: No key
[ 1265.695394] Could not find valid key in user session keyring for sig specified in mount option: [<correct key ID>]
[ 1265.695395] One or more global auth toks could not properly register; rc = [-2]
[ 1265.695396] Error parsing options; rc = [-2]

Note: The correct key ID has been replaced in the "<correct key ID>".

I also accidentally found an workaround - just running ecrytpfs-manager and then the ecryptfs-mount-private (it does not ask for password for the second time and mounts the ecryptfs correctly):

host:~$ ecryptfs-manager

eCryptfs key management menu
-------------------------------
 1. Add passphrase key to keyring
 2. Add public key to keyring
 3. Generate new public/private keypair
 4. Exit

Make selection: 4
host:~$ ls Private/
Access-Your-Private-Data.desktop README.txt
host:~$ ecryptfs-mount-private
host:~$ ls Private/
<ecryptfs content is present>

[Etienne Papegnies (etienne-papegnies)]

Hello
Can you please add a tag for the version of Ubuntu you are using? (Xenial, Zesty, Artful)

[Tomas Hlavacek (tmshlvck)]

It is Artful... Sorry!

brill@tapir:~$ dpkg -l | grep ecrypt
ii ecryptfs-utils 111-0ubuntu4 amd64 ecryptfs cryptographic filesystem (utilities)
ii libecryptfs1 111-0ubuntu4 amd64 ecryptfs cryptographic filesystem (library)

brill@tapir:~$ uname -a
Linux tapir 4.13.0-11-generic #12-Ubuntu SMP Tue Sep 12 16:03:57 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[forevertheuni (forevertheuni)]

Exact same problem here. I am using a custom ecryptfs folder (always worked for 3 years). Only way to mount it was by running ecryptfs-manager first.

[Thorsten (thorstenr-42)]

i have a fresh ubuntu 17.10 installation with an encrypted home (so all auto configured). If i log into my user account it all works fine. However i also get that error message in dmsg:

[ 55.425188] Could not find key with description: [...]
[ 55.425191] process_request_key_err: No key
[ 55.425191] Could not find valid key in user session keyring for sig specified in mount option: [...]
[ 55.425192] One or more global auth toks could not properly register; rc = [-2]
[ 55.425193] Error parsing options; rc = [-2]

So is this also this bug?

[Thorsten (thorstenr-42)]

i have to add that this message only occurs on the first login after a reboot.

[Sergio Callegari (callegar)]

I see the same as @Thorsten. I have an encrypted Private directory. If I log into my user account the directory is correctly mounted. However, I still see the same error message as @Thorsten via dmesg.

[Pavel Grishkov (pgrishkov)]

I faced the same issue after upgrading from Ubuntu 17.04 to 17.10 a day ago.
I'm having my home directory encrypted and I'm getting the same error message after every first login.
My home directory is mounted correctly though.

As an even worst consequense I'm not able to login into grafical environment at all: Gnome keeps crashing when I click on my user name (I even do not have a chance to enter password). Not sure, however, if this is related to the encryption issue; I'm still checking.

[Pavel Grishkov (pgrishkov)]

Okay, the issue with failing X server in my case was not relevant to the encryption errors and was resolved by completing the upgrade process properly:
sudo apt-get update && sudo apt-get dist-upgrade
So this one was more related to the broken upgrade process for 17.04-17.10, so please disregard this part.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Forest (foresto)]

The ecryptfs-manager workaround helps the mount to succeed, but (at least in my case) the system refuses to unmount it afterward. This is a problem for those of us who open our ecryptfs volumes only for as long as they're needed.

[Forest (foresto)]

This is a systemd bug, created by this commit:

https://github.com/systemd/systemd/commit/74dd6b5

It looks like poettering has attempted to address it in more recent versions of systemd (though that doesn't help us in ubuntu 17.10):

https://github.com/systemd/systemd/pull/6832

[Forest (foresto)]

Here's a simple patch to disable the broken systemd feature, and restore ecryptfs functionality.

[Forest (foresto)]

A systemd build with my patch applied is available here:

https://launchpad.net/~foresto/+archive/ubuntu/ubuntutweaks/

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "disable_system_service_session_keyrings.patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

[forevertheuni (forevertheuni)]

This doesn't happen in 18.04.

[Xavier Guillot (valeryan-24)]

I don't agree with the last comme,nt : I have a fresh install of 18.04 and get the same error when trying to recover my old savec Private directory :

Enter your MOUNT passphrase:
mount: /tmp/ecryptfs.fSC9TkTG : échec de l’appel système mount(2) : Aucun fichier ou dossier de ce type.
ERROR: Failed to mount private data at [/tmp/ecryptfs.fSC9TkTG].

[Christian Toffolo (ianxxx)]

Same as @Thorsten and @callegar. I see the error messages but everything works fine.
I also just upgraded to 18.04 from a fresh install of 17.10 and the errors are still present.

[Sergey Ponomarev (stokito)]

I upgraded from Ubuntu Mate 17.10 to 18.04 after reboot I passed GRUB then I saw logo of Ubuntu Mate and then by screen become black witout anything.
I pressed Ctrl+F1 and swithed to tty1 then logged in and it show me three last errors from dmesg and firts was:
"could not find valid key in user session for sig "
"errorparsing options rc = -2"

So the problem is still present.
Meanwile I checked via mc (midniht commander) and I see that almost all files in my home directory was mounted.
My ~/.ecryptfs/Private.sig file contain two signatures.
I tried a workaround mentioned here: ecryptfs-manager, then press 4 to exit, then run ecrypt-mount-private but this doesn't helped

[Jaume (minterior)]

Same as @stokito happened to me. Yesterday I upgraded to Kubuntu 18.04 via "do-release-upgrade" command from a previous install of Kubuntu 17.10 did some half a year ago. When I restart the system I see the Kubuntu Plymouth start screen but then it never arrives to the login screen (sddm). I can login normally in any of the tty's seeing my home correctly decrypted but with these errors:

Could not find key with description: [<key>]
Could not find valid key in user session keyring for sig specified in mount option: [<key>]
Error parsing options; rc = [-2]

Also tried the aforementioned workaround "ecryptfs-manager" but sddm doesn't start either. Also tried installing lightdm with no luck.

[Sergey Ponomarev (stokito)]

Ok, so I restored my system and I got back to my Mate and all my settings are kept.
I did a lot of things, even removed ecryptfs while extracted all my home directory from it.
I removed NVidia drivers but I don't think that they caused the problem.
But only reinstalling of XServer finally resolved the problem. I did something like described here:
https://www.computersnyou.com/4945/re-install-xorg-xserver-completely-ubuntu/

Hint: if you get "Ubuntu Black Screen" then on GRUB item press "e" to edit menu item then replace "no splash" or "splash quit" with nomodeset and press F10.

Thus I think the problem was caused by some tricky X11 configs upgrade.

[Hadmut Danisch (hadmut)]

ecryptfs (private mount) still does not work under 18.04.

That's a complete showstopper for the upgrade 16.04->18.04 because access to encrypted files becomes impossible or at least troublesome.

[Hadmut Danisch (hadmut)]

Please keep in mind that ecryptfs-mount-private and mount.ecryptfs_private are slightly different things.

Since ecryptfs-mount-private is a frontend to the underlying mount.ecryptfs_private, and this isn't working either (also not under 18.04), it is vital to focus on fixing that.

I found that keyctl shows different things under 16.04 and 18.04 after doing ecryptfs-add-passphrase.

[Hadmut Danisch (hadmut)]

Even a direct

mount -t ecryptfs -o ecryptfs_check_dev_ruid,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs /tmp/work /tmp/a

fails with
[-2] No such file or directory

[Hadmut Danisch (hadmut)]

Ooops, no, sorry, it works (/tmp/a was missing).

So the kernel is definitely able to mount the file systems, it's just that ecryptfs-utils and their key management do not work.

[Juan Manuel SA (jumasa)]

I had the same problem with Debian.
The workaround I used is creating a link from the key to the keyring

keyctl link @u @s

[forevertheuni (forevertheuni)]

Something intriguing is that I updated to a 18.04 when it was still not released (I don't know if it was beta or not. I did it in March. Everything was fine. Everything mounted without any workaround with: mount.ecryptfs_private blabla
Suddenly around April when new updates came, it went back to having this bug.

[Redsandro (redsandro)]

#26 fixed this for me.

Doing a manual mount like so (used for safely storing private data in the cloud) used to work since Ubuntu 12 or so.

However, today after updating from Ubuntu 16.04 LTS to 18.04 LTS, the entire thing wouldn't mount anymore:

```
$ echo mypassphrase | sudo ecryptfs-add-passphrase --fnek -

Inserted auth tok with sig [abc] into the user session keyring
Inserted auth tok with sig [123] into the user session keyring

$ sudo /bin/mount -it ecryptfs "/media/locked" "/media/unlocked" -o ecryptfs_cipher=aes,ecryptfs_key_bytes=32,ecryptfs_sig=abc,ecryptfs_fnek_sig=123

mount: /home/local/Dropbox.unlocked: mount(2) system call failed: No such file or directory.
```

I read the following messages in `/var/log/syslog`:

```
kernel: [ 5608.396634] Could not find key with description: [abc]
kernel: [ 5608.396641] Could not find valid key in user session keyring for sig specified in mount option: [abc]
```

Apparently there are different keyrings now.

This fixed my script:

```
$ sudo keyctl link @u @s
$ sudo /bin/mount -it ecryptfs "/media/locked" "/media/unlocked" -o ecryptfs_cipher=aes,ecryptfs_key_bytes=32,ecryptfs_sig=abc,ecryptfs_fnek_sig=123
```

For now everything works again, but the thing seems buggy. Ubuntu even dropped the encrypted home because of it.

Ecryptfs seems to be eol. Looking for fresh solutions to protect the privacy of my cloud files.

[Bill Dietrich (billdietri123)]

I see the messages (starting with "Could not find key with description") on a fresh install of Linux Mint 19 Cinnamon.

Second line of kern.log says: "Linux version 4.15.0-36-generic (buildd@lgw01-amd64-031) (gcc version 7.3.0 (Ubuntu 7.3.0-16ubuntu3)) #39-Ubuntu SMP Mon Sep 24 16:19:09 UTC 2018 (Ubuntu 4.15.0-36.39-generic 4.15.18)"

[Carlos Eduardo Moreira dos Santos (cemsbr)]

This started happening after installing lubuntu-desktop. Even after removing it, it is still failing to mount. After running "keyctl link @u @s", it works.

[Carlos Eduardo Moreira dos Santos (cemsbr)]

Note: I'm using 18.04

[ZdravkoG (zdravko-g)]

I'm using 18.04, everything up to date.
ecryptfs is used for home encryption. Everything seems to work fine, but error messages (as already noted above) appears. Not to repeat everything already said, additional note could be that the messages are not tagged where they really comes from. It is a good practice (at least) everything in the system log to be explicitly clear where it comes from (as in most cases).

[Massimo S. (smassimo)]

I had updated my laptop so to Ubuntu 18.10 64bit and the message is still present for me.

I see the messages (Could not find key with description...) in dmesg output but all works fine.

[Lucas Levrel (llev)]

Trying to mount a personnal dir (not home) with ecryptfs-simple fails, with the same error messages in kern.log as comment #20. (Using Linux Mint 19, Xfce.)
The workaround in comments #26 and #30 works for me. (No sudo like in #28 : with sudo the mount works but the key sig gets added to /root/.ecryptfs . So keyctl has to be launched by thenormal user.)

This bug affects a cryptographic (read: highly sensitive) feature, is 15 months old, a patch was proposed 12 months ago, but it is still of "Undecided" importance and still "Unassigned"? Come on! Are the ecryptfs-utils and systemd packages unmaintained at Ubuntu?

The maintainer of ecryptfs-utils, Dustin Kirkland, is only listed as "may be notified" in the list of subscribers! The group maintainer of systemd, "Ubuntu Developers", is not listed at all!

[Lucas Levrel (llev)]

I could automate the workaround #26 and #30 but putting the said command in my .profile

[Andreas Schirra (preludi)]

This bug affects me too

[BarsMonster (3-y)]

Still actual in 18.04.
This looks scary.

[Marco Lobbia (embcen)]

Still the issue persist at present, Ubuntu 18.08 LTS.
The workaround suggested in the bug description works, but for how long I wonder?
Would you trust this bugged ecryptfs to manage sensible data?

[Kevin Otte (nivex)]

I would not trust ecryptfs anymore.
https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/1756840
Use the time to migrate your data.

[G.M. (sexxxenator)]

This error message is still pressent in my logs in XUbuntu 19.04 (freshly updated as of today). But the mounting finally occurs. However it is still quite annoying...

[sgrey (sgrey)]

I have just encountered this issue on 18.04 with Linux 4.15.0-54-generic.

The proposed workaround does not work for me.

[ADTopkek (adtopkek)]

Upgraded from Ubuntu server 16 to 18 and I too am having this issue.

[Julian Reith (julz224)]

Same here after upgrading Ubuntu Mate 18.04 to 19.04

[Forest (foresto)]

Still broken in disco.

[Forest (foresto)]

The systemd patch I posted earlier no longer works in disco, and the workarounds posted here only partially fix the problem and only for a subset of use cases. Looks like we're back to needing a proper fix.

[Peter Schüller (schueller-p)]

I have a completely encrypted home (auto configured) in bionic and have the same error messages in dmesg. Moreover, since a few weeks ago, the home directory sometimes gets broken in a way that all list requests (ls, browse in nautilus) hang just on the home directory (process in S state) and only a reboot solves this. I found the dmesg messages only because of these hangs which might be unrelated.

[arQon (pf.arqon)]

#34 said:
This bug affects a cryptographic (read: highly sensitive) feature, is 15 months old, a patch was proposed 12 months ago, but it is still of "Undecided" importance and still "Unassigned"? Come on! Are the ecryptfs-utils and systemd packages unmaintained at Ubuntu?

Well, this bug is now over TWO YEARS old, and is still broken in 19.10.

Expecting the systemd devs to care is, frankly, naive. I would have expected Canonical to at least do SOMETHING by now, even if it was just to add the keyctl hack to .profile, but that still leaves a ton of problems like non-root users never being unable to unmount their encrypted data - especially when you add in the OTHER systemd bugs that cause it to stay mounted and unencrypted even after logout.

The problem here is that Kirkland was the one who was hot for ecryptfs, and he left Canonical a long time ago. While he may technically still be listed as the maintainer of the package, he clearly gives 0 f**ks about it. (He was still on Ubuntu staff when this bug first surfaced, and didn't even care THEN when it was literally (part of) his job, so it's no surprise he still doesn't now).

The package needs to be demoted out of the repos, and the default behavior for encrypted /home changed to use something else - anything else, really - if it hasn't been already. In the meantime, the best thing you can do is just warn people not to use it, because at 2 years and counting I wouldn't hold my breath waiting for it to ever get sorted out...

TLDR: use the keyctl hack from #26 to get your data back, then get the hell off ecryptfs as fast as possible.

[Zac Witte (zacwitte)]

This affects me too. I started seeing the error in dmesg after upgrading from 16.04 to 18.04. Everything seems to work fine, but the message is scary.

[Matt Palmer (mattpalms)]

I just upgraded from 16.04 to 18.04 and I'm seeing the same/similar issue. I have the same messages in the log, and I have an encrypted home folder.

When I *first* try to log in after a reboot, I get bounced back to the login screen. It then logs in on the second attempt (so far - but this makes me nervous). None of the fixes above have worked for me so far.

[pEEAT (peatrick)]

This is truly unfortunate -- my little media server started off life as an Ubuntu Server 17.04 _Zesty Zapus_ VM, but has been working for years now as 18.04.x and recently failed an upgrade to 20.04 i believe (at least in part) due to this nagging issue. I'm not able to work around it with my limited skillset, unfortunately. At a loss, probably going to have to rebuild my entire media server. Just wanted to chime in that this has been a persistent issue for quite some time. Lesson learned, will stick to LTS releases for my major appliances moving forward. Thanks for everyone working on this!

[Kenneth Sartre (kkyuconn)]

Same issue here some time after upgrading from 16.04 lts to 18.04 lts. These error messages appear after reboot:
[ 61.411306] Could not find key with description: [...]
[ 61.411344] Could not find valid key in user session keyring for sig specified in mount option: [...]
[ 61.411383] Error parsing options; rc = [-2]

Note: ssh login when `PasswordAuthentication: no` denies connection since this bug.

[marius (marius-cobzarenco)]

I am getting exactly the same issue here after upgrading from 18.04 to 20.04. I use a custom folder and have some shell utilities to run the mount command with the right paramaters. Below SIG and FNEK_SIG continue to match what `ecryptfs-add-passphrase --fnek` reports (and the same as before the update). I am seeing the same in kernel logs via `dmesg` as OP reported.

mount -t ecryptfs /home/marius/Dropbox/private /home/marius/private -o ecryptfs_sig=<SIG>,ecryptfs_fnek_sig=<FNEK_SIG>,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_passthrough=n

$ uname -mrs Linux 5.4.0-37-generic x86_64

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 20.04 LTS
Release: 20.04
Codename: focal

[Forest (foresto)]

I hate to say this, folks, but ecryptfs looks like a dead end for us. It's no longer supported by Ubuntu (the package has been moved to the Universe repo). Also, the problem at hand is caused by systemd, which is run by a man famous for releasing poorly-vetted, system-breaking software, and then refusing to fix the damage he causes.

For a year or so, I maintained a systemd patch to work around this bug. (It is posted above, but no longer applies to current systemd code.) There was a time when it looked like the problem was finally fixed upstream, but then it just broke again.

Anyone who (like me) has been using ecryptfs to encrypt a private directory and unlock it only when needed, might consider switching to gocryptfs. From a user's point of view, it works similarly to ecryptfs. There's also a handy GUI called SiriKali that works with it.
https://nuetzlich.net/gocryptfs/
https://mhogomchungu.github.io/sirikali/

Good luck.

[marius (marius-cobzarenco)]

@foresto Thank you for the message & background info on systemd -- it's very helpful to know when to give up trying.

In the end I followed your advice and stopped using ecrypts (I decrypted my files in a Docker container running 18.04, as I already updated to 20.04 and could not get it to work). Posting here for anyone else.

[arQon (pf.arqon)]

One additional note for anyone still stuck using this trainwreck for whatever reason:

Even if you use the keyctl hack to get mounting your private data to work, you will be unable to UNmount it because of bugs in ecryptfs-umount-private. The workaround for THAT bug is to just call "/sbin/umount.ecryptfs_private" directly.