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

[moonman]

What's the version of windows that's hosting the shares?
Just for the sake of experiment, can you enable smb1 on the host, and use vers=1.0 on the client?

I do not see anything wrong with your configuration and I'm using the same kernel on a different device and it's working fine (albeit my server is linux).

[Lestrad]

Thanks! My Windows version is Windows 7 Ultimate SP1.

I've already tried enabling and disabling SMB1 on Windows, and using:

vers=1 (after enabling SMB1 on Windows and adding "client min protocol = SMB 1" to smb.conf)
vers=2.0
vers=2.1
... and no "vers" at all.

Anyway I get the impression that the most recent versions of samba won't let you use "vers=1" at all because of the Wannacry danger. And I can't use SMB3 on Windows 7. (Nor can I mount the Windows shares as nfs, since my version of Windows can only act as nfs client, not host).

What's "working" now is the fstab line I posted, which uses "vers=2.0". When I say it's "working" I mean that cron jobs can mount the shares automatically and do what I want with them, which is to rsync the directories for backup purposes. I've been doing it regularly for several days now, with logs that show it's working. BUT as soon as I cd into one of the mount points on the Linux box, the shares disconnect after about 20 minutes and the only way to get them back is to reboot.

(I should point out that I'm presently back in my "old" system on the other SD card since the shares on the Linux device became inaccessible when I updated. To stay updated I'd have to stop and solve a whole 'nother samba problem. But the symptoms were exactly the same after the full update as they are now. But if you want I can reboot from the updated card to make tests.)

[Lestrad]

-update-

Now the shares have disconnected even though I have stayed out of the mount point directory. Error:

$this->bbcode_second_pass_code('', 'ls: cannot access '/mnt/test': No such device')

[Lestrad]

That turned out to be because my Windows share password had expired. So I'm back to status quo ante.

But I did learn something: smbclient provides helpful error messages. It told me my Windows password had expired. The only error message I got from the kernel was "No such device." I wish I knew how to get better debug information from the kernel.

[moonman]

You can echo a non 0 value into cifsFYI to get more verbose output in dmesg
$this->bbcode_second_pass_code('', 'echo 7 > /proc/fs/cifs/cifsFYI')

More info: https://wiki.samba.org/index.php/LinuxC ... leshooting

Try a different host, maybe windows 10 for testing and actual samba on linux.

[Lestrad]

Thanks! I've done that and it shows this if I stay out of the /mnt/test directory:
$this->bbcode_second_pass_code('', 'Resources in use
CIFS Session: 1
Share (unique mount targets): 2
SMB Request/Response Buffer: 1 Pool size: 5
SMB Small Req/Resp Buffer: 1 Pool size: 30
Operations (MIDs): 0

0 session 0 share reconnects
Total vfs operations: 223 maximum at one time: 2

Max requests in flight: 2
1) \\xxx.xxx.x.xx\test
SMBs: 21
Bytes read: 0 Bytes written: 0
Open files: 0 total (local), 0 open on server
TreeConnects: 1 total 0 failed
TreeDisconnects: 0 total 0 failed
Creates: 6 total 0 failed
Closes: 6 total 0 failed
Flushes: 0 total 0 failed
Reads: 0 total 0 failed
Writes: 0 total 0 failed
Locks: 0 total 0 failed
IOCTLs: 0 total 0 failed
QueryDirectories: 2 total 0 failed
ChangeNotifies: 0 total 0 failed
QueryInfos: 6 total 0 failed
SetInfos: 0 total 0 failed
OplockBreaks: 0 sent 0 failed ')

If I cd into the /mnt/test directory, after about 20 minutes the share becomes inaccessible and it shows:
$this->bbcode_second_pass_code('', '
Resources in use
CIFS Session: 1
Share (unique mount targets): 2
SMB Request/Response Buffer: 1 Pool size: 5
SMB Small Req/Resp Buffer: 1 Pool size: 30
Operations (MIDs): 0

0 session 0 share reconnects
Total vfs operations: 231 maximum at one time: 2

Max requests in flight: 3
1) \\xxx.xxx.x.xx\test DISCONNECTED
SMBs: 38
Bytes read: 0 Bytes written: 0
Open files: 0 total (local), 0 open on server
TreeConnects: 1 total 0 failed
TreeDisconnects: 0 total 0 failed
Creates: 11 total 0 failed
Closes: 11 total 0 failed
Flushes: 0 total 0 failed
Reads: 0 total 0 failed
Writes: 0 total 0 failed
Locks: 0 total 0 failed
IOCTLs: 0 total 0 failed
QueryDirectories: 4 total 0 failed
ChangeNotifies: 0 total 0 failed
QueryInfos: 11 total 0 failed
SetInfos: 0 total 0 failed
OplockBreaks: 0 sent 0 failed')
I've also been to that CIFS troubleshooting page. In fact that's what prompted me to set up tcpdump and wireshark, and also Windows Network Monitor. But I need advice on what filters to set up so I can track what happens when the share actually disconnects. Any advice on that would be appreciated!
I don't know what you mean by "try actual samba on linux"?? Samba is set up and it serves the shares that are hosted on my Linux box. You mean samba can connect to the Windows share as client?
Trying with a Windows 10 box is not an option at the moment. But remember that SMBCLIENT has no trouble connecting even when automount can't, so for once I don't think the problem is with Windows.

[moonman]

Unfortunately I'm not an expert with wireshark myself. Maybe someone else on this forum can help you with that.

Yeah I don't see anything abnormal with the logs besides the disconnect message.
By actual samba on linux I mean try mounting a share on a host with linux running samba and see if same things happens. With windows 10 it doesn't have to be the same machine once again. Just any machine with Windows 10, although I can see how that could be a problem if you don't have any.

Samba is installed on your client, but it serves no purpose on your client in terms of mounting shares as a client. Samba is the server component. CIFS built into the linux kernel is the client component.

[Lestrad]

Thanks. I see what you meant now. I do have Linux Mint set up on the same PC as Windows. I don't use it much but I can boot into it and try mounting the same share under Mint and see what happens. I'll get back to you on it because at the moment I need to be in Windows for work reasons. Thanks for the suggestion and the clarification.

[Lestrad]

Okay, I booted into Linux Mint and set up a share and tested it. Then I cd'd into the share's mount point directory. I waited a while and all seemed to be well, but when I put the PC into sleep mode and then resumed, I got the same errors -- "Host is down" and "No such device".

I looked at the status of the .mount file:
$this->bbcode_second_pass_code('', '[alarm@alarm etc]$ sudo systemctl status mnt-<share>.mount
- mnt-<share>.mount - /mnt/<share>
Loaded: loaded (/etc/fstab; generated)
Active: inactive (dead) since Mon 2021-08-30 17:16:32 CEST; 3min 16s ago
TriggeredBy: - mnt-<share>.automount
Where: /mnt/<share>
What: //xxx.xxx.x.xx/<share>
Docs: man:fstab(5)
man:systemd-fstab-generator(8)
août 30 12:56:00 alarm systemd[1]: Mounting /mnt/<share>...
août 30 12:56:01 alarm systemd[1]: Mounted /mnt/<share>.
août 30 17:16:32 alarm systemd[1]: Unmounting /mnt/<share>...
août 30 17:16:32 alarm systemd[1]: mnt-<share>.mount: Succeeded.
août 30 17:16:32 alarm systemd[1]: Unmounted /mnt/<share>.')
Note that it didn't unmount until 17:16:32 - which is when I issued the ls command. Normally it should automatically unmount after 30 seconds of inactivity. When I'm in some other directory than the share mount and issue ls /mnt/<share>, then wait a couple of minutes, sudo systemctl status mnt-<share>.mount shows:
$this->bbcode_second_pass_code('', 'août 30 18:37:59 alarm systemd[1]: Mounting /mnt/<share>...
août 30 18:38:00 alarm systemd[1]: Mounted /mnt/<share>.
août 30 18:39:00 alarm systemd[1]: Unmounting /mnt/<share>...
août 30 18:39:00 alarm systemd[1]: mnt-<share>.mount: Succeeded.
août 30 18:39:00 alarm systemd[1]: Unmounted /mnt/<share>.')
In other words, the share unmounts as it's supposed to after 30 seconds.

So what seems to happen is that once I'm actually in the mount directory, the share does not auto-unmount. Systemd says it's "unmounting", but in fact the share has become unfindable by the file system, and the "Host is down" message is issued. Meanwhile SMBCLIENT can connect. So it's as if systemd or the kernel or whatever isn't even trying to connect to the host. And the problem does indeed seem to be unrelated to Windows.