Talk:Pam mount

system-auth template out of date

I think this page is out of date. On my system the /etc/pam.d/system-auth file did not match the template. Further, I had problems with the ordering caused by pam_systemd.so in /etc/pam.d/system-login. I had to load pam_mount after that in order to get volumes to mount and unmount properly. Finally, just modifying /etc/pam.d/system-login worked fine with KDE/KDM so I wonder if any display managers actually need customization. I don't know enough about PAM or pam_mount to make changes. Dshub (talk) 12:11, 16 May 2014 (UTC)

automatic unmounting and systemd

Also unmounting does not work correctly out of the box with Arch Linux. The systemd module drops root privileges and therefore unmounting cannot happen. If your journal has something like:

systemd[474]: (pam_mount.c:538): * PAM_MOUNT WAS INVOKED WITH INSUFFICIENT PRIVILEGES (euid=1002)

systemd[474]: (pam_mount.c:539): * THIS IS A BUG OF THE CALLER. CONSULT YOUR DISTRO.

It is not a bug but instead a problem due to the lack of privileges while trying to unmount. If you read http://sourceforge.net/p/pam-mount/pam-mount/ci/master/tree/doc/bugs.txt#l88 you will find a mention of this. —This unsigned comment is by Cramsan (talk) 16:12, 26 August 2014. Please sign your posts with ~~~~!

Automatic unmounting does work with a properly configured PAM stack. There are two old Forum-Threads relevant to the solution of this problem: [1] [2] Props to the people who originally worked this out. In short, the trick is to seperate pam_mount from system-auth, since that is run by systemctl --user, and place it in its own file. Then, include that file in system-local-login, system-remote-login and the file corresponding to your login-manager. In my case it currently looks like this:

/etc/pam.d/homedirs

#%PAM-1.0

auth      optional                   pam_mount.so
password  optional                   pam_mount.so
session   required                   pam_mkhomedir.so     skel=/etc/skel umask=0022
session   optional                   pam_mount.so

/etc/pam.d/system-local-login

#%PAM-1.0

auth      include   system-login
auth      include   homedirs
account   include   system-login
account   include   homedirs
password  include   system-login
password  include   homedirs
session   include   system-login
session   include   homedirs

/etc/pam.d/lightdm

#%PAM-1.0

auth      include   system-login
auth      include   homedirs
-auth       optional    pam_gnome_keyring.so
account   include   system-login
account   include   homedirs
password  include   system-login
password  include   homedirs
session   include   system-login
session   include   homedirs
-session    optional    pam_gnome_keyring.so auto_start

I'd add this information to the article, if nobody has any objections. Your feedback is welcome.

--Gondlar (talk) 22:58, 8 August 2016 (UTC)

Hi, interesting solution and references. It would be great to fix the unmount problem for good. Ideally any update would create uniform instructions for the different login managers. What I wonder is: Recently this edit suggests that the system-auth template works for GDM. This seems contrary to your solution for lightdm. I'm puzzled on why it should behave differently for the login-managers, but maybe the author of the gdm edit just did not touch upon the problem since it is mentioned separately in the warning top of the article. Any other idea?

What I'll try myself one of the next days is whether your solution helps fixing the same problem for ecryptfs.[3] --Indigo (talk) 19:10, 10 August 2016 (UTC)

I've tested the configuration currently presented in the article with gdm in a virtual machine, but without further modification of gdm's pam files. It works in the sense that the volume in question got mounted, however unmounting does not work out of the box. I suppose a configuration similar to the one I suggested above would also work with gdm although I have not explicitly tested that. However, I'va spotted one major difference between gdm and lightdms pam config: while lightdm includes system-login directly, gdm includes system-local-login. So, there would be no need to adjust gdms pam configuration but only system-local-login and system-remote-login, which is needed anyway. It might be worth considering to change the default lightdm configuration accordingly. --Gondlar (talk) 22:42, 11 August 2016 (UTC)

Yes, that would be a FS# for lightdm. It also shows that your existing config above has redundancy, because it doubles the calls (see the examples in PAM#PAM base-stack). Put together, the change your config does is ordering. Including pam_mount.so (directly or via homedirs) in the lightdm or system-(|local|remote-)login policies like you do, leads to it being processed after the problematic systemd.so.

