Public bug reported: I am using KDE (kde-plasma-desktop, not Kubuntu) but I have seen this happening before with GNOME (vanilla-gnome-desktop); I basically switched ... the installation was a 20.04 "server" initially because the desktop installation media would not even boot on my machine. Either way, I am merely mentioning this, but the desktop environment doesn't really matter for this defect.
I have configured my desktop so that within my LAN certain shares can be accessed without user/password restrictions. For convenience I have mapped the guest account to my interactive user. This means files/directories created on the shares in question will automatically be owned by myself. Alas, every now and then, the ecryptfs home folder gets simply unmounted under my nose, WHILE I am _interactively logged on_ (i.e. in KDE). This happened several times and without a real pattern emerging which would give me clues. So I set out to track it down and found entries pertaining to smbd which tell me about a session being closed for my interactive user (redacted by substituting johndoe): =============================================== Sep 08 21:47:20 machine smbd[144802]: pam_unix(samba:session): session closed for user johndoe =============================================== Upon a closer look it turned out that this was the exact point when the ecryptfs home folder got unmounted (the above is merely exemplary of the issue, but that's already the reproduced occurrence, read on). Alright, so I saw that pam_unix is involved and smbd is involved. First I suspected that systemd was doing Its Thing™ and killing my processes (I had encountered this with Tmux before to my dismay) but even after setting "KillExcludeUsers=root johndoe" (and, yes, restarting logind) the problem first _seemed_ to have gone away, but it returned again. Notably there was no message about pam_unix opening a session for my interactive user for smbd. All research I did on how best to log what was going on w.r.t. the session management of smbd/PAM didn't get me any further. So I entered the trial&error phase of hunting down the root cause. Basically what I did was in Tmux to edit smb.conf while in another Tmux window having three things running (1 and 3 as root): 1.: while mountpoint /home/johndoe; do service smbd restart; date; sleep 2s ; done 2.: watch 'mount|grep ecryptfs' 3.: tail -F /var/log/auth.log|grep samba:session Fortunately this almost immediately yielded the desired result. The third time the loop body from 1. ran, the home folder was no longer mounted and the loop quit. Simultaneously I could see that mount no longer listed the home folder either and the auth.log received that "pam_unix(samba:session): session closed for user johndoe" ... In journalctl output (also lightly redacted) it looks like this: =============================================== Sep 08 21:47:20 machine smbd[144802]: pam_unix(samba:session): session closed for user johndoe Sep 08 21:47:20 machine systemd[1601]: home-johndoe.mount: Succeeded. -- Subject: Unit succeeded -- Defined-By: systemd -- Support: http://www.ubuntu.com/support -- -- The unit UNIT has successfully entered the 'dead' state. Sep 08 21:47:20 machine systemd[1]: home-johndoe.mount: Succeeded. -- Subject: Unit succeeded -- Defined-By: systemd -- Support: http://www.ubuntu.com/support -- -- The unit home-johndoe.mount has successfully entered the 'dead' state. Sep 08 21:47:20 machine systemd[1]: smbd.service: Succeeded. -- Subject: Unit succeeded -- Defined-By: systemd -- Support: http://www.ubuntu.com/support -- -- The unit smbd.service has successfully entered the 'dead' state. Sep 08 21:47:20 machine systemd[1]: Stopped Samba SMB Daemon. -- Subject: A stop job for unit smbd.service has finished -- Defined-By: systemd -- Support: http://www.ubuntu.com/support =============================================== So in short: smbd closing the login session for my interactive user via pam_unix also pulls the mounted ecryptfs home folder out right from under "my feet". As you can imagine the symptoms after the ecryptfs home folder are unavailable are pretty inconvenient and I found no other remedy than to log out and back in to mitigate it. Yes, I am aware of ecryptfs-mount-private but that only helps for programs I know how to restart. I was unable to get the Plasma shell to restart and so basically the application menu was no longer listing most of the programs ... But this means that evidently there is some session cleanup initiated by smbd which causes systemd to happily unmount my home folder. I apologize if this means I should have filed this with systemd as having the defect. It's presumably the interaction of both that causes this. The gist of the smb.conf (before my workaround) as produced by testparm looks like this (redacted path, share and user names respectively): =============================================== $ testparm|sed 's|'$(whoami)'|johndoe|g' Load smb config files from /etc/samba/smb.conf WARNING: The "syslog only" option is deprecated WARNING: The "syslog" option is deprecated Loaded services file OK. Server role: ROLE_STANDALONE Press enter to see a dump of your service definitions # Global parameters [global] debug uid = Yes dns proxy = No guest account = johndoe 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 = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* . passwd program = /usr/bin/passwd %u security = USER server role = standalone server server string = %h server (Samba, Ubuntu) syslog = 7 syslog only = Yes workgroup = NULL idmap config * : backend = tdb [sharename] force create mode = 0660 force directory mode = 0770 guest ok = Yes guest only = Yes path = /data/sharedir read only = No =============================================== MY WORKAROUND: Right now (and for my use case that's perfectly fine, it seems) I have have simply set "obey pam restrictions = no" in smb.conf and retried with my above trial&error method and the issue can no longer be reproduced. The version information requested in the Ubuntu bug reporting guidelines: =============================================== $ lsb_release -rd Description: Ubuntu 20.04.1 LTS Release: 20.04 $ apt policy samba samba: Installed: 2:4.11.6+dfsg-0ubuntu1.4 Candidate: 2:4.11.6+dfsg-0ubuntu1.4 Version table: *** 2:4.11.6+dfsg-0ubuntu1.4 500 500 http://de.archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages 500 http://de.archive.ubuntu.com/ubuntu focal-security/main amd64 Packages 100 /var/lib/dpkg/status 2:4.11.6+dfsg-0ubuntu1 500 500 http://de.archive.ubuntu.com/ubuntu focal/main amd64 Packages =============================================== If there is any information missing, please let me know and I'll try to amend the ticket. I also asked about this over here https://unix.stackexchange.com/q/607508/5462 ... ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: samba 2:4.11.6+dfsg-0ubuntu1.4 ProcVersionSignature: Ubuntu 5.4.0-47.51-generic 5.4.55 Uname: Linux 5.4.0-47-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu27.8 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: KDE Date: Tue Sep 8 22:09:33 2020 EcryptfsInUse: Yes OtherFailedConnect: Yes SambaServerRegression: Yes SmbConfIncluded: No SourcePackage: samba TestparmExitCode: 0 UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: samba (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug focal -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1894899 Title: smbd with "obey pam restrictions" enabled unmounts my interactive users' ecryptfs home directory To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1894899/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
