Results 1 to 2 of 2
Enjoy an ad free experience by logging in. Not a member yet? Register.
- Join Date
- Jul 2007
Samba mount does not drop on timeout
I'm somewhat of a Linux newbie (been tinkering with Linux for a decade, but rarely).
We have a Linux server hosting a service that publishes files out to a Windows machine running IIS. We're using Samba for the file transfer since the service expects a file path (not, for example, an FTP path).
We've found that if the service publishes while the Windows machine goes down for maintenance--never a planned synchronous event but it does happen--Samba does not break the mount. Instead, it just sort of hangs there, and if you try to unmount it, it says it can't do it because it's "busy".
More specifically, the service on the Linux machine was publishing files out when the Windows machine rebooted. The Samba connection was never restored, and half a day later we were all looking at it and trying to figure out why the service running on Linux was hung. The Linux guys said that the Samba path to one Windows server was up but the path to another Windows server was down. We rebooted the Windows server whose link was down, but that didn't help. We then observed that Samba's link wasn't unmounted and we couldn't unmount it and remount it. We looked at the Event Viewer on Windows and saw that the machine had been rebooted half a day prior, from which we concluded that Samba simply failed to unmount the link when Windows went down.
What can we do on Samba configuration-wise to get a proper timeout or connection error / exception to be raised on Linux, or to write to a temp path, rather than let it just hang there in a broken state indefinitely?
- Join Date
- Jul 2007
No one responded to this. We've since cleaned up our "going down for maintenance" periods on Windows and we've migrated the Linux environment to RHEL 5 so we don't know if the problem remains on Samba.
However, continuing the original discussion, ..
What should happen is a timeout should occur, an error should be raised to the calling application (the publishing service), the application (publishing service) if dependent upon the file I/O should halt at its own discretion, and then when the Windows server comes back up and the application (publishing service) on Linux reattempts to access the path, Samba should reattempt to build the link and either succeed or fail (obviously if Windows is back up, it should succeed).
That is the clean behavior of Windows and network mounted drives. If the server goes down, the network mounted drive will timeout and throw an error. Reattempting later just by double-clicking the drive will rebuild the link without having to re-map the drive or reboot the client machine.