The smb-protocols nmap script checks to see which smb dialects are present on the Samba server.

client min protocol sets the minimum smb dialect that server can use to connect to another server not the minimum dialects that a client to this server can use.

By default the version of samba used in Ubuntu 18.04 sets the server min to NT1 ( smbv1 ) and the max to SMBv3.

If you want to restrict access to this server to SMB3 and SMB3 only you need to set the server min protocol:

server min protocol = SMB3

*Note: there are sub-variants to this dialect:

SMB3_00: Windows 8

SMB3_02: Windows 8.1

SMB3_10: early Windows 10

SMB3_11: Windows 10

By default SMB3 in smb.conf selects the SMB3_11 variant.*

put in the [global] section of /etc/samba/smb.conf the directive

min protocol = NT1

samba calls SMB1 as NT1.

Do you mean NTLM v1 authentication (ntlm auth = yes alias ntlm auth = ntlmv1-permitted) or SMB protocol v1 (server min protocol = NT1)? With a new enough version of Samba, you might need both of these settings.

(Modern defaults e.g. in Debian 11 are ntlm-auth = ntlmv2-only and server min protocol = SMB2_02.)

Unfortunately both of them are marked with (G) in the smb.conf(5) man page, indicating that these settings can only be specified in the [global] section of the configuration. This is probably because these settings affect the conversation between the client and the server even before the client can tell the server which share it wants to access.

Since the weakness of the SMBv1 protocol was the reason why the WannaCry ransomware managed to spread so fast and wide, the attitude towards it among security-aware administrators these days tends to be "kill SMBv1 with fire". You might want to e.g. set up a virtual machine, with a stand-alone Samba server dedicated to serving that old scanner and any other SMBv1 devices like that only.

If you want maximum security, you would then have any scanned documents first pass through an anti-virus check before transferring them to a share in another system that will be accessible using SMBv2 or greater, on the assumption that a malicious user might use the scanner's network connection to plug in a malware injector.

My testing with Nessus has indicated SMBv1 is only disabled when setting

min protocol = SMB2

in the [global] section of smb.conf . Core, LANMAN2 and NT1 were all still flagged as being vulnerable.

The issue here is very simple, Network browsing is using SMBv1!!! In the latest SNIA SDC Microsoft announced about the death of SMBv1(disable by default - register) but still the network browsing will work over SMBv1.

That is why you could not see your device. Try to modify only the server : server min protocol = SMB2_10 And leave the Client to support SMBv1

First, there is no such thing as a HomeGroup in Linux, MacOS, or Windows starting with Win10.

Second, if you are talking about that specific error when running smbclient you would need to enable SMB1 ( Samba calls it NT1 ) on the client side in /etc/samba/smb.conf. Right under the workgroup = WORKGROUP line add this one:

client min protocol = NT1

Of course the server you are trying to connect to must have SMB1 enabled on its side. If you kept your Win10 machine up to date it is disabled so you will have to enable it there. If the server is running Ubuntu 20 or anything with the same version of samba you would have to edit smb.conf on that machine and add:

server min protocol = NT1

Then restart samba:

sudo service smbd restart
sudo service nmbd restart

If you don't do that on the server you will likely get a protocol negotiation failed: error.

That will probably eliminate the SMB1 error message. Whether you can "discover" all the workgroups and hosts in Nautilus is another matter. If you have to turn the clock back to SMB1 days you need to follow the rules set at that era ... name resolve order, host name length restrictions, etc ...

After a lot of experimentation, in ubuntu 16.04.x this is the solution. Works with Thunar, Nautilus, pcmanfm, Dolphin file managers.

The fix suggested of setting "client max protocol = SMB3_10" in /etc/samba/smb.conf also fixed the problem for me. [1]

Do this in the client ubuntu machine, in addition to the server. This might sound weird but works. [2]

The current Samba version in Ubuntu 16.04 defaults to making NT1 (SMB1) connections even though it supports SMB2 and SMB3 - hence it works when you specify the client version from the command line. The default is scheduled to change to SMB3 in Samba 4.7 (due for release soon) and already does this in LE because we backported the change to Samba 4.6 for our codebase. You have two options:

a) Configure the system smb.conf in Ubuntu to have "client min protocol = smb2" and "client max protocol = smb3" so that smbclient connections are forced to use something higher than NT1 .. then you don't need to specify the protocol version manually.

1. From debian bug report https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883939

2. https://forum.libreelec.tv/thread/9920-solved-8-1-1-samba-access-from-linux-protocol-negotiation-failed/

The smpd version 3.6.x doesn't support SMB3, so it won't recognize it. Using max protocol = SMB2 should enable the SMB2 support, so start with it. If you then add min protocol = SMB2 the list gets quite narrow...

The LTS support for Debian 7 "Wheezy" ends on May 31, 2018. That's in less than a week. Upgraded Debian 9 comes with smbd 4.5.x, and SMB 3.0 is supported since smbd 4.2. It will support your max protocol = SMB3.