Rob Gillen wrote: > > Some of you might already be familiar with the strange way that Linux > will often disallow umount-ing or listing directory contents of a > mounted smb share, returning the error text, "Input/output error." I > believe this error happens when a smb share is mounted, then that remote > share is removed. This is a seriously annoying problem, because > restarting Samba does not solve the problem, nor does changing > runlevels. Which is why I think it may be a kernel-level problem. I > have tried changing the runlevel to [S]ingle level user, which is > running pretty much nothing save kernel processes and a simple shell. > At this level, a 'mount' command still shows the shares to be mounted, > and also at this level it is still impossible to umount them. The only > solution that I have found so far is rebooting, which I think is an > unacceptable way to handle such a problem.
I do not believe this is a samba "bug" per se. It does, however, point out some things you should be aware of in regards to any *nix type system. When you mount a remote directory, using ether the "smbmount" or "mount -t smbfs" commands, you have called a daemon to run on your linux machine. This daemon is spawned by the command "/usr/bin/smbmount", and it will run until you umount your remote directory. Now you are saying that someone comes along, and kills the machine you have mounted the remote directory from. The problem now is not samba: it is that you have a daemon running that can no longer make a connection to the "dead" machine. You can restart the samba services until hell freezes over but it will not help you. You must stop the samba mount daemon that is running. If I have a remote directory mounted via smbmount on my linux machine, and I do a "ps -aux | grep mount", I will see the daemon. In my case it looks like this: "root 591 0.0 0.2 3748 1648 ? S Jul28 0:00 /sbin/mount.smbfs" (if you run "ps -ef | grep mount" you will actually see the name of the remote directory, such as "//windows_name/c$". Some of this may vary according to the way you called the daemon, i.e. "smbmount" or "mount -t smbfs") Now, no doubt, because the remote machine went down, I am a bit foobarred but if I simply run a kill -9 on the correct pid, I should be good to go. Some things not to do when samba mounting. Do not do a "hard" mount, i.e. do not make entries for your mount in "/etc/fstab". Do make it a "soft" mount" Because machines can and will go down, especially M$ junk, do your smbmount, take care of what you want to do, and "smbumount" as soon as possible. Try to make sure that the M$ machine is not turned off by some knucklehead while you are in the smbmount mode (good luck on this one). > Now the interesting part. During the time that I could not remove the > unmountable mounted smb shares, the dhcpd daemon also seemed to start > malfunctioning. Well, as James S. pointed out, if you went into a major "eat cpu cycles" because you had a daemon, i.e. smbmount or mount.smbfs (this latter daemon is just a symlink to smbmount) running amuck, it is possible that it foobarred dhcp on your machine. Again, no need to reboot or restart samba, just kill...kill...kill... Hopes it makes sense, and helps drjung -- J. Craig Woods UNIX/NT Network/System Administration http://www.trismegistus.net/resume.html Character is built upon the debris of despair --Emerson
Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
