CIFS is going crazy (Linux - Windows XP) - Page 1
Forum section: electronics / general

author: legacy
author_rank: Super Contributor
timestamp: August 18, 2019, 10:03:54 am
content: So, I have always used my IBM/Lenovo X61S laptop with Windows XP + MobaXterm/Professional to access a remote Linux machine running kernel 2.6.39.This machine is for legacy reasons since I have legacy applications (compilers, and applications) that run better this way or don't run on Windows 7..10.Anyway, I needed to update the userland, and this required to update the kernel, so now I am on Linux 4.9.16, and I am experimenting a weird problem with CIFS.The Windows laptop "exports" a part of its filesystem to the Linux machine via CIFS, and ... the problem is that it hangs up if I don't continuously keep it busy.This is the error I see on Linux when the CIFS filesystem hands upCode:CIFS VFS: Server 192.168.1.12 has not responded in 120 seconds. Reconnecting...And there is no way to sort it out. I have to unmount, and remount it.This is how it's mountedCode:# cat /etc/fstab | grep idp//192.168.1.12/idp.do /idp.do cifs noauto,nobrl,noserverino,rw,iocharset=utf8,credentials=/etc/cifspasswd,vers=1.0 0 0Code:# mount | grep idp//192.168.1.12/idp.do on /idp.do type cifs (rw,relatime,vers=1.0,cache=strict,username=root,domain=IDP,uid=0,noforceuid,gid=0,noforcegid,addr=192.168.1.12,file_mode=0755,dir_mode=0755,nounix,mapposix,nobrl,rsize=61440,wsize=65536,echo_interval=60,actimeo=1)And this script is how I save my day, but it's crazy that I have to do something like that!Code:while [ 1 ]do#clear#echo "sync"#dfsyncsyncsyncsyncls /idp.do/ > /dev/null 2> /dev/nullsleep 1done"ls /idp.do" is repeated every second and this keeps the comunication between the laptop and the remote Linux machine alive.

author: magic
author_rank: Super Contributor
timestamp: August 18, 2019, 10:13:14 am
content: TryCode:mv . ../../computing/general_computingAnd the elephant in the room is that you also updated the userland?

author: legacy
author_rank: Super Contributor
timestamp: August 18, 2019, 11:51:22 am
content: Quote from: magic on August 18, 2019, 10:13:14 amI had updated the userland, and the new userland (compiled for the new glibc) required to update the kernel. So now they are both updated.

author: legacy
author_rank: Super Contributor
timestamp: August 18, 2019, 11:55:08 am
content: Thetoolfor for Managing Linux CIFS Client Filesystems is version 6.7

author: magic
author_rank: Super Contributor
timestamp: August 18, 2019, 12:20:12 pm
content: Nevermind, I'm an idiot. You are using the in-kernel CIFS driver and it just stops working for no reason?Dunno, standard stuff: dmesg, tcpdump. Maybe they modified it so it needs some stupid supporting deamon to keep it alive? No idea, sorry.

author: SparkyFX
author_rank: Frequent Contributor
timestamp: August 19, 2019, 02:34:27 am
content: searching for "smblient connection timeout" came up with this:https://askubuntu.com/questions/890499/connection-timeout-on-windows-share-network

author: legacy
author_rank: Super Contributor
timestamp: August 19, 2019, 06:11:50 am
content: it suggests to use version3, butCode:vers=SMB protocol version. Allowed values are:o 1.0 - The classic CIFS/SMBv1 protocol. This is the default.o 2.0 - The SMBv2.002 protocol. This was initially introduced in Windows Vista Service Pack 1, andWindows Server 2008. Note that the initial release version of Windows Vista spoke a slightly differentdialect (2.000) that is not supported.o 2.1 - The SMBv2.1 protocol that was introduced in Microsoft Windows 7 and Windows Server 2008R2.o 3.0 - The SMBv3.0 protocol that was introduced in Microsoft Windows 8 and Windows Server 2012.Note too that while this option governs the protocol version used, not all features of each version areavailable.Windows XP can only use the classic CIFS/SMBv1 protocol.

