Bug 1474539

Summary: Default CIFS protocol changed from SMB 1.0 to SMB 3.0 in kernel 4.13, breaks mounts from some servers
Product: [Fedora] Fedora Reporter: Adam Williamson <awilliam>
Component: cifs-utilsAssignee: Jeff Layton <jlayton>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 27CC: abokovoy, ads.kuknus, astarta, berrange, celinedioncdc, dobbels.geert, emilyjohan200, fradisel, heldwin, jlayton, ljglmail, marco.laverdiere, mariah9xx, pstrang_w_rzekle, raymondbarry78, redhatbugzilla, sprabhu, ssorce, steffen.mann, txellenne
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Fixed In Version: cifs-utils-6.7-5.fc27 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-11-14 00:56:12 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Adam Williamson 2017-07-24 23:23:35 UTC
I just upgraded my main desktop from Fedora 26 to Rawhide. Mounting a CIFS share provided by my NAS (a Thecus N5550) now fails, where it worked fine before. Any attempt to mount the share immediately results in:

mount error(95): Operation not supported

The /etc/fstab line for the share looks like this:

//nas/Media /share/data	cifs	rsize=8192,wsize=8192,nosuid,soft,guest,uid=99,gid=99,file_mode=0777,dir_mode=0777,users,comment=systemd.automount	0 0

but I've also tried just this:

mount.cifs //nas/Media /share/data

and this:

mount.cifs -o guest //nas/Media /share/data

and even this (from a stackoverflow suggestion):

mount.cifs -o guest,vers=3\.0 //nas/Media /share/data

and they all fail the same way. However, smbclient works:

[root@adam adamw]# smbclient -U guest //nas/Media
Enter SAMBA\guest's password: 
<hit enter>
Try "help" do get a list of possible commands.
smb: \> ls

Comment 1 Sachin Prabhu 2017-07-25 11:10:07 UTC
Hello Adam,

Can you please provide a tcpdump? Also, can you try using other mount versions such as 2.1 or 1.0.

Sachin Prabhu

Comment 2 Adam Williamson 2017-07-25 23:03:48 UTC
OK, so it works with 1.0 and 2.0, but not with 2.1 or 3.0. Did the default change, perhaps? The man page claims the default is 1.0, but it only works if I explicitly set 1.0 or 2.0 with a mount option...

Comment 3 Sachin Prabhu 2017-07-26 04:53:09 UTC
There is a patch which just went into upstream which I guess made it to the rawhide kernel.

Sachin Prabhu

Comment 4 Sachin Prabhu 2017-07-26 04:57:18 UTC
Sorry, I wasn't very clear with the above comment.

The default was changed to SMB 3.0 in keeping with the advisories issued by Microsoft to disable SMB1.0.

Sachin Prabhu

Comment 5 Adam Williamson 2017-07-26 06:00:37 UTC
I see; in that case, the man page should be updated to reflect that, and really, the cifs-utils release notes should have mentioned it...

Comment 6 Adam Williamson 2017-07-26 15:19:33 UTC
So adjusting the description. Not sure if we still want to treat this as a bug in any sense, but I'll leave that choice up to Sachin.

Comment 7 Sachin Prabhu 2017-07-28 05:26:28 UTC

I guess this change in default behaviour needs to be documented in the cifs-utils man page. Re-assigning the case to you.

Sachin Prabhu

Comment 8 Jan Kurik 2017-08-15 06:54:44 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 27 development cycle.
Changing version to '27'.

Comment 9 Adam Williamson 2017-08-24 15:34:22 UTC
We've just run into another consequence of this, involving qemu setting some type of lock on a file on a CIFS share: https://bugzilla.redhat.com/show_bug.cgi?id=1484130

Comment 10 geert 2017-10-09 21:41:19 UTC
Just upgraded to kernel 4.13 in Fedora 26 and cannot mount my CIFS share since then.

smb.service running
nmb.service running

I can access the share using smb://name-of-share

but mounting it via fstab gives following error:

mount error(112) host is down

don't know if this is the same bug or if I should file a new one.

Comment 11 Txe 2017-10-16 20:40:50 UTC
Same issue here. just updated to kernel 
`4.13.5-100.fc25.x86_64 #1 SMP Fri Oct 6 01:01:44 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux`
and cannot mount my CIFS share since then.

