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
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.