Linux kernel 4.13 and SMB protocol version fun

There's been a rather interesting change in the Linux kernel recently, which may affect you if you're mounting network drives using SMB (the Windows native protocol, occasionally also called CIFS).

There have been several versions of the protocol - Wikipedia has a good writeup. Both servers and clients may support different versions; when accessing a shared resource, the client tells the server which protocol version it wants to use, and if the server supports that version then everyone's happy and the access goes ahead; if the server doesn't support that version, you get an error and no-one's happy.

Up until kernel 4.13, the kernel's default SMB protocol version was 1.0. So when you mount an SMB share, if you don't explicitly specify a protocol version with the vers= mount option, with kernel 4.12 or earlier, SMB 1.0 will be used.

With kernel 4.13, the default protocol version is changed to 3.0. So now, when mounting SMB mounts that don't explicitly specify a version, your system will request 3.0.

As I understand it, the main reason for this is security: SMB 3.0 is considerably more secure as a protocol than 1.0. Microsoft has been gradually trying to push Windows users towards later versions of the protocol over the last few releases.

Kernel 4.13 has been released as an update for Fedora 25 and Fedora 26, so users of those Fedora releases will hit this change when updating the kernel. Fedora 27 comes with kernel 4.13 out of the box.

Obviously, this comes with some compatibility consequences. If the server providing the share is running Windows 8 or later, you should be fine. However, in other cases, you may find your SMB mount suddenly fails after the kernel update. Older versions of Windows do not support SMB 3.0.

Samba added SMB 3.0 support in version 4.2, at least according to this page, so mounts provided by earlier Samba versions similarly will not work.

If your server is a NAS, it may or may not support SMB 3.0. My NAS is a Thecus N5550, so I know that for ThecusOS 5-based NASes, firmware version added SMB 3.0 support. However, it's not enabled by default; you have to log into the admin UI, go to Network Service, select Samba/CIFS, and set 'SMB Max Protocol' to 3. Note that with this update, the default SMB minimum version is set to 2, so the NAS will no longer support 1.0 - you can change the minimum version to 'NT1' if you have a client which cannot do 2 or 3, though.

If you know information about SMB protocol support for any other NAS brand or other common SMB server of any kind, please post a comment and I'll add it to this post.

If you get caught out by this, the best solution is to somehow update the server end of your setup so that it supports SMB 3.0. However, if you can't do that, you can use the vers mount option. Use the highest version that works - 2.x isn't as good as 3.0, but better than 1.0. The available choices are documented in man mount.cifs; at present they are 1.0, 2.0, 2.1 and 3.0.


Steffen Mann wrote on 2017-12-05 12:45:
Holy sch*t I've run into that on F27 Usually mountig with nemo or nautilus with smb://share/name how do I specify this version thing there?
Steffen Mann wrote on 2017-12-05 12:49:
With: cifs-utils.x86_64 6.7-5.fc27 @updates that is on a fresh F27 install /me forgot to metion
Angelo Barney wrote on 2017-12-06 16:03:
Same issue here on a F27 connecting to a 7-mode NetApp CIFS share :( The only way to let it work it's mounting the share with "mount.cifs -o vers=1.0..."
JoeS wrote on 2017-12-17 11:03:
My god thank you for explaining all this. I have been trying to force all sorts of different Linux flavors to use SMB3.0 mounts served from my OpenMediaVault vm (kernel, smbd -V 4.2.14-deb). Haven't been successful really. I am using kerberos tickets and autofs too, which doesn't make things any easier. I've been seeing weird issues from my linux hosts like input/output errors after ~12 hours of the drives being mounted. When specifying "server min protocol = SMB3" & "client min protocol = SMB3" I've even been having trouble connecting from some of my Windows hosts with mapped SMB drives. What the heck
Sean Anderson wrote on 2018-01-11 11:48:
For what it's worth, just hit this on Ubuntu 16.4.03 LTS when it just upgraded to the 4.13 kernel. I was unable to connect to my Drobo FS NAS. Adding the vers=1.0 fixed the problem. I'll check if there is an update to the Drobo firmware - but I suspect not.
Scott wrote on 2019-03-27 17:35:
Thanks so much for this article. I was really hitting my head against the wall after upgrading Ubuntu - all my files were marked with the `x` bit set, and symlinks didn't work, preventing python from running on my server files. I knew something changed in the kernel, but couldn't find any information anywhere. There really should be better reporting of these kinds of changes that break existing behavior. I really don't see why they broke the client behavior either. I understand it is for security purposes, but the alternative is NFS which really completely on trust anyway, so what's the point?