Does Windows disable SMB when it resumes from sleep?

Lestrad · 07-02-2021, 10:00 AM

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=********
mount error(2): No such file or directory
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg)

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

Code:

  CIFS: Attempting to mount //xxx.xxx.x.xx/<dir>
    CIFS: VFS: cifs_mount failed w/return code = -2

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.

Lestrad · 07-03-2021, 12:31 AM

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

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?

michaelk · 07-03-2021, 05:50 AM

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.

Lestrad · 07-04-2021, 03:08 AM

Thanks for answering.

Quote:

Originally Posted by michaelk

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.

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

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

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?

ferrari · 07-04-2021, 05:49 AM

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

michaelk · 07-04-2021, 07:04 AM

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

Lestrad · 07-04-2021, 11:32 AM

To ferrari: Thanks. I am using SMB2. I've disabled SMB1 on the Windows box.

Lestrad · 07-04-2021, 12:32 PM

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?

michaelk · 07-04-2021, 01:07 PM

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.

Lestrad · 07-04-2021, 11:21 PM

Quote:

Originally Posted by michaelk

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:

Code:

smbclient -L xxx.xxx.x.xx -U Dad -d 256
--------snip---------
SPNEGO login failed: The transport connection has been reset.
session setup failed: NT_STATUS_CONNECTION_RESET

Lestrad · 08-06-2021, 10:24 AM

Quote:

Originally Posted by michaelk

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

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):

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

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

Quote:

"Host is down"

error, and if I try to re-mount the share I get

Quote:

"No such file or directory."

The systemctl status says:

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.

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

Lestrad · 08-28-2021, 01:02 AM

Hello?

ferrari · 08-28-2021, 02:43 AM

Quote:

Originally Posted by Lestrad

...but if I do the daemon-reload nothing changes. Only after rebooting the Linux box can I connect to the share again.

Does the following work in this situation?

Code:

sudo systemctl daemon-reload
sudo systemctl restart remote-fs.target

ferrari · 08-28-2021, 03:03 AM

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

Lestrad · 08-28-2021, 03:12 AM

Quote:

Originally Posted by ferrari

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.