Hello, I can confirm that this bug is both reproducible and present in current etch's mount.cifs. And it's VERY annoing.
I can reproduce it on a server where I'm using libpam-mount for automounting user shares. The users are somewhat limited users that log onto the system using it as a terminal server. The relevant stanzas in /etc/security/pam_mount.conf are as follows: cifsmount /bin/mount -t cifs //%(SERVER)/%(VOLUME) %(MNTPT) -o "username=%(USER)%(before=\",\"OPTIONS)" volume * cifs fileserver.corporate.com home /mnt/&/home uid=&,gid=site.users,dir_mode=0750,domain=DOM - - volume * cifs fileserver.corporate.com shared /mnt/&/shared uid=&,gid=site.users,dir_mode=0750,domain=DOM - - This mounts the volumes... usually - libpam-mount constructs a proper and valid command, which looks like this: mount -t cifs //fileserver.corporate.com/shared /mnt/username/shared -ousername=username,uid=username,gid=site.users,dir_mode=0750,domain=DOM But for some reasons when users make an error during logon, the mount.cifs still sometimes [not always, unfortunately] writes into mtab that the mount exists. Every such fscked mount entry has to be removed from the /etc/mtab manually and the user has to re-login, which is PITA. (We cannot at the moment use our shiny fileserver appliance *and* provide the directories to the users via nfs, which would solve the problems, not until the end of the financial year ;-)) If you need more information, please specify what is needed. Kind regards Jubal -- [ Miros/law L Baran, baran-at-knm-org-pl, neg IQ, cert AI ] [ 0101010 is ] [ BOF2510053411, http://hell.pl/baran/tek/, alchemy pany! ] [ The Answer ] If we knew what the hell we were doing, then it wouldn't be research. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
