Basically, I have a script on a machine like this: sudo mount.cifs //$FILESERVER/share dir -ousername=$USER,uid=$USER,gid=$USER,file_mode=0775,dir_mode=0775 and each user has $FILESERVER set to their desktop machine. This is supposed to bring a share from their machine to /home/$USER/dir (share and dir is generally the same for everyone constant) This works fine with 2.6.18-4-k7 from Debian/etch, but under a self-compiled 2.6.20.3, something weird happened. When one user "winner" had his share mounted, another user "victim" was unable to mount his share, getting "mount error 20, not a directory" back from mount.cifs. Just to be sure, we tried rmdir and mkdir on dir, and mount.cifs between the two rejected due to lack of existance of dir. When user "winner" has his share unmounted, "victim" can mount, but the owner and group of the directory is "winner" (--verbose confirmed that uid="loser" et al were being passed to the kernel). Booting to 2.6.18 again has restored correct operation. This only happened that I'm aware of to the one pair of users. The mounts are against Windows XP SP2 machines, on a Samba 3 domain, the mountee runs samba as a domain member, but the users aren't running krb or winbind or anything. Any further debugging information required can prolly be gotten, although it might take a few days as we're using this server for development testing so I need to kick everyone off to boot back to 2.6.20.
Just a followup, I just replicated this behaviour on a 2.6.22 server (kernel from backports.org, otherwise the same as the original server) Same user and CIFS server box, too, although different uid. It _seems_ to be that the fourth person to mount was somehow preventing the fifth person from mounting with error 20, and when the fourth person unmounted, the fifth person would mount but the directory would show the fourth person's credentials. Replacing cifs with smbfs in the mount call fixed it. I wonder if it's related to #4530?
Turns out this was a permissions problem. The file server (Windows XP SP2) was on the domain, but the user had both local machine account and domain account with the same name and password. The share was granted access to the domain user, but the local filesystem only had permissions for the machine user. The command line given to mount.cifs and mount.smb didn't specify the domain of the user to mount as. I presume that cifs was happily able to mount as the domain user, but failed to get file access to the root folder, so produced the 'not a directory error'. Turning cifsFYI up (under cifs 1.52, 2.6.24 kernel) indeed showed a log where the server was connecting, getting a permission denied back during the process, and then unmounting again. On the other hand, mount.smb must have been connecting as the machine user, which passed the security checks and therefore was able to access the system. Further testing showed that the fourth-mount stuff I came up with earlier was in fact bogus. I suspect some the mentioned username clash went away when we unified our username mapping using winbind against our Samba PDC, or by upgrading kernels on the cifs client. Certainly in recent testing, the earlier-mentioned problem of the wrong user owning the files had gone away, and only the "mount error 20, not a directory" was reproducible. The error message isn't actually massively helpful if you don't realise what's going on, but that's not a cifs thing (traces show that cifs sent back "-13 permission denied" correctly) but a vfs thing.
*** Bug 5230 has been marked as a duplicate of this bug. ***