ecryptfs-mount-private fails to initialize ecryptfs keys

Bug #1718658 reported by Tomas Hlavacek on 2017-09-21
This bug affects 23 people
Affects Status Importance Assigned to Milestone
ecryptfs-utils (Ubuntu)
systemd (Ubuntu)

Bug Description

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>

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

no longer affects: ubuntu-mate
Tomas Hlavacek (tmshlvck) wrote :

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

tags: added: artful
Launchpad Janitor (janitor) wrote :

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

Changed in ecryptfs-utils (Ubuntu):
status: New → Confirmed
forevertheuni (forevertheuni) wrote :

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) wrote :

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) wrote :

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

Sergio Callegari (callegar) wrote :

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) wrote :

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) wrote :

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) wrote :

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

Changed in systemd (Ubuntu):
status: New → Confirmed
Forest (foresto) wrote :

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) wrote :

This is a systemd bug, created by this commit:

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):

Forest (foresto) wrote :

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

Forest (foresto) wrote :

A systemd build with my patch applied is available here:

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.]

tags: added: patch
forevertheuni (forevertheuni) wrote :

This doesn't happen in 18.04.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers