Red Hat Bugzilla – Bug 4950
i/o error when smbmounted nt share 'times out'
Last modified: 2008-05-01 11:37:51 EDT
I think this is an old bug that has resurficed, i think it was fixed in the smbmount 2.0.3 or something. When i have shares from our nt server mounted on my linux and don't touch them for a while they stop to work, and i get [noa@purcell mp3]$ ls ls: .: Input/output error When i try to ls in the root of the mount. I can't umount the share since it thinks that 'device is budy' The samba-package that comes with redhat-6 doesnt have this problem (it succeeds to remount when the connection dies)
What version of samba do you have now?
I am running RH 6.0 and am having similar problems with Samba. I have the problem that if i try to mount a share and make a typo, then smbmount fails to unmount the directory on the way out and i get the io error. An example of the exchange is as follows: $smbmount \\\\junk\\c /mnt/other Added interface ip=192.168.1.1 bcast=192.168.1.255 nmask=255.255.255.0 Connection to junk failed smbmount: login failed Could not umount /mnt/other: Device or resource busy smbmount: exit $ls /mnt/other ls: /mnt/other: Input/output error This can be fixed with smbumount, but the problem is if I want to use autofs then if for some reason the connection to a share breaks, autofs cant remake the connection.
The reconnect problems should be fixed in samba-2.0.5a-11, which will be in the next Raw Hide release.
smbmount timeouts of mounted filesystems still occur under samba-2.0.6-2. smbumount cannot disconnect the dead mount, but root umount can. It appears this bug should be reopened.
Is this across reboots of the server? Samba mounts will *not* persist across this.
closed, lack of input.
The problem I have with smbmount is that if for example I give a name that is incorrect or the network is down, it tries to mount the share, realizes it cant and then tries to undo what it did. For some reason it cant and it leaves the directory in some unusable state so that i have to smbumount the directory in order to retry to mount it. This is relevant if you use autofs since if the connection is broken it cant later remount it. This does not have to do with rebooting.