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 the lock.
I think this bug is fixed in 3.3.0rc2, at least from the comments in the code Christian Perrier
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.* as well.
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.