Am 04.03.26 um 11:58 schrieb Jochen Sprickerhof:
* Paul Leiber <[email protected]> [2026-03-04 11:11]:
Hi Jochen,
Thank you for looking into this.
Long story short: The "fix" for bug 1034339 introduced the issue. Removing the
line
<pmvarrun>/usr/sbin/pmvarrun -u %(USER)</pmvarrun>
from pam_mount.conf.xml solved this issue (and brought back the issue from bug 1034339
when exiting a "sudo -i" session).
Am 03.03.26 um 15:57 schrieb Jochen Sprickerhof:
control: tag -1 moreinfo
control: severity -1 normal
Hi Paul,
* Paul Leiber <[email protected]> [2026-03-03 13:07]:
On a workstation PC running Debian Trixie, I have configured pam-mount so that
it mounts some samba shares with user data at login. That is working well for a
single user. However, I noticed that after logging out as a specific user A and
then logging in as another user B, the mounts from user A still exist (and vice
versa). This is of course not acceptable for several reasons (e.g. privacy,
security).
This is not a privacy or security issue as other uses can log in at the same
time to see the mounts. Thus downgrading severity.
I agree.
I found some ancient bug reports [1] where pam was not able to use root rights
and therefore couldn't unmount the volumes. I am pretty sure that this is not
the case here, as the bug was fixed long ago and I don't see this specific log
entry on my system.
Nit: reference missing.
Sorry.
https://bugs.launchpad.net/ubuntu/+source/libpam-mount/+bug/117736
I found several bugs in the Debian pam-mount package describing unmount not happening, but with other symptoms. In one of the reports, changing the "logout"-line in
/etc/security/pam_mount.conf.xml from <logout wait="0" hup="0" term="0" kill="0" /> to <logout wait="2000"
hup="0" term="1" kill="1"/> solved a similar issue. I changed this config line, but without a noticable effect.
What I noticed in the pam-mount logs while digging deeper was a line saying that "user A seems
to have other remaining open sessions". I then checked the session tracker in
/var/run/pam_mount/, and the numbers there don't seem to be correct. After the first login of user
A to a desktop, the value stored in "/var/run/pam_mount/user A" is 0x1. After logging
out, it is 0x2. With each new login, the number is increased by 1 after login and by 1 after logout.
With the help from Debian user mailing list, I executed strace -f -s 10000 -e
execve -p $(pidof login | tr ' ' ,) -o /tmp/strace_login before login and
logout. It gives the following output:
For reference: https://lists.debian.org/debian-user/2026/03/msg00015.html
For login:
9414 execve("/usr/sbin/pmvarrun", ["/usr/sbin/pmvarrun", "-u", "xxx"],
0x55ec223822c0 /* 11 vars */) = 0
For logout:
9483 execve("/usr/sbin/pmvarrun", ["/usr/sbin/pmvarrun", "-u", "xxx"],
0x55ec223822c0 /* 17 vars */) = 0
The results indicate that instead of decreasing the count at logout using
arguments '-o' '-1', the count is increased by the default value. Thus, the
session counter never reaches 0 and this prevents unmount.
I can't reproduce this. What I tried:
debvm-create -k ~/.ssh/id_ed25519.pub -r trixie -- \
--hook-dir=/usr/share/mmdebstrap/hooks/useradd \
--include=libpam-mount,libpam-mount-bin \
--customize-hook='truncate -s100M $1/image.img; mkfs.ext4 $1/image.img; sed -i \'$ i <volume
path="/image.img" mountpoint="/mnt" user="user" />\'
$1/etc/security/pam_mount.conf.xml'
debvm-run -s 2222
In a new terminal: ssh -p 2222 user@localhost sleep 5
In the debvm-run terminal:
Debian GNU/Linux 13 testvm ttyS0
testvm login: root (automatic login)
pam_mount password:[ 2.667557] RAPL PMU: API unit is 2^-32 Joules, 0 fixed
counters, 10737418240 ms ovfl timer
[ 2.690571] cryptd: max_cpu_qlen set to 1000
[ 2.754126] AES CTR mode by8 optimization enabled
Linux testvm 6.12.73+deb13-cloud-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.73-1
(2026-02-17) x86_64
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
root@testvm:~# [ 6.399162] loop: module loaded
[ 6.400183] loop0: detected capacity change from 0 to 204800
[ 6.405868] EXT4-fs (loop0): mounted filesystem
622fd4f2-5408-4187-907c-a7244c13fd25 r/w with ordered data mode. Quota mode:
none.
root@testvm:~# awk 1 /run/pam_mount/user # while the user is logged in
0x1
root@testvm:~# [ 14.870179] EXT4-fs (loop0): unmounting filesystem
622fd4f2-5408-4187-907c-a7244c13fd25.
root@testvm:~# awk 1 /run/pam_mount/user # after the logout
awk: cannot open "/run/pam_mount/user" (No such file or directory)
Also from the source code it is pretty clear that pmvarrun is run with -o -1.
Can you please provide a reproducer?
I can confirm that on a fresh Debian Trixie VM joined as a Samba domain member
and with a minimal pam_mount.conf.xml to mount a Samba share, pmvarrun is run
with the correct arguments:
On login:
command: 'pmvarrun' '-u' 'xxx' '-o' '1'
On logout:
command: 'pmvarrun' '-u' 'xxx' '-o' '-1'
Also, there is no file for the user in /var/run/pam_mount after logout, and
unmount is executed at logout.
Looking at the logs and the strace output, I assumed that the cause of the unmount not happening is
indeed that arguments "-o 1" and "-o -1" for pmvarrun are dropped.
What I then tried to find the cause:
1. To create a system similar to the workstation PC, I added missing pam
packages libpam-krb5 and libpam-systemd in the VM, with no effect on the
pmvarrun arguments.
2. I ran pam-auth-update on the workstation PC to restore configuration files
in pam.d, but the issue still existed.
3. I checked the versions of libpam-mount on both the workstation PC and the
VM, they are identical (2.20-3+b2).
4. I compared the pam_mount.conf.xml files. One difference seemed potentially relevant: On the workstation PC,
there is the line <pmvarrun>/usr/sbin/pmvarrun -u %(USER)</pmvarrun> which I added to solve an
issue described in bug 1034339 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034339. Success! Removing
that line resolved the issue of unmount not happening. However, it reintroduced the issue from bug 1034339
(output "HXproc_run_async: pmvarrun: No such file or directory" when exiting a "sudo -i"
session).
After some testing, it seems that this is not a bug and therefore can be closed.
Done.
However, there are two follow-ups:
1. Should bug 1129584 (this bug) be referenced in the bug report for bug
1034339 to avoid other users running into this issue?
Cced.
2. What could a better fix for bug 1034339 (this will probably make more sense
to discuss in the thread for bug 1034339)?
I wonder if it would help to move pmvarrun to /usr/bin, can you try?
That did the trick.
Thanks,
Paul
