Backup-data fails with CIFS SMB2/SMB3

Bug
1

Hello,

I’m on latest NS version, trying to use the backup-data package with a Windows 2016 server as a CIFS repository (actually, it’s a Microsoft free Hyper-V 2016 server).

The backup-data.log says:
2018-02-17 01:00:10 - ERROR - Error while mounting 192.168.168.5:Backup : mount error(112): Host is down Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) 2018-02-17 01:00:10 - ERROR - Event pre-backup-data failed - 1

Searching the “Host is down” error, I found this thread

Indeed the missing option seems to be “-o vers=2.0”, since SMB1 has been disabled on this server due its to recent vulnerabilities.

Is there an option to enable it in the server manager or on command line ?
Thank you!
Davide.

2

Ok, digging more, I found /etc/e-smith/events/actions/mount-cifs
and changed line:

$err = qx(/bin/mount -t cifs “//$smbhost/$smbshare” $mntdir -o vers=2.0,credentials=$tmp,nounix 2>&1);

It works!
But I’m a bit afraid that my change will be overwritten by next packages updates.
Would be nice to be able to set CIFS compatibility level in the web gui.

Bye!

5 Likes
3

Thank you for the report.

We should probably add a new prop named something like SMBProtocolVersion.
The default should be v1 but the user must be able to choose v2 directly from the web interface.

What do you think?

1 Like
4

I don’t like it.
Even if I fear some regressions, I think that we should try to mount using the best protocol and try to fall back to earlier versions if the mount fails.

From mount.cifs manual we can try in order: 3.0 2.1 2.0 1.0

1 Like
5

And if an SMB server locks out after 3 login attempts? I suggest that interface can let the admin choose which version use.

6

Protocol version is not only about login.
We should always try to hide complexity.
And a future update from upstream will do what I’m suggesting.

7

Hide complexity is useful for not-skilled people. There’s already a specific distro which is called for human beings.
Or there’s another software for servers, homebased at Redmon.
Therefore, IMO, a toggle is preferrable.

8

I second the “best version first” approach, expecially given the recent commitment from Microsoft to try retiring the INSECURE SMB1: https://blogs.technet.microsoft.com/filecab/2016/09/16/stop-using-smb1/

NS users are sysadmins, so I would expect that anyone at least knows that there are different SMB/CIFS protocol versions.

My preference would go to a GUI-toggle, with latest or at least 2.0 being the default - and maybe an “insecure” warning next to the SMBv1 choice (helps spreading the awareness).

9

Of course we all can choose a protocol version 1 or 2, but I think @filippo_carletti is at the right way, because the target of Nethserver is:

Making sysadmin’s life easier

It is one thing less you have to look for.

10

In my Fedora, the man states:

vers=arg
The default since v4.13.5 is for the client and server to negotiate the highest possible version greater than or equal to 2.1. In kernels prior to v4.13, the default was 1.0. For kernels
between v4.13 and v4.13.5 the default is 3.0.

Probably we will have this patch in the upcoming kernel for RHEL 7.5 (https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7-beta/html/7.5_release_notes/new_features_kernel).

But if we are not getting this improvements, @Davide_Del_Grande would you like to open a PR to the code which tries all samba protocol version?

This is the relevant code: nethserver-backup-data/root/etc/e-smith/events/actions/mount-cifs at master · NethServer/nethserver-backup-data · GitHub

IMHO I would like to also have a prop to force a specific protocol, even if the prop could not been exposed inside the web interface.

11

Why not add a third link

  • General
  • Notification
  • Fine tuning / advanced configuration / ...
That way, you could keep the "simple" aproach because you'd have to only configure the general settings, and put the tryal of versions as default method. When one wants to go advanced, click the third link, and have the option to specify version manually, and disturbing no one I'd say. I'm not a sys admin, so my points of view might slightly differ, since in my case ns is just a plain old gateway, but at least one i feel comfortable using :slight_smile:
1 Like
12

I agree with the “fine tuning” approach, but I guess the mount command will handle most scenarios automatically.

Before implementing, let’s see if mount does its own job :wink:

But id someone want to try to open a PR, the steps should be:

  • create a new pop for managing protocol version
  • refactor the mount/umount actions to handle the new parameter (also check the is_mounted function)
  • add it to the Cockpit API
  • expose the new options inside the Cockpit UI
  • document everything
13

So, I’m not sure what fix 5687 is, I had set my backup destination NAS to v3 after I had the cifs mount error on a production network after upgrading to 7.6 and I’m fine with NS using smb3, I would prefer it didn’t downgrade to v2 or 2.1 and I’m not clear enough on the code change to be sure exactly what this fix does. I don’t see where the requirement is to use the highest available protocol. I’m not using cockpit yet either.

14

CIFS will try to auto-negotiate the following protocols: 3, 2.1, 2.0.
If none of these work, the mount will fail.

We added a workaround: if all the above fails, fallback to protocol 1.0.
This is necessary for old Samba version (like the one on NS 6).

(This is not related to Cockpit)

1 Like