On Ubuntu 20.04 – and I have encountered this with (vanilla) GNOME before – with KDE Plasma (no, not Kubuntu!), I am faced with a strange thing that happens every few hours or so and for which I have no explanation or remedy as of yet.
Somehow the ecryptfs-encrypted home folder which gets mounted when I log on "disappears" out of the blue. I mostly notice it due to weird symptoms starting to occur, such as all sorts of programs reporting files from
$HOME they can not find, which they deem corrupt or for which they simply report they can’t open them.
The first time this happens, I can usually run
/usr/bin/ecryptfs-mount-private, enter my passphrase and be done with it. Alas, this still doesn’t recover functionality of certain KDE desktop elements. As an example, I am unable search for installed programs from that point on and so everything that isn’t already running becomes unavailable until I log off and back on.
Subsequent times this happens and I attempt using
/usr/bin/ecryptfs-mount-private I usually see:
$ /usr/bin/ecryptfs-mount-private Enter your login passphrase: Inserted auth tok with sig  into the user session keyring mount: No such file or directory
Even logging off in such situation becomes a minor nightmare as you can see from the following screenshot. The dialogs pop up merely based on the fact that I am opting to log off!
So my questions (yeah, plural … since I’m currently at a loss how to even start diagnosing this):
- which entity could be causing this automatic removal of my
$HOME? … I was reminded of weird behavior like when sessions get purged when you log off and so suddenly your Screen or Tmux sessions also get killed (unless you use
- what are the steps to troubleshoot such an issue? (keep in mind that the desktop behaves all weird when this happens!). I tried to look at
journalctloutput and in the logs with ripgrep, but I don’t really know what terms to look for …
- suppose this is a known bug, what’s the workaround if any?
It reminds me a bit of Tmux/Screen getting killed when logging out, something I’d not normally expect and that can be prevented only by starting Tmux/Screen after logging into SSH (i.e. separate login session) or enabling session lingering.
The one thing I found with
journalctl which seems odd and correlates to the "lost" home directory is the following:
Sep 01 23:39:11 machinename smbd: pam_unix(samba:session): session closed for user username Sep 01 23:39:11 machinename systemd: home-username.mount: Succeeded. -- Subject: Unit succeeded -- Defined-By: systemd -- Support: http://www.ubuntu.com/support -- -- The unit home-username.mount has successfully entered the 'dead' state. Sep 01 23:39:11 machinename systemd: home-username.mount: Succeeded. -- Subject: Unit succeeded -- Defined-By: systemd -- Support: http://www.ubuntu.com/support --
… but that would indicate that something caused by the Samba daemon on behalf of my interactive user account leads to another part of the system assuming that I logged off and unmounting my
$HOME … that sounds exceedingly unlikely, no?
The above pattern
pam_unix(samba:session) closing a session for my username followed by the
$HOME folder becoming inaccessible is the the smoking gun, but also the only one so far. Currently reading up on how this whole session business is supposed to work and why that mount unit "thinks" it can "reap" my mounted home folder while I am still interactively logged on.
Edit #1: since the comment indicates that the configuration of Samba could be relevant, I am adding it here. I replaced my actual username with
username in the dump from
# Global parameters [global] dns proxy = No guest account = username log file = /var/log/samba/log.%m map to guest = Bad Password max log size = 1000 obey pam restrictions = Yes panic action = /usr/share/samba/panic-action %d passwd chat = *Entersnews*spassword:* %nn *Retypesnews*spassword:* %nn *passwordsupdatedssuccessfully* . passwd program = /usr/bin/passwd %u security = USER server role = standalone server server string = %h server (Samba, Ubuntu) syslog = 0 syslog only = Yes workgroup = NULL idmap config * : backend = tdb [scratchpad] force create mode = 0660 force directory mode = 0770 guest ok = Yes guest only = Yes path = /data/scratchpad read only = No
As you can tell nothing special, but my guess is that the fact that I am "defaulting" to my own user as guest user via global setting is somehow causing the login session to appear for my user.
There are no entries with
samba:session marker other than a handful more entries like the log line reproduced above.
Edit #2: my
/etc/pam.d/samba looks like this:
@include common-auth @include common-account @include common-session-noninteractive
… and so I attempted to edit those referenced files and add
debug (separated by a blank space) on every line that referenced either
pam_ecryptfs. The result – after a reboot – was that I could no longer log into KDE at all. It simply stalled. So I used one of the other terminals to log on as
root and revert my changes (which thanks to
etckeeper was trivial).
Edit #3: a temporary workaround is to disable session lingering for my user by setting … Edit 4: the workaround turned out not to work.
KillExcludeUsers=root username in
/etc/systemd/logind.conf or "locally" via
loginctl. Which makes this seem more and more like a defect.