Bug 1474539

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

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...

There is a patch which just went into upstream which I guess made it to the rawhide kernel.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/cifs?id=eef914a9eb5eb83e60eb498315a491cd1edc13a1

Sachin Prabhu

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

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...

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.

Jeff,

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

This bug appears to have been reported against 'rawhide' during the Fedora 27 development cycle.
Changing version to '27'.

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

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.

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 //192.168.0.77/share /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.

Try vers=1.0 or vers=2.0 instead.

(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.

(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

(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.

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.
TCPDUMP:http://www.edcint.co.nz/tmp/smb.failsdefault.pcap

Forcing 2.1 works:
umount /mnt;mount -t cifs -o username=$user,password=$password,vers=2.1 //win0/c /mnt
TCPDUMP:http://www.edcint.co.nz/tmp/smb.worksforce2.1.pcap

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
TCPDUMP:http://www.edcint.co.nz/tmp/smb.failsforce3.0.pcap

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
TCPDUMP:http://www.edcint.co.nz/tmp/smb.failsforce3.02.pcap

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.

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.

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.

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.

Yeah, the new problem is clearly an entirely different bug and should be filed and handled separately. Thanks.

Create https://bugzilla.redhat.com/show_bug.cgi?id=1507342

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 - 2.06.02.10 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.

I've written this up in a blog post:

https://www.happyassassin.net/2017/11/03/linux-kernel-4-13-and-smb-protocol-version-fun/

cifs-utils-6.7-5.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-1e176ff4d3

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

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.

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.

On command line vers= is fine with 

cifs-utils-6.7-5.fc27

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

How would I specify vers= there?

Answer for all ye seekers out there is to add following to your 

/etc/samba/smb.conf

in the 

[global]

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

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


Then:

systemctl restart smb.service

Thus should do the trick...

Maybe raise max proto to SMB3...

Adding 

    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

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.

Thanks.