Share "disconnected" but smbclient can connect. CIFS bug?

[Lestrad]

This is actually an update to an earlier question on the General section (https://archlinuxarm.org/forum/viewtopic.php?f=57&t=15426), but since I can now express it in clearer terms and since it didn't get any nibbles there I've decided to post it here as a new topic.

To summarize: A CIFS share on a Windows host mounts with no problem but becomes inaccessible after about 20 minutes. Yet it remains accessible using smbclient.

One of the solutions I've tried is using systemd automount instead of mounting the share at boot. The line I use in fstab is as follows:

$this->bbcode_second_pass_code('', '//xxx.xxx.x.xx/test /mnt/test cifs credentials=/home/alarm/.smbcredentials,vers=2.0,noauto,x-systemd.automount,x-systemd.idle-timeout=1min,x-systemd.mount-timeout=30,_netdev')
Now the share stays available. The mount times out after one minute and the share automounts as soon as I do ls /mnt/test. This works for entire days and even after the Windows host goes into standby and then resumes. If I put the host into standby while the share is mounted, systemd reports that the timeout has timed out and unmounts the share on its own.

Once the Windows PC has resumed, the share mounts again instantaneously. BUT as soon as I cd into the actual share mount directory (/mnt/test) the same behavior returns: After 20 minutes or so the share becomes inaccessible. The output of systemctl status mnt-test.mount shows that the share has not auto-unmounted. Presumably just being in the mount directory makes it "not idle" and it is now "permanently mounted" as when I mounted it at boot. And the behavior is the same: If I ls there is a delay and then the error: $this->bbcode_second_pass_code('', 'cannot open directory '.': Host is down') (or sometimes "cannot access '/mnt/Work': No such device.").
/proc/fs/cifs/Stats.txt shows:
$this->bbcode_second_pass_code('', 'Max requests in flight: 3
1) \\192.168.0.32\Work DISCONNECTED ')

BUT the share remains accessible with smbclient.

Logic tells me that the CIFS VFS has flagged the Windows host as "Down" when it isn't. I can now strace and trace network activity from both the Linux and the Windows box, but I don't know what to capture or how to interpret the results.

Any help would be appreciated.
TIA

Arch Linux ARM version 5.7.2-1-ARCH
- samba v 4.12.3
- cifs-utils v 2.26
- mount.cifs v 6.10
- host: Windows 7 Ultimate with SMB1 disabled and SMB2 enabled

[moonman]

We don't have any kernel that's at 5.7.2 in the repo currently.
What kernel exactly are you running? What's the output of
$this->bbcode_second_pass_code('', 'pacman -Qs linux-')

Is your system fully up to date? Try if you haven't already
$this->bbcode_second_pass_code('', 'pacman -Suy')

[Lestrad]

$this->bbcode_second_pass_quote('moonman', 'p')acman -Qs linux-

[moonman]

What did the update break? In my experience breakage does happen, but not as often as you imply. If you install packages without doing a full update you will run into unexpected behavior because you install brand new packages that depend on other packages in your system, which are now out of date. It is recommended to run full system update before installing any new packages.

[Lestrad]

Yeah, I know. Well what went haywire that last time was Logitech Media Server. And once, Samba stopped working. But that turned out to be a bug in Samba itself that I found a workaround for.

When I get time I'll switch back to the other SD card and update everything. But in the meantime do you have any idea why my share would disconnect and still be accessible via smbclient? Currently, with systemd automount, I can go for hours and hours and still be able to mount when I do an ls of the mount point directory. But if I cd into the actual directory, the share becomes inaccessible after about 20 minutes and can't be accessed or remounted, but it can still be accessed by smbclient. So the problem wouldn't seem to be on the host side.

[moonman]

smbclient is a standalone utility which doesn't depend on an the kernel to access samba shares.

You mount shares using in-kernel cifs driver. This leads me to believe something is up with the kernel. Maybe there is a bug there, maybe the cifs-utils is outdated, or there is bug there. I can't troubleshoot with you because you are severely out of date.

[Lestrad]

Thanks! I'll go back to the "old" SD card and disable Logitech Media Server (which is one raisin d'être of my box) and update it again and set it to automount the share and get back to you. Might take me a little while.

Have a good weekend.
Les

[Lestrad]

Hello. Okay I'm now back on the "old" system. Here's what pacman -Qs linux- shows:

$this->bbcode_second_pass_code('', '[alarm@alarm ~]$ pacman -Qs linux-
local/libaio 0.3.112-2
The Linux-native asynchronous I/O facility (aio) library
local/liburing 2.0-1
Linux-native io_uring I/O access library
local/linux-api-headers 5.12.3-1
Kernel headers sanitized for use in userspace
local/linux-armv7 5.11.2-1
The Linux Kernel and modules - ARMv7 multi-platform
local/linux-firmware 20210511.7685cf4-1
Firmware files for Linux
local/util-linux-libs 2.37-3
util-linux runtime libraries

')
I've updated /etc/fstab with the lines I've been using to automount the two Windows shares:

$this->bbcode_second_pass_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
#
//xxx.xxx.x.xx/test /mnt/test cifs credentials=/home/alarm/.smbcredentials,vers=2.0,noauto,x-systemd.automount,x-systemd.idle-timeout=1min,x-systemd.mount-timeout=30')

The two shares mount and are accessible when I do ls /mnt/test and ls /mnt/Work. I'll try a few more times before I cd into one of them to see if I get the same behaviour (that is, the share becoming inaccessible).

Meanwhile, please let me know if you want me to update.

Thanks so much for being willing to help.

[Lestrad]

Update: I waited a while and was able to ls the shares with no problem several times. Then I cd'd into /mnt/test. ls worked at first, but a half-hour later I had lost the connection. ls now gives the error "Host is down" after a delay. /proc/fs/cifs/Stats shows:

$this->bbcode_second_pass_code('', '1) \\192.168.0.32\test DISCONNECTED
')

If I cd out of the /test directory and run ls, the error message is the same. If I try to ls the other share (/mnt/Work), I get "No such device" (without the delay.

In other words, the same behaviour. I'm going ahead with the update as you suggested.

[Lestrad]

I did a complete update with pacman -Suy. The behaviour is the same: ls results in a delay, then a "'Host is down" error. Trying to ls from outside the mount point produces "No such device."

$this->bbcode_second_pass_code('', '/proc/fs/cifs/Stats shows:
1) \\192.168.0.32\test DISCONNECTED ')

The only difference is that since the update all the samba shares on my Linux box are inaccessible and the Linux host can't be found on the network. (Samba version is Version 4.14.6)


Here's the output of pacman -Qs linux-:
$this->bbcode_second_pass_code('', '[alarm@alarm etc]$ pacman -Qs linux-
local/libaio 0.3.112-2
The Linux-native asynchronous I/O facility (aio) library
local/liburing 2.0-1
Linux-native io_uring I/O access library
local/linux-api-headers 5.12.3-1
Kernel headers sanitized for use in userspace
local/linux-armv7 5.11.2-1
The Linux Kernel and modules - ARMv7 multi-platform
local/linux-firmware 20210716.b7c134f-1
Firmware files for Linux
local/util-linux-libs 2.37.1-3
util-linux runtime libraries')