Comment 4 for bug 1377924

I've learned that the issue is not related to kernel version but caused by environment under which mount is executed.

On my systems (14.04), it fails when executed inside x2go session but manages to operate when connected via physical VT or SSH.

May be it's related to apparmor, but how x2go and ssh are different in that perspective? They both spawned as by sshd.
Also additional environments like vnc and rdp might be affected.

Below is strace of failing attempt.

===
"ecryptfs-add-passphrase --fnek" works but mount fails:
===
sudo strace mount -o no_sig_cache,ecryptfs_passthrough=no,ecryptfs_enable_filename_crypto=yes,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,passwd=dummy,ecryptfs_sig=xxxxxxxxxxxxxxxx,ecryptfs_fnek_sig=yyyyyyyyyyyyyyy -t ecryptfs /media/storage/backup/home/.ecryptfs/user/.Private /media/storage/backup/home/user
...
stat("/sbin/mount.ecryptfs", {st_mode=S_IFREG|0755, st_size=25880, ...}) = 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7fb366a0bb50) = 11423
wait4(-1, Unable to link the KEY_SPEC_USER_KEYRING into the KEY_SPEC_SESSION_KEYRING; there is something wrong with your kernel keyring. Did you build key retention support into your kernel?
[{WIFEXITED(s) && WEXITSTATUS(s) == 251}], 0, NULL) = 11423
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=11423, si_status=251, si_utime=0, si_stime=1} ---
exit_group(251) = ?
+++ exited with 251 +++
===