I have setup the standard home ~/Private directory. It looks like it is
confused about which key to use.

For the last few months or so, I get this (key IDs changed but consistent
in report):

$ ecryptfs-mount-private
Enter your login passphrase:
Inserted auth tok with sig [aaaaaaaaaaaaaaaa] into the user session keyring
mount: No such file or directory

The kernel reports:
Jul 30 07:43:31 elmo kernel: [225198.624579] Could not find key with description: [bbbbbbbbbbbbbbbb]

And plenty of other messages, all about the second key with ID bbbbbbbbbbbbbbbb

These are the two keys:
$   keyctl list @u
2 keys in keyring:
270246897: --alswrv  1000  1000 user: bbbbbbbbbbbbbbbb
996876983: --alswrv  1000  1000 user: aaaaaaaaaaaaaaaa

The work-around. Is given below.
Note that I overrode the fnek signature on the command line.

$ ecryptfs-unwrap-passphrase .ecryptfs/wrapped-passphrase
Passphrase: (enter your usual passphrase)
PPPPPPPPPPPPPPPP
(write down this unwrapped passphrase)

$ sudo ecryptfs-add-passphrase --fnek
Passphrase: (enter the PPPPPPPPPPPPPPPP)
Inserted auth tok with sig [aaaaaaaaaaaaaaaa] into the user session keyring
Inserted auth tok with sig [bbbbbbbbbbbbbbbb] into the user session keyring
udo mount -t ecryptfs /home/username/.Private/ /home/username/Private/
Select key type to use for newly created files:
 1) passphrase
 2) tspi
Selection: 1
Passphrase:
Select cipher:
 1) aes: blocksize = 16; min keysize = 16; max keysize = 32
 2) blowfish: blocksize = 8; min keysize = 16; max keysize = 56
 3) des3_ede: blocksize = 8; min keysize = 24; max keysize = 24
 4) twofish: blocksize = 16; min keysize = 16; max keysize = 32
 5) cast6: blocksize = 16; min keysize = 16; max keysize = 32
 6) cast5: blocksize = 8; min keysize = 5; max keysize = 16
Selection [aes]: 1
Select key bytes:
 1) 16
 2) 32
 3) 24
Selection [16]: 1
Enable plaintext passthrough (y/n) [n]:
Enable filename encryption (y/n) [n]: y
Filename Encryption Key (FNEK) Signature [aaaaaaaaaaaaaaaa]: bbbbbbbbbbbbbbbb
Attempting to mount with the following options:
  ecryptfs_unlink_sigs
  ecryptfs_fnek_sig=bbbbbbbbbbbbbbbb
  ecryptfs_key_bytes=16
  ecryptfs_cipher=aes
  ecryptfs_sig=aaaaaaaaaaaaaaaa
WARNING: Based on the contents of [/root/.ecryptfs/sig-cache.txt], it looks like you have never mounted with this key before. This could mean that you have typed your passphrase wrong.
Would you like to proceed with the mount (yes/no)? : yes
Would you like to append sig [aaaaaaaaaaaaaaaa] to [/root/.ecryptfs/sig-cache.txt]
in order to avoid this warning in the future (yes/no)? : no
Not adding sig to user sig cache file; continuing with mount.
Mounted eCryptfs

Hello,

1. The problem is the user keyring not being linked
to the session keyring.   keyctl link @u @s   is a much easier workaround.

2. For me this happens only in gnome sessions (not console or ssh)
Is this the same for you?

(see also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870335 )

Cheers,
Itaï.

I've got the same issue but this workaround didn't solve the issue.
(testing, package version 111-4 as this report)

The longer solution is a bit tricky to use, since the whole homedir is
encrypted and I am already logged in. Could I perhaps disable ecryptfs
and redo it from start? Got backups and all, not an issue.

I haven't seen that when running a graphical desktop (xfce, in my case)
or via ssh, only in console. Also, if I am already logged in, regardless
of the terminal, it won't happen but I assume this is to be expected.


Andrea.

keyctl link workaround works for me.

I'm using lightdm and slimmed down LXQt session.

What system component should link keyrings by design? DM, session lead, PAM, basic login scripts? I feel that this bug should be redirected accordingly.

So linkage of user and session keyrings is apparently done by pam_keyinit module.

There is a line:

    session    optional   pam_keyinit.so force revoke

in /etc/pam.d/login, but not in /etc/pam.d/lightdm.

Dear Maintainer,

   * What led up to the situation?

I'm trying to mount my Private directory in a script called by .xsession
and .xsession itself is being called by Nodm (or
lightdm-autologin-greeter).

   * What exactly did you do (or not do) that was effective (or
     ineffective)?

I created a script that calls mount.ecryptfs_private. It based on
ecryptfs-mount-private where I stripped the interactive passphrase
prompt and replaced it with a environment variable that my scripts
expects to contain the passphrase.

   * What was the outcome of this action?

When I manually login via ssh and run my script, it works. When the
same script is called by .xsession I get:

  mount: no such file or directory

like the OP. Same errors in the kernel log.

You can find full details in my debian-user mailing list post:

https://lists.debian.org/debian-user/2021/11/msg00002.html

Worked around by adding

   session    optional   pam_keyinit.so force revoke

to /etc/pam.d/nodm and rebooting the system.