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:

dmesg shows the following error, presumably from when I tried to remount the share after losing the connection:


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: Then I rebooted the Linux box and the share mounted just fine. So the question is now, how can I get Linux to re-establish the connection with the Windows share if it becomes momentarily unavailable?

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.

I set up an automount by adding the following line to my fstab:

The mountpoint.mount and mountpoint.automount files have been created and the share is mounted and is accessible. But as soon as the Windows host goes to sleep and resumes, the share becomes inaccessible again with the same error messages ("cannot open directory '.': Host is down"). If I do mount -av, the list shows the directory as "Ignored". If I re-start the mountpoint.automount unit, nothing changes.

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.

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.

Thanks! No file browser here, this is Arch Linux on a Wandboard, which I access via PuTTY or else via the serial port.

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:

I've been struggling with this problem for a month and I'm more and more certain it's a Linux problem. After trying many different solutions I've gone back to your original suggestion of setting up automount in fstab (as below):
The share stays mounted and unmounts after one minute, as shown by the systemctl status output on the mnt-Work.mount service. When I ls the mount point it reconnects almost instantaneously. If I put the host PC to sleep and resume, the status shows that it timed out trying to unmount and then unmounted on its own; after I resume it remounts again with no problem.

But if I actually cd to the /mnt/Work directory, it eventually loses the connection. If I ls, I get a error, and if I try to re-mount the share I get The systemctl status says:
but if I do the daemon-reload nothing changes. Only after rebooting the Linux box can I connect to the share again.

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?

Does the following work in this situation?

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

Hello. I've cd'd into the mount directory of the share and am waiting for it to disconnect. As for the NIC, I doubt if that has anything to do with it since I can always connect using SMBCLIENT.

I was really only attempting to answer your question in superuser.com...

I'm afraid not:


As usual, SMBCLIENT works:

When this happens, can you ping the host successfully?

Sure. And as I said above, SMBLIENT connects with no problem.

Thanks for that. I've posted this probem to several forums in fact. On the one that might be able to help most, serverfault, they removed my question on the grounds that I'm not a network professional (I already knew that).

Have you checked the samba logs for any errors when this condition exists?

I'm testing via a Windows 10 host (server) and a samba client running openSUSE Leap 15.3. I can't replicate the issue connectivity issue you describe, (even when I disabled file-sharing on the server and then re-enabled it again).

Thanks! Here's the Samba log just after I send an "ls" on the /mnt/test directory (log level is 10):

The "pid=16408" it's referring to doesn't exist in the list I get if I run "ps aux". pid=484 is

I'm not sure about the significance of that snippet. A quick search online turns up similar results when the log level is set high.

FWIW, pgrep can be used to identify processes by name