The only output I got is:
mount error(112) host is down

However I can mount without problems if boot on to the second kernel, the one I was using before updating. I also have tried adding the option `vers=3.0`
as following 

$sudo mount -t cifs // /mnt/share/ -o username=user,uid=root,rw,sec=ntlm,vers=3.0

but unsuccessful.

Would anyone know to give a clue on this? I'd appreciate it so much.

Comment 12 Adam Williamson 2017-10-16 21:46:07 UTC
Try vers=1.0 or vers=2.0 instead.

Comment 13 geert 2017-10-17 07:26:06 UTC
(In reply to Adam Williamson from comment #12)
> Try vers=1.0 or vers=2.0 instead.

Tried it without success...  I tried 1.0, 2.0 and 2.1 and always get the 

mount error(112) host is down 

Same as Txe, switching back to an 4.12 kernel lets me mount my cifs share.

Comment 14 geert 2017-10-17 07:44:51 UTC
(In reply to Adam Williamson from comment #12)
> Try vers=1.0 or vers=2.0 instead.

Update to my previous comment: 

The problem mentioned in my previous comment was with kernel 4.13.4

After posting my comment, I saw there was a 4.13.5 kernel and installed it.

Now the mount works, but only when using vers=1.0

The shared mount is a NAS disk, I guess it requires SMB1.0 to work.  Will have to check if I can update the firmware of the NAS

Comment 15 mlaverdiere 2017-10-21 12:16:21 UTC
(In reply to geert from comment #14) 
> Now the mount works, but only when using vers=1.0

Same experience here, on Fedora 27 beta: adding vers=1.0 to my fstab cifs config lines solves the problem with mounting various shares on a NAS disk.

Comment 16 redhatbugzilla 2017-10-29 10:29:18 UTC
This is more than just a problem with the default SMB dialect (version).

Using 4.13.9-200.fc26.x86_64, trying to mount a Windows 10 share (which does support up to SMB dialect 3.02).
Also fails using any 4.13 kernel on fc25 and presumably fc27

Use the default dialect (which is 3.02 for this server):
umount /mnt;mount -t cifs -o username=$user,password=$password //win0/c /mnt
umount: /mnt: not mounted.
mount error(5): Input/output error

Inspecting a tcpdump shows that this server supports 2.1, 3.0 and 3.02.

Forcing 2.1 works:
umount /mnt;mount -t cifs -o username=$user,password=$password,vers=2.1 //win0/c /mnt

Forcing 3.0 fails:
umount /mnt;mount -t cifs -o username=$user,password=$password,vers=3.0 //win0/c /mnt;mount | grep /mnt
umount: /mnt: not mounted.
mount error(5): Input/output error

Forcing 3.02 also fails:
umount /mnt;mount -t cifs -o username=$user,password=$password,vers=3.02 //win0/c /mnt;mount | grep /mnt
umount: /mnt: not mounted.
mount error(5): Input/output error

All the failures appear to fail on a step of the the SMB protocol "FSCTL_VALIDATE_NEGOTIATE_INFO" (part of Secure Dialect Negotiation). Version 2.1 does not do that step.

Dropping back to kernel 4.12.*, all the SMB versions (dialects) work just fine.

Comment 17 Jeff Layton 2017-10-29 11:22:47 UTC
Sorry for the delay here -- I missed the message where Sachin turned this into a documentation bug. I just sent a patch to linux-cifs mailing list to update mount.cifs manpage for it. The f28 package is building now, and I'll plan to update earlier release pacakges once the patch is merged into mainline cifs-utils.

As to redhatbugzilla.nz, you'll need to do some investigation. The server claims to support v3.0 but when the client sent a FSCTL_VALIDATE_NEGOTIATE_INFO call to the server, the server responded by breaking the TCP connection. You may need to check the server's logs to see why it did that.

It may be simpler to email linux-cifs.org if you need to help tracking down that problem.

Comment 18 redhatbugzilla 2017-10-29 11:41:02 UTC
The only problem with the theory that the server does not support v3.0 is that when I drop back to a 4.12 kernel and force v3.02 it works perfectly fine.

Forcing 3.02 works when using kernel 4.12.13-300.fc26.x86_64: 
umount /mnt;mount -t cifs -o username=$user,password=$password,vers=3.02 //win0/c /mnt

This points directly at the kernel.

Comment 19 Jeff Layton 2017-10-29 11:54:05 UTC
Fair enough then...

This is a documentation BZ for cifs-utils. You may want to file a kernel bug, or consider sending a problem report to the linux-cifs mailing list.

It might not also hurt to test a rawhide-ish kernel to see if this is something that might already be fixed. If not, and you're up for it, run a git bisect and narrow it down to the single patch that broke it and report that upstream.

Comment 20 Adam Williamson 2017-10-30 19:19:51 UTC
Yeah, the new problem is clearly an entirely different bug and should be filed and handled separately. Thanks.

Comment 21 redhatbugzilla 2017-10-30 21:21:32 UTC
Create https://bugzilla.redhat.com/show_bug.cgi?id=1507342

Comment 22 Adam Williamson 2017-11-03 20:05:07 UTC
So, couple of heads-up on things I've run into with this, for people who happen to be following this issue and using the same hardware/software:

* If you have a Thecus NAS running ThecusOS 5, the latest firmware - for my N5550 - adds SMB 3 support. It is not enabled by default, however. 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 min ver to NT1 if you have a client which cannot do 2 or 3, though. I'm not sure about ThecusOS 7.

* LibreELEC (the HTPC appliance OS forked from OpenELEC) added SMB 2 and 3 support with the recent 8.2.0 release: https://libreelec.tv/2017/10/libreelec-krypton-8-2-0-release/ . Earlier LibreELEC releases *do not support* SMB 2 or 3.

* OpenELEC updated Samba to 4.6 in its 8.0.4 release: http://openelec.tv/news/22-releases/188-stable-openelec-8-0-4-released . That should add SMB 2 and 3 support. I have not tested OpenELEC myself, though.

Comment 23 Adam Williamson 2017-11-04 01:40:38 UTC
I've written this up in a blog post:


Comment 24 Fedora Update System 2017-11-08 00:28:58 UTC
cifs-utils-6.7-5.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-1e176ff4d3

Comment 25 Fedora Update System 2017-11-08 20:31:10 UTC
cifs-utils-6.7-5.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-1e176ff4d3

Comment 26 Fedora Update System 2017-11-14 00:56:12 UTC
cifs-utils-6.7-5.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.

Comment 27 Fedora Update System 2017-11-14 09:23:56 UTC
cifs-utils-6.7-5.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.

Comment 28 steffen.mann 2017-12-06 05:59:02 UTC
On command line vers= is fine with 


But how to mount with smb://your_share with file browsers such as nautilus / nemo

How would I specify vers= there?

Comment 29 steffen.mann 2017-12-06 06:44:02 UTC
Answer for all ye seekers out there is to add following to your 


in the 


        client min protocol = CORE
        ; default is 'CORE' (MS-DOS era)

        client max protocol = NT1
        ; default is 'NT1' (aka CIFS)


systemctl restart smb.service

Thus should do the trick...

Maybe raise max proto to SMB3...

Comment 30 steffen.mann 2017-12-06 06:58:30 UTC

    client min protocol = CORE
        ; default is 'CORE' (MS-DOS era)

        client max protocol = NT1
        ; default is 'NT1' (aka CIFS)

in [global] section of your /etc/samba/smb.conf file

and then:

systemctl restart smb.service  

should do the trick

Comment 31 pstrang 2018-02-15 00:23:30 UTC
Anyone know why gnome/nautilus/gvfs/fuse can't handle anything other than what steffen posted?

in [global] section of /etc/samba/smb.conf file:

    client min protocol = CORE
        ; default is 'CORE' (MS-DOS era)

        client max protocol = NT1
        ; default is 'NT1' (aka CIFS)

I've tried various combinations of SMB1, SMB2, and SMB3.  Nothing works except the above.


Comment 37 raymondbarry78 2023-02-24 04:42:03 UTC Comment hidden (spam)
Comment 38 Celine Dion 2023-04-13 04:09:53 UTC Comment hidden (spam)
Comment 39 reks 2023-06-20 21:28:20 UTC Comment hidden (spam)
Comment 40 williamliz 2023-08-07 03:29:46 UTC Comment hidden (spam)
Comment 41 boss 2024-01-29 15:38:39 UTC Comment hidden (spam)