I am trying to mount some cifs shares from a Windows Server 2003 domain server to a Debian Linux machine (sarge 3.1 with all available updates). I am getting often problems to mount the shares, but sometimes it is successfull. The Debian system uses a kernel 2.6.8-2 686-SMP, now updatet to 2.6.8-3-SMP. The problem is that if I try to mount a Windows share, then I get often the following error message: larch:/mnt/shares# mount share4/ mount error 11 = Resource temporarily unavailable Refer to the mount.cifs(8) manual page (e.g.man mount.cifs) (I am not sure if the problematic Component is kernel fs or userspace tool.) When I retry the command one or two times more, it is suddenly successfull, without changing anything else. What I also could observe, is that it mostly mounts 3 shares successfully, and then the 4th and 5th do not. It does not care which three shares I mount first, always the 4th fails. That also happens at boot time, as these shares are written in the fstab, so 2 of 5 shares were not mounted successfully at boot up. For your reference, here is a short example protocol of my doing: larch:/mnt/shares# ll total 8 drwxrwx--- 1 user user 0 Jun 23 15:07 share1 drwxrwx--- 1 user user 0 Jun 22 12:00 share2 drwxrwx--- 1 user user 0 Jun 21 10:50 share3 drwxr-xr-x 2 root root 4096 Jun 21 13:43 share4 drwxr-xr-x 2 root root 4096 Jun 21 13:44 share5 (so share 1-3 have been mounted, 4&5 not) larch:/mnt/shares# mount share4/ mount error 11 = Resource temporarily unavailable Refer to the mount.cifs(8) manual page (e.g.man mount.cifs) larch:/mnt/shares# mount share4/ mount error 11 = Resource temporarily unavailable Refer to the mount.cifs(8) manual page (e.g.man mount.cifs) larch:/mnt/shares# mount share4/ larch:/mnt/shares# ll total 4 drwxrwx--- 1 user user 0 Jun 23 15:07 share1 drwxrwx--- 1 user user 0 Jun 22 12:00 share2 drwxrwx--- 1 user user 0 Jun 21 10:50 share3 drwxrwx--- 1 user user 0 Feb 21 2005 share4 drwxr-xr-x 2 root root 4096 Jun 21 13:44 share5 (share4 now is mounted after 3 trys) here is the /etc/fstab (with changed servername, user and password, the user which should be able to access these shares is secretary) larch:/mnt/shares# cat /etc/fstab (...) //testserver/share1 /mnt/shares/share1 cifs nls=utf8,iocharset=iso8859-15,users,exec,rw,auto,username=testuser,password=testpasswd,uid=secretary,gid=secretary,file_mode=0770,dir_mode=0770 0 0 //testserver/share2 /mnt/shares/share2 cifs nls=utf8,iocharset=iso8859-15,users,exec,rw,auto,username=testuser,password=testpasswd,uid=secretary,gid=secretary,file_mode=0770,dir_mode=0770 0 0 //testserver/share3 /mnt/shares/share3 cifs nls=utf8,iocharset=iso8859-15,users,exec,rw,auto,username=testuser,password=testpasswd,uid=secretary,gid=secretary,file_mode=0770,dir_mode=0770 0 0 //testserver/share4 /mnt/shares/share4 cifs nls=utf8,iocharset=iso8859-15,users,exec,rw,auto,username=testuser,password=testpasswd,uid=secretary,gid=secretary,file_mode=0770,dir_mode=0770 0 0 //testserver/share5 /mnt/shares/share5 cifs nls=utf8,iocharset=iso8859-15,users,exec,rw,auto,username=testuser,password=testpasswd,uid=secretary,gid=secretary,file_mode=0770,dir_mode=0770 0 0
Hi, I also have this similar strange behavior. I'm running Debian Edge with the latest updates, kernel version 2.6.18-4-686, mount.cifs version: 1.10-3.0.24. I run samba for mounting Windows shares in order to create backups. If suddendly the mount of a share fails for some Windows machine, I get this error while I try to mount any other share of this machine. I do not get an error if I mount a share from another machine. The only workaround I could think of was, in the event of a mount failure, to unmount any mounted shares from the same Windows machine that has mount problems. But obviously, this workaround is not a good, robust and permanent solution. The problem should be tackled in the core programming somewhere. Below is the command I use to mount a share from a Windows machine : /bin/mount -t cifs -o ro,directio,mapchars,iocharset=utf8,user=backupusr,domain=somedomain,password=somepwd,ip=192.168.2.2,uid=root,gid=root //somewindowsmachine/someshare /mnt/mymountpointforthisshare Hopefully this leads the programmers in the right direction. Kind regards, Bart Boelaert.
Created attachment 2930 [details] Reestablish cifs session for a mount after a disconnection Hi I have reproduced the bug in the following case: - setup a Samba server with a short deadtime; - on a client side, mount a share, dont do anything with it but wait for the disconnection; - once disconnected, try to mount a share from the same server with the same credentials, you should get the error 11. Here is what happens in the cifs driver: - when Samba closes the connection to the idle share, it closes the socket; - the driver notices it, marks the current sessions as needing reconnection, and reestablishes the TCP connection; - on the next mount, the driver finds an existing cifs session for that particular server and wants to use it to mount the share ; but the session still needs to be reestablished. The patch is a small copy/paste from the reconnection part of smb_init, which seems to fix the problem. I am absolutely not sure if it is the right way to do it. Cheers, -- Matthieu
I am not able to recreate this bug. Against a Windows XP server, I can mount five shares without any errors. I do not see session disconnected to a share on a Samba server with [global] section having a parameter deadtime = 2
By the way, rc=-11 (EAGAIN) should be an internal error, not returned back to the user. We have not been able to reproduce this.