I have now tried it with ecryptfs (both with console login/startx and gdm). The only change I did for that was move its pam policies (see ECryptfs#Auto-mounting) from system-auth to system-local-login. That worked fine (re mounting&unmounting). However, I had problems to reproduce the unmounting problem with the original stack. When I tried a couple of times before the change, unmounting worked too. I have seen this before. The unmounting problem appears to be a sporadic issue (at least for ecryptfs, I have not installed pam_mount on Arch). I believe it depends on how much and which processes are started. Hence, just logging in and out does not bring up the error consistently.

Before the article is changed, can you perhaps try the following? - (1) Add your homedirs include to system-login, but only after any systemd.so call, (2) remove your changes to lightdm and system-local-login (system-auth default i.e. without pam_mount) and (3) test that. Perhaps that is enough for unmounting to work; it would be a change that is more universal for the different login managers. Thanks. --Indigo (talk) 08:39, 13 August 2016 (UTC)

My solution does not simply reorder the calls! I am not sure if reodering fixes the permission problem, however there is another issue with pam_mount: It counts calls to determine whether a user is still logged in or not. Since both system-login and system-auth are called from systemd-user that messes with the count and pam_mount does not even try to unmount. You can see that in the log by the following messages (if debugging on pam_mount is enabled):

journalctl -f

Aug 13 22:31:49 vm-pamtest gdm-password][496]: (pam_mount.c:706): received order to close things
Aug 13 22:31:49 vm-pamtest gdm-session-worker[496]: (pam_mount.c:706): received order to close things
Aug 13 22:31:49 vm-pamtest gdm-password][496]: command: 'pmvarrun' '-u' 'gondlar' '-o' '-1'
Aug 13 22:31:49 vm-pamtest gdm-session-worker[496]: command: 'pmvarrun' '-u' 'gondlar' '-o' '-1'
Aug 13 22:31:49 vm-pamtest gdm-session-worker[496]: (pmvarrun.c:254): parsed count value 2
Aug 13 22:31:49 vm-pamtest gdm-password][496]: (pam_mount.c:441): pmvarrun says login count is 1
Aug 13 22:31:49 vm-pamtest gdm-session-worker[496]: (pam_mount.c:441): pmvarrun says login count is 1
Aug 13 22:31:49 vm-pamtest gdm-password][496]: (pam_mount.c:735): gondlar seems to have other remaining open sessions
Aug 13 22:31:49 vm-pamtest gdm-session-worker[496]: (pam_mount.c:735): gondlar seems to have other remaining open sessions
Aug 13 22:31:49 vm-pamtest gdm-password][496]: (pam_mount.c:743): pam_mount execution complete
Aug 13 22:31:49 vm-pamtest gdm-session-worker[496]: (pam_mount.c:743): pam_mount execution complete

My configuration therefore deliberately removed it from the systemd-user execution path, moving it up the stack does not. Even though, I ran you test, and the volume is not unmounted.

Thanks for testing again. I missed to look into /etc/pam.d/systemd-user before. So that does not work. The debug output is helpful in that it shows the unmounting fails after a couple of tries due to open session renmants. What I'm unsure is why you don't see this as an ordering issue, but that may be just a matter of defining what "ordering" includes. Anyhow, it does not matter at this point. Please go ahead to merge your solution into the article as planned/you think is best. --Indigo (talk) 23:19, 13 August 2016 (UTC)

I have made a change to the config presented which adds in a check to see if the systemd-user is "here" and if so skip over the pam_mount session which mounts the volume. That will already have been done by the actual user login process. You should be able to verify that this is working correctly by watching the file /var/run/pam_mount/<username> which simply contains the login count, also watch journalctl - there should no longer be lots of pam_mount errors in red relating to permissions. Gerdesj (talk) 12:24, 24 May 2017 (UTC)

Tested current (07.Sep.2017) config on this page - works fine on first reboot with SDDM/LxQt/LUKS encrypted volume.Nesk (talk) 09:13, 7 September 2017 (UTC)

[Moved from User talk:Kynikos#pam_mount page clarification. -- Kynikos (talk) 11:57, 27 September 2017 (UTC)]

About your edit on 11:36, 26 September 2017‎ - that warning is related to either both "General setup" and "Login manager configuration" sections or just the latter one. I'm using both configs and it's not working. Judging from talk page the problem is in "Login manager configuration" section, but I'm not 100% sure. Nesk (talk) 12:20, 27 September 2017 (UTC)

Thanks Nesk! Are you proposing to move the Warning back in the introduction? I really don't mind too much :) -- Kynikos (talk) 11:59, 27 September 2017 (UTC)

Yes. Nesk (talk) 12:20, 27 September 2017 (UTC)

Special:Diff/491400/491553 -- Kynikos (talk) 14:16, 27 September 2017 (UTC)

Configuration for crond

I'm trying to setup /etc/pam.d/crond in order to let the cron jobs access the encrypted drive mounted with pam_mount. The configuration of pam-d/crond is crucial to be able to backup the disk using automatic backup solutions (backintime in this case). Can someone help me in figuring out how to correctly setup that file? I've tried to place session optional pam_mount.so in different positions but I'm not able to properly mount the disk.

—This unsigned comment is by Simgunz (talk) 21:34, 12 September 2016‎ (UTC). Please sign your posts with ~~~~!

Failure messages when home is already mounted

The main article has a tip to avoid error messages when logging in for a second time. This messages are tipically caused because pam_mount tries to mount the home directory when it is already mounted.

The tip says to include this line before the session pam_mount configuration:

session [success=1 default=ignore] pam_succeed_if.so service = systemd-user quiet

Unfortunately that doesn't seem to work.

However, I've found another way to achieve the same goal. Instead of that line configure pam_exec to run a script to check if the home folder is already mounted:

session [success=1 default=ignore] pam_exec.so /usr/local/bin/is-pam-user-home-mounted

The contents of the is-pam-user-home-mounted script follow:

/usr/local/bin/is-pam-user-home-mounted

#!/bin/bash

C=$(mount | grep "on /home/$PAM_USER " | wc -l)

if [ "$C" == "1" ]
then
    exit 0
else
    exit 1
fi

—This unsigned comment is by Izaera (talk) 09:33, 26 January 2021‎ (UTC). Please sign your posts with ~~~~!

The pam_succeed_if line does not solve double login errors, only double mount errors in a single login. I've added more details: [4].

Also your script can be simplified to just a single command: mountpoint -q "/home/$PAM_USER"

-- Lahwaacz (talk) 20:19, 2 April 2021 (UTC)