2

We have two machines running Ubuntu, one of which was upgraded from 19.10 to 20.04 a week or so ago, and the other one yesterday. When the first one was upgraded, we went through the SMB problem learning curve, finding out that our router was now not accessible due to it running the discontinued SMB1 protocol (which is how our ISP provides them). We had to add

client min protocol = NT1

to the smb.conf on the 20.04 machine to get this access working again. Then we found that the 19.10 machine could no longer access the shared disk on the 20.04 machine, same symptoms as for the router access problem. Updating smb.conf with

server min protocol = NT1

on the 20.04 machine fixed that problem but left us with insecure access. Bad, but we were about to upgrade the other machine to 20.04 and hoped that would sort things out. It didn't - with both machines on 20.04 and without the server min protocol parameter we still got the same error. Restoring the server min protocol = NT1 setting on the machine hosting the share fixed the problem but we were back with insecure access again.

We also tried adding

server max protocol = SMB3

to sbm.conf on the hosting machine, but that made no difference, so we have had to take the server min protocol parameter out and lose access to the share for the sake of security. This is a big problem.

What I would like to understand is whether we have got something wrong or missing in the smb protocol parameters, or whether something somewhere is really restricting the protocol being used to SMB1 (aka NT1). I thought that the two 20.04 machines should negotiate the highest protocol that both could support (or the highest that a max protocol setting allowed). With the settings we have, I think this should be SMB3.

Improve this question

1 Answer 1

Reset to default
1

You have two issues:

[1] Accessing a server ( router in your case ) that can only use SMB1.

Samba disabled client SMB1 so the only way around it if you want to use the Nautilus is the "client min protocol = NT1" edit. You could of course use a CIFS mount specifying smb1 so that only access to the router is affected.

[2] Accessing a server that has disabled SMB1 on the server side. ( Win10, Ubuntu20, etc...)

This is actually a GVFS bug ( gvfsd-smb-browse ) not a samba bug. But it involves "discovery - then access" to the server not access by itself. You can still access the server but you must bypass the bug and access it directly. For example in Connect to Server:

smb://hostname.local/share-name

Or:

smb://server-ip-address/share-name

Again, you can bypass gvfs entirely and do a CIFS mount then you can specify whatever dialect version of samba you want.

Improve this answer
1
  • Thanks for your very useful comments and information. We're laying the router issue aside for the moment and may take it up with the ISP. For the server shares we tried your bypass suggestion using the IP format, and this gave us access using SMB3, plus we were able to set up a bookmark for convenience. Much appreciated. However while testing things out last night we found an issue with Krusader which may or may not be related, but I will post a question about this separately.
    – Judyk
    Jun 22, 2020 at 8:19

You must log in to answer this question.

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