From one of our Debian users:
The mtab locking code gives up too easily. If it can't obtain the lock
it just bails out without retrying, sometimes resulting in a dirty mtab
with the mount entry still there.
This causes autofs to think that the mount is still active and it
doesn't try to mount the autofs entry again when accessed.
I looked in the source code for umount (package: mount) and umount.cifs
(package: smbfs) for how each does the mtab locking. umount tries to get
the lock for a few seconds before giving up. umount.cifs just gives up.
So, if there are two umount processes running and one of them is
umount.cifs, and they both need to update mtab, umount.cifs will leave
its mtab entry there because it wasn't patient enough when trying to get
I think this bug is fixed in 3.3.0rc2, at least from the comments in the code
Can you please verify if this bug still persists?
Confirmed as fixed in 3.3.0 as I write (privately) to Steve French. Sorry for forgetting to come back to this bug et mention this here.
Original mail sent to Steve:
Steve (French), this is samba bug #4665 (umount.cifs: gives up too quickly when mtab is locked by another process)
Just a small mail to confirm that this bug is still here in 3.2.5 and
subsequent releases, but is fixed in 3.3.0 pre-releases where the
locking code has been apparently entirely rewritten.
There are probably several other bugs (reported in Debian and
forwarded to Samba's Bugzilla) related to mtab that are fixed in 3.3.*
Closing as fixed.
Also note that with the changes to the default behavior when mount.cifs is setuid, there is virtually no reason to ship umount.cifs anymore.