Cifs share on Windows host disconnects, but can still be reached using smblient

Question

My small home network includes a Wandboard running Arch Linux ARM and a Windows 7 desktop. The Linux box mounts a cifs share hosted on the Windows 7 machine at boot with no problem. But after a certain amount of time the connection to the Windows share is lost.

I can cd to the mount point directory, but when I run ls I get the message: cannot open directory '.': Host is down. If I unmount the mount directory and try to remount the share, I get a mount error(2): No such file or directory error. However, I can connect to the share using smbclient with no problem. And if I reboot the Wandboard the share again mounts with no problem. But after a time it becomes inaccessible again.

I've tried several different things on the Windows machine, including enabling and disabling SMB v1 and trying all the possible settings for the NIC (Intel with the latest driver) and for Windows share permissions. But the problem must involve the Linux side, since the share remains available via smbclient and mounts with no problem when I reboot. I've updated samba and cifs-utils and tried enabling and disabling winbind. I'm not sure what else to try.

Further information:

The mount line I'm using in fstab is: //192.xxx.x.xx/Work /mnt/Work cifs guest,users,credentials=/home/alarm/.smbcredentials,iocharset=utf8,vers=2.1 0 0 But I have tried a number of options, including noperm and _netdev and using vers=2.0 and also with no vers= option at all.

The command I use to connect via smbclient is sudo smbclient //192.xxx.x.xx/Work -U=alarm This prompts me for the samba password, which is the same as the password for a user "alarm" on the Windows machine. The username and password are the same as in the credentials file I use to mount the share (and try to re-mount). Once I enter the password I am connected via smbclient and can perform read and write operations.

The Windows logs show that NTLMv2 is being used for authentication when the share is mounted. smbclient's output also shows that NTLMv2 is being used. However the samba log shows the Linux box trying to use NTLMv1 to connect, and the user alarm (the one I am supposedly connecting to the share as) not being recognized; after that the anonymous user nobody seems to be logged on (the Windows host is configured to allow anonymous logon). Might this suggest that the Linux box is trying to use NTLMv1 to reconnect the share and failing?

Around the time the share disconnects, dmesg shows the following: CIFS VFS: \\192.xxx.x.xx has not responded in 180 seconds. Reconnecting... - but nothing after that to show there has been a reconnect.

My configuration is as follows:

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

I will attach a file with more detailed information once I figure out how. But I can provide any information, run tests, etc. as needed - just ask.

Thanks

Les

Answer 1

This is not an answer, but it may be a step in the right direction. I now have strace and tshark outputs from successful and failed ls and mount commands, as well as for the smbclient connection, which always succeeds.

Comparing the strace outputs, the key point seems to be (in the successful strace):

statx(AT_FDCWD, "/mnt/Work", AT_STATX_SYNC_AS_STAT, STATX_MODE, {stx_mask=STATX_TYPE|STATX_MODE|STATX_NLINK|STATX_UID|STATX_GID|STATX_MTIME|STATX_CTIME|STATX_INO|STATX_SIZE|STATX_BLOCKS|STATX_BTIME, stx_attributes=0, stx_mode=S_IFDIR|0755, stx_size=131072, ...}) = 0
openat(AT_FDCWD, "/mnt/Work", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_CLOEXEC|O_DIRECTORY) = 3
fstat64(3, {st_mode=S_IFDIR|0755, st_size=131072, ...}) = 0
mmap2(NULL, 1052672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb68d2000
getdents64(3, 0xb68d2028 /* 65 entries */, 1048576) = 2352
openat(AT_FDCWD, "/usr/lib/gconv/gconv-modules.cache", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/gconv/gconv-modules", O_RDONLY|O_CLOEXEC) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=56353, ...}) = 0
read(4, "# GNU libc iconv configuration.\n"..., 4096) = 4096

... and then a further series of reads (presumably of the files and subdirectories).

The failed connection shows this:

statx(AT_FDCWD, "/mnt/Work", AT_STATX_SYNC_AS_STAT, STATX_MODE, 0xbeb86650) = -1 EHOSTDOWN (Host is down)
openat(AT_FDCWD, "/usr/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=2998, ...}) = 0
read(3, "# Locale name alias data base.\n#"..., 4096) = 2998

...and then a read and a write of the error message ("Host is down"). I can post more of the strace output and the tshark and smbclient outputs too if anyone wishes to see them. TIA