Bug 3857 - mount error 11 = Resource temporarily unavailable
Summary: mount error 11 = Resource temporarily unavailable
Status: RESOLVED FIXED
Alias: None
Product: CifsVFS
Classification: Unclassified
Component: user space tools (show other bugs)
Version: 2.6
Hardware: x86 Linux
: P3 normal
Target Milestone: ---
Assignee: Steve French
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-06-26 02:42 UTC by stefan matthäus
Modified: 2009-08-24 18:07 UTC (History)
1 user (show)

See Also:


Attachments
Reestablish cifs session for a mount after a disconnection (746 bytes, patch)
2007-09-26 09:49 UTC, Matthieu Lochegnies
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description stefan matthäus 2006-06-26 02:42:31 UTC
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
Comment 1 Bart Boelaert 2007-08-30 02:02:34 UTC
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.
Comment 2 Matthieu Lochegnies 2007-09-26 09:49:27 UTC
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
Comment 3 shirishpargaonkar@gmail.com 2009-07-15 11:33:59 UTC
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
Comment 4 Steve French 2009-08-24 18:07:49 UTC
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.