author: legacy
author_rank: Super Contributor
timestamp: August 19, 2019, 07:29:26 am
content: I have just updated the kernel toCode:#uname -r4.20.12-Shy-Crocodile-orangebox(a lot of effort at doing that, because I had to "port" my kernel-drivers for my can-bus adapters)anyway, I have also patched the mount.cifs, forced an explicit IP, and now it seems working.Code:echo 7 > /proc/fs/cifs/cifsFYIsource="//idp/idp.do"target="/idp.do"ip="ip=192.168.1.12"opt="rw,noauto,nobrl,noserverino,rw,iocharset=utf8,user=root,pass=*****,vers=1.0,soft"mount -t cifs --verbose -o "$ip,$opt" $source $target#test#smbclient //192.168.1.12/idp.do /idp.do/It also seems there is a serious problem with credentials, so I have forced the support on net-fs/cifs-utils (mount.cifs) but I am manually passing the username and the passwordCode:#creds, cifs credentials supportnet-fs/cifs-utils acl ads caps caps-ng pam +creds

author: legacy
author_rank: Super Contributor
timestamp: August 19, 2019, 09:53:32 am
content: After 30 minutes, it silently hangs up with this messageCode:Status code returned 0xc0000034 NT_STATUS_OBJECT_NAME_NOT_FOUNDKernel 4.20.12 is no better, it adds more problems

author: legacy
author_rank: Super Contributor
timestamp: August 19, 2019, 12:56:53 pm
content: the kernel has been downgraded to 4.9.16-Roaring-Lionusthe net-fs/cifs-utils has been updated to -6.9 (~x86 experimental)(mount.cifs-v6.9 does panic with kernel > 4.9.16)Code:# Active debugecho 7 > /proc/fs/cifs/cifsFYI# -------------------------------------------------------------------------------------------------------------ip="192.168.1.12"source="//idp/idp.do"target="/idp.do"domain="my"opt=""opt="$opt,ip=$ip"opt="$opt,rw"opt="$opt,noauto"opt="$opt,nobrl"opt="$opt,noserverino"opt="$opt,rw"opt="$opt,iocharset=utf8"opt="$opt,user=xxxx,pass=xxxxx"opt="$opt,domain=$domain"opt="$opt,vers=1.0"opt="$opt,noperm"opt="$opt,hard"#noperm# Client does not do permission checks. This can expose files on this mount to access by other users on the# local client system. It is typically only needed when the server supports the CIFS Unix Extensions but the# UIDs/GIDs on the client and server system do not match closely enough to allow access by the user doing the# mount. Note that this does not affect the normal ACL check on the target machine done by the server# software (of the server ACL against the user name provided at mount time).#WindowsXP: Server does not support signing#opt="$opt,sec=ntlmsspi"mount -t cifs --verbose -o "$opt" $source $target(I have forced noperm, see the note for the meaning)It seems that this script can do the job, the bug seems to be in both kernel and userland, so dunno if the problem is well workarounded, but at least it's still stable after two hours with GCC running on a Linux machine still compiling files on a remote folder shared on a Windows XP computer.No hang yet, no crash yet. Will it last? Who knows ...

author: SparkyFX
author_rank: Frequent Contributor
timestamp: August 19, 2019, 01:07:31 pm
content: Quote from: legacy on August 19, 2019, 06:11:50 amIt suggests to set the maximum version to what is applicable.

author: legacy
author_rank: Super Contributor
timestamp: August 19, 2019, 09:24:16 pm
content: Still stable, after hours of use. OK, not a neat solution, but it works.Sometimes the kernel (with cifs-debug enabled) complains about"Status code returned 0xc0000043 NT_STATUS_SHARING_VIOLATION""Status code returned 0xc0000034 NT_STATUS_OBJECT_NAME_NOT_FOUND"but it doesn't crash, and it doesn't hang up.It seems there is a deep bug in the v1-protocol, or something has been removed