Bug 1502606

This is almost certainly a problem with the kernel, not cifs-utils. Changing components.

kernel-4.13.5-200.fc26.x86_64

Feel free to contact me if you need any debug info.

Hello,

Thank you for taking the time to report this bug. I have added the proper keyword to this bug to bring it to the attention of the CIFS subsystem maintainer. 

Can you attach the following information to this bug:

* dmesg output after the issue

I got the same issue. I cannot mount my server as usually before updating: 
My dmesg report is as following if it helps; I'd appreciate any clue or help on this.


[  184.422171] No dialect specified on mount. Default has changed to a more secure dialect, SMB2.1 or later (e.g. SMB3), from CIFS (SMB1). To use the less secure SMB1 dialect to access old servers which do not support SMB3 (or SMB2.1) specify vers=1.0 on mount.
[  184.625187] CIFS VFS: cifs_mount failed w/return code = -112
[  203.993067] No dialect specified on mount. Default has changed to a more secure dialect, SMB2.1 or later (e.g. SMB3), from CIFS (SMB1). To use the less secure SMB1 dialect to access old servers which do not support SMB3 (or SMB2.1) specify vers=1.0 on mount.
[  204.013639] CIFS VFS: cifs_mount failed w/return code = -112
[ 5304.637290] nf_conntrack: default automatic helper assignment has been turned off for security reasons and CT-based  firewall rule not found. Use the iptables CT target to attach helpers instead.
[ 8185.240840] CIFS VFS: cifs_mount failed w/return code = -112
[ 8198.950289] CIFS VFS: cifs_mount failed w/return code = -112
[ 8229.909894] CIFS VFS: cifs_mount failed w/return code = -112
[ 9088.423867] CIFS VFS: cifs_mount failed w/return code = -112
[ 9106.080500] CIFS VFS: cifs_mount failed w/return code = -112
[ 9117.228389] CIFS VFS: cifs_mount failed w/return code = -112
[12240.453491] CIFS VFS: cifs_mount failed w/return code = -112

I have different error in the journal:
říj 16 11:34:16 yarda kernel: No dialect specified on mount. Default has changed to a more secure dialect, SMB2.1 or later (e.g. SMB3), from CIFS (SMB1). To use the less secure SMB1 dialect to access old servers which do not support SMB3 (or SMB2.1) specify vers=1.0 on mount.
říj 16 11:34:17 yarda kernel: CIFS VFS: validate protocol negotiate failed: -11
říj 16 11:34:17 yarda kernel: CIFS VFS: cifs_mount failed w/return code = -5

I will check the dmesg tomorrow, but I think it will be the same as the journal.

I would like to mention I have Czech version of Windows 10. I will also check with different Windows 10 Samba servers, but AFAIK I have nearly default config except enablement of the admin shares (C$). It works with the SMB2.1, but it doesn't work with the now default SMB3.

