I'm running an Ubuntu 16.04 server with eCryptfs and samba.

User bob has created an encrypted private folder via ecryptfs-setup-private. The wrapping passphrase matches the linux login passphrase. When bob connects via SSH, his private folder is decrypted automatically. User bob has samba access to his home directory. The samba credentials match the linux login credentials.

The PAM configuration contains the default entries (created by Ubuntu and eCryptfs). /etc/fstab contains no entries specific to eCryptfs.


When bob accesses his private folder via samba from a Windows client, his private folder is not decrypted. The samba server log (/var/log/samba/some-client.log) contains

Signature not found in user keyring
Perhaps try the interactive 'ecryptfs-mount-private'

Further investigation

The same message occurs when bob opens a shell via sudo; it does not occur when bob opens a shell via su. Apparently, the user session keyring has different content depending on login method:

$ su -c 'keyctl show @s' bob
 887339582 --alswrv   1000 65534  keyring: _uid_ses.1000
 797923857 --alswrv   1000 65534   \_ keyring: _uid.1000
 523913245 --alswrv   1000  1000       \_ user: 363f394f32249cc4
 840141489 --alswrv   1000  1000       \_ user: 905f555cf7fd10e0

$ sudo -i -H -u bob -- keyctl show @s
Signature not found in user keyring
Perhaps try the interactive 'ecryptfs-mount-private'
 887339582 --alswrv   1000 65534  keyring: _uid_ses.1000
 797923857 --alswrv   1000 65534   \_ keyring: _uid.1000

It seems that the login credentials are missing in the keyring when using sudo.

I suppose that when I find a solution for the sudo case, it can be applied to the samba problem.

I tried changing /etc/pam.d/sudo to the contents of /etc/pam.d/su, but it had no effect. I've read about ecryptfs-add-passphrase and pam_cifscreds, but don't know if and how one of these could be helpful here. I've browsed through the wikis of ubuntuusers.de and Arch Linux, found several questions on StackOverflow and unix.stackexchange.com (references are omitted due to low reputation), but did not find a solution yet.

  1. What is necessary for eCryptfs to use the login credentials in the sudo case?
  2. What is necessary for eCryptfs to use the login credentials in the samba case?

This is a long standing bug


ecryptfs does not work properly over nfs, cifs, samba, WebDAV, or aufs

Workaround - use sshfs : https://bugs.launchpad.net/ecryptfs/+bug/277578/comments/8

Other options: File a bug report re: sudo / su if you wish.

  • From my point of view, the reported bug does not apply here. It describes a crash when Samba, CIFS or NFS is used as underlying file system (which contains the private folder). This is not the case here. I have to stick with samba because all clients support it natively, so using sshfs as alternative is not an option. – Christian Aug 17 '17 at 4:31
  • @Christian Then file a new bug report =) – Panther Aug 17 '17 at 18:21

After further investigations I can answer the question by myself: it is not possible to use sudo or samba credentials to automatically decrypt an eCryptfs private folder on login because the password is unknown in either case.

1.) sudo

Let's assume that user alice calls sudo -u bob. Alice doesn't need Bob's password for that; she uses her own password. Thus, Bob's password is not known and cannot be added to the user keyring or used by eCryptfs. That's a difference to su which requires bob's password. Therefore it is possible to auto-mount an eCryptfs folder with su but not with sudo.

2.) Samba

My observation was that the login credentials are missing in the user session keyring. I thought that maybe samba does not add them by default, so I searched for a way to do it manually.

After a little bit of research I found the PAM module pam_cifscreds which may be used to provide user credentials to the kernel - sounds good. I added pam_cifscreds.so to both PAM facilities auth (to store the password in the keyring) and session, but had no luck. With the debug argument set, the session call wrote the message no stored password found to the log; the auth call was not visible.

Further research lead me to another PAM module pam_script and its example file logscript which may be used to trace PAM calls. It revealed that the session facility is called on every samba client connect but the auth facility isn't. Then I found this paragraph in the smb.conf PAM Configuration:

Samba always ignores PAM for authentication in the case of encrypt passwords = yes. The reason is that PAM modules cannot support the challenge/response authentication mechanism needed in the presence of SMB password encryption.

Nowadays, a samba client does not send the clear-text password but a hash value to the server. Thus, the server has no access to the password and cannot add it to the keyring.

It is probably possible to change the samba configuration to allow clear-text passwords, but I do not want that and thus didn't try it.


My idea of transparent server-side decryption based on samba login credentials is not possible, because the password is missing on the server.

There may be another option as workaround: if eCryptfs didn't use a single wrapped-passphrase file but one per login type (e.g. UNIX password, Samba, SSH certificate, ...), the mounting passphrase could be unwrapped depending on the login. But as implementing this idea seems quite complicated and time-consuming for me, I will not track it further.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.