Force Mac SMB server to use SMB version 3.1.1

I am NOT an expert!!!! But, from what I've been reading, the values in the Protocol version map (and that may be seen in some places as `ProtocolVersionMap` or `protocol_vers_map` depending where you're looking/reading) is NOT a 1 for 1 value. At least for MacOS.

Instead it is a map. Done by each "bit" in the number being a flag, and for programmers, more commonly known as a bitmask.

Bit 1 is to enable/disable V1

Bit 2 is to enable/disable V2

Bit 3 is to enable/disable V3

And so, the values you have are

0 = In theory, support no version.

1 = Support ONLY V1

2 = Support ONLY V2

3 = Support V1 AND V2

4 = Support ONLY V3

5 = Support V1 AND V3

6 = Support V2 AND V3

7 = Support V1, V2, AND V3

That's the theory!

If you run the following ...

$ sudo scutil --prefs com.apple.smb.server.plist
Password:
> get /
> d.show
<dictionary> {
  DOSCodePage : 437
  LocalKerberosRealm : LKDC:SHA1.192345B0DB15F0814DDDA2A2AB4D3DE5983D84D8
  NetBIOSName : ArrayQueue-MBP
  ProtocolVersionMap : 255
  ServerDescription : ArrayQueue MPB
  SigningRequired : false
  protocolVersionMap : 2
}
>  quit

(You can type "help" if you want to see what you can do).

Now, with that, you'll see I've got mine set to 2, which, in theory, would be ONLY supporting v2.

But, if I run

$ nmap -p445 --script smb-protocols 192.168.0.101
Starting Nmap 7.95 ( https://nmap.org ) at 2024-06-17 13:12 BST
Nmap scan report for 192.168.0.101
Host is up (0.00018s latency).

PORT    STATE SERVICE
445/tcp open  microsoft-ds

Host script results:
| smb-protocols: 
|   dialects: 
|     2:0:2
|     2:1:0
|     3:0:0
|_    3:0:2


Nmap done: 1 IP address (1 host up) scanned in 5.16 seconds

Even after turning off/on SMB support and a reboot, the "dialects" are STILL exactly as they were when I started.

I've tried setting the version to 1, 7, 127, and 255 ... all common values to select everything (programming brain on this).

But no matter what I do, I can't get a Windows VM to see the shares from my Mac. But weirdly, I can quite happily see the shares from Windows on my Mac.

Also, the /etc/nsmb.conf file got completely wiped when I rebooted. So no idea on that either!

Like I said, not an expert on this and I'm as frustrated as anyone else would be. This ALL used to work. Need to try and get the old Intel MacBook Pro out of storage!

I think (pure opinion now on a decade of using MacBooks), Apple do not really think "developers" are their use case for MacBooks. This sort of "low level" (it really is NOT low level!!! I promise you that!!!) is "outside" of their target audience.

We all get used to detailed blogs, version controlled open sourced software with everything documented that when we come to something from Apple, it's almost like the idea of us asking questions like this is because we want to rip them off and steal all their IP ... or something like that!!!

Whilst there IS protectionism (and in cases, rightly so), the responses I've read really shows that no one has a clue! Some poor developer deep within Apple rights the code, and never gets to see the light of day in terms of the actual issues it is dealing with. Again, counterargument, we are a VERY small number of people who would have this issue, and so why focus so much energy on it.

Back and forth, swings and roundabouts.

I just wish it was more "open" so rather than us all finding bits and pieces all over the 'net, it would actually be handled via a decent Wiki of some sort. Something that knows how to organise information in a constructive manner.

And I bet you, there's probably an app for all of that that I've never heard of!

Rant over.

The server and the client are independent things. When hosting, the Mac uses the server software.

When connecting to SMB, the Mac uses the client software. The client using the 3.1.1 version does not imply that the server is running that version.

We have the opposite problem. Our Mac Sonoma 14.1 users cannot establish an SMB connection to the institutional SAN, as the institution's SANM does not support higher than SMB 3.0. We assume Sonoma is trying SMB 3.1.1.

Our Windows 11 users had the same problem, but there's a Window Registry that allows you to set the maximum negotiated SMB version — in this case from SMB 3.1.1 to SMB 3.0. And with that Registry entry, the Windows 11 SMB clients have no problem connecting to the institution's NAS.

Unfortunately, there is no corresponding MaxNegotiatedSMB setting in MacOS' /etc/nsmb.conf file.

Furthermore, there appears to be no way in MacOS Sonama's /etc/nsmb.conf file to limit SMB version to SMB v2.

In other *nix implementations, protocol_vers_map= can have arguments of 1, 2, & 3, corresponding to SMB 1, SMB 2, SMB 1/2.

But the MacOS 14.1 man pages for the nsmb.conf entry protocol_vers_map=, list only 4, 5, & 6, corresponding to SMB 3, SMB 2/3, & SMB 1/2/3 as valid arguments. And this seems to be deliberate, because any of:

protocol_vers_map=1

protocol_vers_map=2

protocol_vers_map=3

seem to have no effect if entered into MacOS 14.1's /etc/nsmb.conf file.

The property is case-sensitive!

You have all bits enabled in your post:

RQuadling wrote:

...

  ProtocolVersionMap : 255

...

  protocolVersionMap : 2

...

The item "protocolVersionMap" gets ignored because it is spelled wrong (lower case letter p) and the value "ProtocolVersionMap" has all relevant bits set to 1.

(the higher 5 bits are ignored)

You would need to install that version and configure macOS to use it instead of the built-in version.

I don’t know how to do that.

I do t know why that would be true.

there is much more testing involved in the server version than the client version.

Again, they are essentially independent pieces of software.