(In reply to Jaroslav Škarvada from comment #5)
> I have different error in the journal:
> říj 16 11:34:16 yarda kernel: No dialect specified on mount. Default has
> changed to a more secure dialect, SMB2.1 or later (e.g. SMB3), from CIFS
> (SMB1). To use the less secure SMB1 dialect to access old servers which do
> not support SMB3 (or SMB2.1) specify vers=1.0 on mount.
> říj 16 11:34:17 yarda kernel: CIFS VFS: validate protocol negotiate failed:
> -11
> říj 16 11:34:17 yarda kernel: CIFS VFS: cifs_mount failed w/return code = -5
> 
> I will check the dmesg tomorrow, but I think it will be the same as the
> journal.
> 
> I would like to mention I have Czech version of Windows 10. I will also
> check with different Windows 10 Samba servers, but AFAIK I have nearly
> default config except enablement of the admin shares (C$). It works with the
> SMB2.1, but it doesn't work with the now default SMB3.

Yup, it's the same, the dmesg snip:
[ 6296.754518] FS-Cache: Netfs 'cifs' registered for caching
[ 6296.754634] Key type cifs.spnego registered
[ 6296.754637] Key type cifs.idmap registered
[ 6296.755054] No dialect specified on mount. Default has changed to a more secu
re dialect, SMB2.1 or later (e.g. SMB3), from CIFS (SMB1). To use the less secur
e SMB1 dialect to access old servers which do not support SMB3 (or SMB2.1) speci
fy vers=1.0 on mount.
[ 6297.093312] CIFS VFS: validate protocol negotiate failed: -11
[ 6297.095360] CIFS VFS: cifs_mount failed w/return code = -5

Aha, I probably got it:
$ grep CONFIG_CIFS_SMB311  /boot/config-4.13.5-200.fc26.x86_64
# CONFIG_CIFS_SMB311 is not set

That's probably why the protocol negotiation fails with the latest Windows 10.

(In reply to Jaroslav Škarvada from comment #7)
> Aha, I probably got it:
> $ grep CONFIG_CIFS_SMB311  /boot/config-4.13.5-200.fc26.x86_64
> # CONFIG_CIFS_SMB311 is not set
> 
> That's probably why the protocol negotiation fails with the latest Windows
> 10.

It maybe not the source of the problem, I am going to recompile the kernel with the:
CONFIG_CIFS_DEBUG
CONFIG_CIFS_SMB311
and retry.

CONFIG_CIFS_SMB311 didn't help, CONFIG_CIFS_DEBUG was already there, but it was a bit tricky to enable the FYI debug without full kernel recompile:

[58014.081891] No dialect specified on mount. Default has changed to a more secure dialect, SMB2.1 or later (e.g. SMB3), from CIFS (SMB1). To use the less secure SMB1 dialect to access old servers which do not support SMB3 (or SMB2.1) specify vers=1.0 on mount.
[58014.081898] CIFS VFS: Username: user
[58014.081905] CIFS VFS: file mode: 0x1ed  dir mode: 0x1ed
[58014.081912] CIFS VFS: CIFS VFS: in cifs_mount as Xid: 0 with uid: 0
[58014.081917] CIFS VFS: UNC: \\192.168.1.2\C$
[58014.081946] CIFS VFS: Socket created
[58014.081950] CIFS VFS: sndbuf 16384 rcvbuf 87380 rcvtimeo 0x1b58
[58014.084062] CIFS VFS: cifs_fscache_get_client_cookie: (0xffff8c2978906800/0xffff8c2ac514a9a0)
[58014.084073] CIFS VFS: CIFS VFS: in cifs_get_smb_ses as Xid: 1 with uid: 0
[58014.084076] CIFS VFS: Existing smb sess not found
[58014.084082] CIFS VFS: Demultiplex PID: 10297
[58014.084090] CIFS VFS: Negotiate protocol
[58014.084099] CIFS VFS: Sending smb: smb_len=106
[58014.088013] CIFS VFS: RFC1002 header 0x1c0
[58014.088032] CIFS VFS: smb2_check_message length: 0x1c4, smb_buf_length: 0x1c0
[58014.088038] CIFS VFS: SMB2 data length 320 offset 128
[58014.088041] CIFS VFS: SMB2 len 452
[58014.088086] CIFS VFS: cifs_sync_mid_result: cmd=0 mid=0 state=4
[58014.088097] CIFS VFS: mode 0x1
[58014.088099] CIFS VFS: negotiated smb3.02 dialect
[58014.088107] CIFS VFS: OID len = 10 oid = 0x1 0x3 0x6 0x1
[58014.088110] CIFS VFS: OID len = 10 oid = 0x1 0x3 0x6 0x1
[58014.088115] CIFS VFS: Security Mode: 0x1 Capabilities: 0x300047 TimeAdjust: 0
[58014.088118] CIFS VFS: Session Setup
[58014.088120] CIFS VFS: sess setup type 4
[58014.088126] CIFS VFS: Sending smb: smb_len=120
[58014.091380] CIFS VFS: RFC1002 header 0xd2
[58014.091394] CIFS VFS: smb2_check_message length: 0xd6, smb_buf_length: 0xd2
[58014.091398] CIFS VFS: SMB2 data length 138 offset 72
[58014.091400] CIFS VFS: SMB2 len 214
[58014.091438] CIFS VFS: cifs_sync_mid_result: cmd=1 mid=1 state=4
[58014.091447] CIFS VFS: Mapping SMB2 status code 0xc0000016 to POSIX err -5
[58014.091450] CIFS VFS: Null buffer passed to cifs_small_buf_release
[58014.091455] CIFS VFS: rawntlmssp session setup challenge phase
[58014.091510] CIFS VFS: Sending smb: smb_len=296
[58014.095924] CIFS VFS: RFC1002 header 0x48
[58014.095939] CIFS VFS: smb2_check_message length: 0x4c, smb_buf_length: 0x48
[58014.095944] CIFS VFS: SMB2 data length 0 offset 72
[58014.095948] CIFS VFS: SMB2 len 77
[58014.095952] CIFS VFS: Calculated size 77 length 76 mismatch mid 2
[58014.095999] CIFS VFS: cifs_sync_mid_result: cmd=1 mid=2 state=4
[58014.096006] CIFS VFS: Null buffer passed to cifs_small_buf_release
[58014.096086] CIFS VFS: SMB2/3 session established successfully
[58014.096101] CIFS VFS: CIFS VFS: leaving cifs_get_smb_ses (xid = 1) rc = 0
[58014.096108] CIFS VFS: CIFS VFS: in cifs_get_tcon as Xid: 2 with uid: 0
[58014.096111] CIFS VFS: TCON
[58014.096119] CIFS VFS: Sending smb: smb_len=106
[58014.097956] CIFS VFS: RFC1002 header 0x50
[58014.097969] CIFS VFS: smb2_check_message length: 0x54, smb_buf_length: 0x50
[58014.097973] CIFS VFS: SMB2 len 84
[58014.098023] CIFS VFS: cifs_sync_mid_result: cmd=3 mid=3 state=4
[58014.098031] CIFS VFS: Null buffer passed to cifs_small_buf_release
[58014.098037] CIFS VFS: connection to disk share
[58014.098041] CIFS VFS: validate negotiate
[58014.098044] CIFS VFS: SMB2 IOCTL
[58014.098049] CIFS VFS: Sending smb: smb_len=150
[58014.099152] CIFS VFS: Received no data or error: -104
[58014.099158] CIFS VFS: Reconnecting tcp session
[58014.099163] CIFS VFS: cifs_reconnect: marking sessions and tcons for reconnect
[58014.099167] CIFS VFS: cifs_reconnect: tearing down socket
[58014.099171] CIFS VFS: State: 0x3 Flags: 0x0
[58014.099177] CIFS VFS: Post shutdown state: 0x3 Flags: 0x0
[58014.099199] CIFS VFS: cifs_reconnect: moving mids to private list
[58014.099203] CIFS VFS: cifs_reconnect: issuing mid callbacks
[58014.099228] CIFS VFS: Socket created
[58014.099232] CIFS VFS: cifs_sync_mid_result: cmd=11 mid=4 state=8
[58014.099235] CIFS VFS: Null buffer passed to cifs_small_buf_release
[58014.099240] CIFS VFS: validate protocol negotiate failed: -11
[58014.099244] CIFS VFS: CIFS VFS: leaving cifs_get_tcon (xid = 2) rc = -5
[58014.099247] CIFS VFS: Tcon rc = -5
...

Hope it helps.

(In reply to Jaroslav Škarvada from comment #9)
> [58014.098041] CIFS VFS: validate negotiate
> [58014.098044] CIFS VFS: SMB2 IOCTL
> [58014.098049] CIFS VFS: Sending smb: smb_len=150
> [58014.099152] CIFS VFS: Received no data or error: -104

It seems the connection is reset by peer (error 104 from the underlying sock_recvmsg) when calling FSCTL_VALIDATE_NEGOTIATE_INFO. It seems it's reset by the server or something on the way (there is only one transparent wifi router, but I will try without it). No idea why it happens. I will try to do tpcdump sniffs.

There are several threads about this related to kernel updates. We tried the version 1 for SMB work around with the mount command but it does not work with autofs. Stilt getting the below after restarting autofs:
kernel: No dialect specified on mount. Default has changed to a more secure dialect, SMB2.1 or later (e.g. SMB3), from CIFS (SMB1). To use the less secure SMB1 dialect to access old servers which do not support SMB3 (or SMB2.1) specify vers=1.0 on mount.
kernel: CIFS VFS: cifs_mount failed w/return code = -112

https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwj6zOzFwPjWAhWr34MKHUSYBUEQFggmMAA&url=https%3A%2F%2Fplus.google.com%2F%2BThorstenLeemhuis%2Fposts%2F7sm3xKWxWjP&usg=AOvVaw2-5EDDs1LAQvlzPWcfxN33

https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&uact=8&ved=0ahUKEwj6zOzFwPjWAhWr34MKHUSYBUEQFggsMAE&url=https%3A%2F%2Fplus.google.com%2F%2BThorstenLeemhuis%2Fposts%2FgnGwqw6EGNd&usg=AOvVaw1tLMcUCdigjeUQ0l6HaVLG

https://access.redhat.com/discussions/3002961?tour=8

(In reply to RobbieTheK from comment #11)
Thanks for reply.

> There are several threads about this related to kernel updates. We tried the
> version 1 for SMB work around with the mount command but it does not work
> with autofs. Stilt getting the below after restarting autofs:
> kernel: No dialect specified on mount. Default has changed to a more secure
> dialect, SMB2.1 or later (e.g. SMB3), from CIFS (SMB1). To use the less
> secure SMB1 dialect to access old servers which do not support SMB3 (or
> SMB2.1) specify vers=1.0 on mount.
> kernel: CIFS VFS: cifs_mount failed w/return code = -112
>
I do not get error -112, but it maybe related. IMHO Windows 10 SMB server does not support SMB1, but as I wrote earlier workaround with SMB2.1 works OK for me.
 
> https://www.google.com/
> url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwj6zOzFwPjW
> AhWr34MKHUSYBUEQFggmMAA&url=https%3A%2F%2Fplus.google.
> com%2F%2BThorstenLeemhuis%2Fposts%2F7sm3xKWxWjP&usg=AOvVaw2-
> 5EDDs1LAQvlzPWcfxN33
> 
> https://www.google.com/
> url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&uact=8&ved=0ahUKEwj6zOzFwPjW
> AhWr34MKHUSYBUEQFggsMAE&url=https%3A%2F%2Fplus.google.
> com%2F%2BThorstenLeemhuis%2Fposts%2FgnGwqw6EGNd&usg=AOvVaw1tLMcUCdigjeUQ0l6Ha
> VLG
> 
Marcos Mello in the comment of this post reports the same error as me.

> https://access.redhat.com/discussions/3002961?tour=8
I do not get the host down error and smbclient works OK for me (probably because it's using SMB2), but the error protocol negotiation failed: NT_STATUS_CONNECTION_RESET, seems to be related problem.

I also did tcpdump on the router with all firewalls disabled:

240	128.715022	192.168.1.6	192.168.1.2	SMB2	366	Session Setup Request, NTLMSSP_AUTH, User: \user
241	128.717994	192.168.1.2	192.168.1.6	SMB2	142	Session Setup Response
242	128.720375	192.168.1.6	192.168.1.2	SMB2	176	Tree Connect Request Tree: \\192.168.1.2\C$
243	128.721110	192.168.1.2	192.168.1.6	SMB2	150	Tree Connect Response
244	128.723624	192.168.1.6	192.168.1.2	SMB2	220	Ioctl Request FSCTL_VALIDATE_NEGOTIATE_INFO
245	128.723991	192.168.1.2	192.168.1.6	TCP	60	445 → 35848 [RST, ACK] Seq=827 Ack=799 Win=0 Len=0

It confirms my previous assumption that the connection is reset by the Windows 10 SMB server after the (maybe invalid?) FSCTL_VALIDATE_NEGOTIATE_INFO request. I will probably forward this report to LKML.

Upstream bug report:
https://bugzilla.kernel.org/show_bug.cgi?id=197311

Possibly related? https://bugzilla.samba.org/show_bug.cgi?id=12917

(In reply to Jaroslav Škarvada from comment #13)
> Upstream bug report:
> https://bugzilla.kernel.org/show_bug.cgi?id=197311

Any chance you would be willing to describe how you built the kernel with the patch removed? Do the instructions at https://www.howtoforge.com/kernel_compilation_fedora still apply

The following statement in the referenced howtoforge article:

"I prefer to do all the steps here as the root user." 

turned me away. It is SO wrong to build packages as root.

(In reply to RobbieTheK from comment #15)
> (In reply to Jaroslav Škarvada from comment #13)
> > Upstream bug report:
> > https://bugzilla.kernel.org/show_bug.cgi?id=197311
> 
> Any chance you would be willing to describe how you built the kernel with
> the patch removed? Do the instructions at
> https://www.howtoforge.com/kernel_compilation_fedora still apply

It's unrelated to this BZ, but it may be useful for newbies, so I wrote a simple blog post about it:
http://blog.yarda.eu/2017/10/how-to-recompile-fedora-kernel-with.html

Try this patch: https://git.samba.org/?p=sfrench/cifs-2.6.git;a=commit;h=cf237481182846c508a4baa4f8281a2a7262ca09

*** Bug 1507342 has been marked as a duplicate of this bug. ***

kernel-4.13.11-100.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-38b37120a2

kernel-4.13.11-200.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-9fbb35aeda

kernel-4.13.11-300.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-ef58cbde27

kernel-4.13.11-300.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-ef58cbde27

(In reply to Fedora Update System from comment #21)
> kernel-4.13.11-200.fc26 has been submitted as an update to Fedora 26.
> https://bodhi.fedoraproject.org/updates/FEDORA-2017-9fbb35aeda

This may be another bug as the error code is different but I'm getting this:
No dialect specified on mount. Default has changed to a more secure dialect, SMB2.1 or later (e.g. SMB3), from CIFS (SMB1). To use the less secure SMB1 dialect to access old servers which do not support SMB3 (or SMB2.1) specify vers=1.0 on mount.
kernel: CIFS VFS: cifs_mount failed w/return code = -112
So there is some place where the vers=1.0 option is not being passed, note the results of this NIS command:
ypcat -k auto.cifs
$SMBCLIENT $smbclientopts -gL $key 2>>/var/log/autofs.log    | awk -v key="$key" -v opts="$mountopts" -F'|' -- '
[ -x $SMBCLIENT ] || exit 1
credfile="/etc/auto.smb.$key" 
do 
done 
else 
fi 
for P in /bin /sbin /usr/bin /usr/sbin
if [ -e "$credfile" ]
key="$1" 
mountopts="-fstype=cifs,file_mode=0600,dir_mode=0700,uid=root,gid=root"
smbclientopts=""

kernel-4.13.11-100.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-38b37120a2

kernel-4.13.11-200.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-9fbb35aeda

kernel-4.13.11-200.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.

kernel-4.13.11-100.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.

kernel-4.13.11-300.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.