CIFS is going crazy (Linux - Windows XP)

[legacy]

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 up

Code: [Select]

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 mounted

Code: [Select]

# 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 0



Code: [Select]

# 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: [Select]

while [ 1 ]
do
    #clear
    #echo "sync"
    #df
    sync
    sync
    sync
    sync
    ls /idp.do/ > /dev/null 2> /dev/null
    sleep 1
done

"ls /idp.do" is repeated every second and this keeps the comunication between the laptop and the remote Linux machine alive.

[magic]

Try

Code: [Select]

mv . ../../computing/general_computing

And the elephant in the room is that you also updated the userland?

[legacy]

And the elephant in the room is that you also updated the userland?

I had updated the userland, and the new userland (compiled for the new glibc) required to update the kernel. So now they are both updated.

[legacy]

The tool for for Managing Linux CIFS Client Filesystems is version 6.7

[magic]

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.

[SparkyFX]

searching for "smblient connection timeout" came up with this: https://askubuntu.com/questions/890499/connection-timeout-on-windows-share-network

[legacy]

it suggests to use version3, but

Code: [Select]

       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, and
               Windows Server 2008. Note that the initial release version of Windows Vista spoke a slightly different
               dialect (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 are
           available.

Windows XP can only use  the classic CIFS/SMBv1 protocol.

[legacy]

I have just updated the kernel to

Code: [Select]

#uname -r
4.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: [Select]

echo 7 > /proc/fs/cifs/cifsFYI
source="//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 password

Code: [Select]

#creds, cifs credentials support 
net-fs/cifs-utils acl ads caps caps-ng pam +creds


[legacy]

After 30 minutes, it silently hangs up with this message

Code: [Select]

Status code returned 0xc0000034 NT_STATUS_OBJECT_NAME_NOT_FOUND

Kernel 4.20.12 is no better, it adds more problems 

[legacy]

the kernel has been downgraded to 4.9.16-Roaring-Lionus
the net-fs/cifs-utils has been updated to -6.9 (~x86 experimental)

(mount.cifs-v6.9 does panic with kernel > 4.9.16)

Code: [Select]

# Active debug
echo 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 ... 

[SparkyFX]

it suggests to use version3, but

It suggests to set the maximum version to what is applicable.

[legacy]

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