Does Windows disable SMB when it resumes from sleep?
I have a shared directory on my Windows 7 (SP1) box that is mounted on my (Arch) Linux box at boot. Everything works fine until the Windows box goes to sleep and then wakes up. But once it does the share becomes inaccessible on the Linux box with a "cannot access <dir>: Host is down" message. mount shows the share as mounted.
The Windows box is running SMB version 1 and the "autodisconnect" property of LanmanServer is set to -1. If I try to connect with smbclient -L <hostname> I get a list of all the shares on the Windows box, followed by "SMB1 disabled -- no workgroup available". But as I mentioned, the share mounts and is accessible until the Windows host has gone to sleep and then resumed. On the Linux side, if I unmount the share and run mount -av, I get: Code:
mount.cifs kernel mount options: ip=192.168.0.32,unc=\\xxx.xxx.x.xx\<dir>,vers=2.0,user=Dad,pass=******** Code:
CIFS: Attempting to mount //xxx.xxx.x.xx/<dir> Is there a way to configure SMB on the Windows side or Samba on the Linux side to avoid losing the connection to the share when the Windows box goes to sleep? I'd be happy to provide any information anyone might need. TIA for any help. |
Update by OP
I changed a couple of settings on the Windows side and rebooted Windows, and to my surprise I was still unable to mount the Windows share. The error message was the same:
Code:
mount error(2): No such file or directory |
I would try using autofs or systemd automount. The connection is only established when you access the share and automatically disconnects after an idle timeout.
|
Thanks for answering.
Quote:
Code:
//xxx.xxx.x.xx/<dir> /mnt/mountpoint cifs defaults,noauto,user=xxxx,password=xxxxxxxx,x-systemd.automount,x-systemd.requires=network-online.target 0 0 Do you think it's Windows that's cutting off the connection, or Linux? |
Any reason for using SMBv1? That may well be impacting here. Try using SMBv2 (Windows 7 is capable of supporting that) and see if this helps. It is a less chatty protocol along with some security improvements.
https://forums.linuxmint.com/viewtopic.php?t=255204 |
You need to specify the idle timeout value. x-systemd.mount-timeout=30 will limit the time the system tries to mount the filesystem.
Code:
//xxx.xxx.x.xx/<dir> /mnt/mountpoint cifs defaults,noauto,x-systemd.automount,x-systemd.mount-timeout=30,x-systemd.idle-timeout=1min,_netdev,user=xxxx,password=xxx 0 0 |
To ferrari: Thanks. I am using SMB2. I've disabled SMB1 on the Windows box.
|
To Michealk:
Thanks again! At first I thought I had found the problem: I saw somewhere that the Windows host's network adapter needs to be set to "allow system to turn device off to save power" so that when the computer goes to sleep it will be sure to turn it back on. I did that, but after a couple of tests I was getting the same errors. I copied your entry to fstab, and tried it with and without the above setting. Once or twice, with the network adapter set as above, I was able to connect after Windows resumed. But after waiting a while - maybe 20 minutes - before resuming Windows the share became inaccessible again. That got me to thinking: does the timeout setting have something to do with it? Is there a way to set it to "no timeout"? Of course there's one basic question that needs to be answered: Why does the share become accessible again when I reboot the Linux box? What does it do when it reboots? Shouldn't systemd do that when it automounts? |
The idle timeout is just to automatically un-mount the share if no process is using it on the linux side for that set time. The mount timeout prevents the system from continuously trying to mount the share if it is not accessible. If Windows goes to sleep before before the idle timeout happens it could still hang although I would think a forced un-mount should work without rebooting.
When you reboot your resetting the computer,network and samba connection but your not actually accessing the Windows box until you access that directory. However, I think I read somewhere that if you have created a shortcut in your file browser it could automatically access the share which if the Windows box is sleeping could cause problems. However, mount timeout should prevent the system from hanging completely although I have read that the file browser might hang. I have not found any related threads that point to a particular samba version but that does not rule it out. It could also be a Windows 7 problem which means you are stuck. |
Quote:
When I get a minute I'm going to try rebooting and then connecting and seeing what the dmesg output is when I connect. Or maybe connect with smbclient verbose and see what that says in order to compare with the errors I get now when I try to connect that way: Code:
smbclient -L xxx.xxx.x.xx -U Dad -d 256 |
Quote:
Code:
//xxx.xxx.x.xx/Work /mnt/Work cifs credentials=/home/alarm/.smbcredentials,vers=2.0,noauto,x-systemd.automount,x-systemd.idle-timeout=1min,x-systemd.mount-timeout=30,_netdev But if I actually cd to the /mnt/Work directory, it eventually loses the connection. If I ls, I get a Quote:
Quote:
Code:
Warning: The unit file, source configuration file or drop-ins of mnt-Work.mount changed on disk. Run 'systemctl daemon-reload' to reload units. So it looks to me as if actually being in the mount point of the share is what's causing the problem. But moving to another directory doesn't help. Rebooting is the only thing that works. It appears to me that the CIFS VFS has been told the host is down and for some reason won't try to reconnect. Watching the network activity shows no SMB2 calls being made to the Windows host. I'd love to hear what you think. TIA Les |
Hello?
|
Quote:
Code:
sudo systemctl daemon-reload |
I note that you posted to superuser.com regarding this...
https://superuser.com/questions/1660...with-smbclient This might be helpful to you regarding NIC power management (Windows 7 server)... https://docs.microsoft.com/en-us/tro...etwork-adapter |
Quote:
|
All times are GMT -5. The time now is 05:22 PM. |