3

Question(s)

  • How - if at all - can I configure a client-specific or share-specific exception, allowing SMB1?
  • I understand the security risk with enabling SMB1 and therefore would like to minimize the attack surface. As long as there are exclusively shares configured allowing this sort of guest access, does it make a difference at whether I enable SMB1 or not?

Current situation

I have a Ubuntu 20.04 box with Samba 4.11.6-Ubuntu (2:4.11.6+dfsg-0ubuntu1.3) configured to accept connections to a particular share from anonymous connecting users (security = user with map to guest = bad password and at the share level guest only = yes and guest ok = yes).

This works fine from other Ubuntu machines. It does not work from an Android app called X-plore. The app will fail with the error message:

java.io.IOException: This client does not support the negotiated dialect.

There is a similarly configured Ubuntu 18.04 in my network, which has Samba 4.7.6-Ubuntu (2:4.7.6+dfsg~ubuntu-0ubuntu2.17) configured in a similar fashion to the above server.

This also works fine from other Ubuntu machines (no matter whether newer or older Samba is used) and it does work from said Android app X-plore.

Okay, so that suggests that the version difference between 4.7.6 and 4.11.6 is the cause of the issue here. The differences in the smb.conf boil down to path differences and differences based on expanded variables (server name and such, e.g. %h), so I can rule that out with high certainty.

The Android app reports SMB1 after connecting successfully to the Samba 4.7.6 server. So this would seem to be a likely cause for the issue with the 4.11.6 version:

SMB1 is disabled by default

The defaults of 'client min protocol' and 'server min protocol' have been changed to SMB2_02.

This means clients without support for SMB2 or SMB3 are no longer able to connect to smbd (by default).

The options for both of the remote Samba servers are given as follows in /etc/fstab (1. 18.04 2. 20.04):

$ awk '$3 ~ /cifs/ {print $4}' /etc/fstab|sed 's|'$(whoami)'|username|g'
nofail,user,guest,rw,uid=username,gid=username,forceuid,forcegid,file_mode=0664,dir_mode=0775,_netdev,x-gvfs-hide,noauto,x-systemd.automount
nofail,user,guest,rw,uid=username,gid=username,forceuid,forcegid,file_mode=0664,dir_mode=0775,_netdev,x-gvfs-hide,noauto,x-systemd.automount

... and the resulting mounted entries look like (same order as before):

$ awk '$3 ~ /cifs/ {print $4}' /proc/mounts 
rw,nosuid,nodev,noexec,relatime,vers=3.1.1,sec=none,cache=strict,uid=1000,forceuid,gid=1000,forcegid,addr=192.168.188.120,file_mode=0664,dir_mode=0775,soft,nounix,serverino,mapposix,rsize=4194304,wsize=4194304,bsize=1048576,echo_interval=60,actimeo=1
rw,nosuid,nodev,noexec,relatime,vers=3.1.1,sec=none,cache=strict,uid=1000,forceuid,gid=1000,forcegid,addr=192.168.188.130,file_mode=0664,dir_mode=0775,soft,nounix,serverino,mapposix,rsize=4194304,wsize=4194304,bsize=1048576,echo_interval=60,actimeo=1

So evidently the protocol version 3.1.1 was selected in both cases by mount.cifs when negotiating the protocol version from some recent Ubuntu.

To support X-plore, it seems I need to enable SMB1. And that could be done from smb.conf with:

[global]
min protocol = SMB2

1 Answer 1

1

I found the answer over on AskUbuntu.

The gist is to add the following line on the server-side into /etc/samba/smb.conf:

server min protocol = NT1

... followed by restarting smbd with either of the following (as superuser):

  • service smbd restart
  • systemctl restart smbd.service

After that the Android-side should be able to pick up on it. The difference is evidently the default minimum protocol version between the two Samba versions on 18.04 and 20.04.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .