Created attachment 500020 [details] kernel configurations I tried Up until sys-kernel/gentoo-sources-4.9.52 mounting a share from our Windows 2012 R2 server with vers=3.0 worked perfectly. Since sys-kernel/gentoo-sources-4.9.53 I always get the folowing error: # mount -v -t cifs //FS/Public/EAV/EAV-Server 1 -o credentials=/root/.Server.credentials,vers=3.0 domain=MDV mount.cifs kernel mount options: ip=192.168.1.13,unc=\\FS\Public,vers=3.0,user=EAV-Server,,domain=MDV,prefixpath=EAV/EAV-Server,pass=******** mount error(5): Input/output error Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) Please compare the attached kernel config files: they are practically the same. I even tried to enable CONFIG_BIG_KEYS (since 4.9.53). That did not help either. Mounting the same server with vers=2.1 works with all the configurations I tried.
I compiled gentoo-sources-4.9.53 with CONFIG_CIFS_DEBUG=y and CONFIG_CIFS_DEBUG2=y. After echo 7 > /proc/fs/cifs/cifsFYI, trying to mount -t cifs -o vers=3.0 yielded the following kernel error messages: Status code returned 0xc0000016 STATUS_MORE_PROCESSING_REQUIRED CIFS VFS: validate protocol negotiate failed: -11 CIFS VFS: cifs_mount failed w/return code = -5
I found a workaround: mounting -t cifs with -o vers=3.0,sec=ntlmsspi makes it work again. I guess that there was some kind of fallback doing this automagically up until kernel 4.9.52. In the commit messages of root/fs/cifs/smb2pdu.c since then I found that a protection against downgrade attacks was added. Maybe that led to the observed behaviour. Just my 2 cents ;-)
could you try a more recent kernel version? like 4.9.60 and 4.13.11
# uname -r 4.9.60-gentoo # mount.cifs --version mount.cifs version: 6.4 # mount -t cifs //FS/Public/EAV/EAV-Server 1 -o credentials=/root/.Server.credentials,vers=3.0 mount error(5): Input/output error Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) # mount -t cifs //FS/Public/EAV/EAV-Server 1 -o credentials=/root/.Server.credentials,vers=3.0,sec=ntlmsspi # ls -l 1 total 0 drwxr-xr-x 2 root root 0 Aug 9 2016 Aktiv drwxr-xr-x 2 root root 0 Aug 29 2016 Kopie # umount 1
I'm not sure about the upstream reasons behind requiring sec=ntlmssp. I suppose could be for security reason. You could try to upstream the problem and see what they reply. Thanks you