Fix STATUS_SMB_NO_PREAUTH_INTEGRITY_HASH_OVERLAP 0XC05D0000

SMB 3.1.1 clients and servers can't agree on a preauth integrity hash algorithm. Usually caused by mismatched dialect or missing SHA-256 support on one side.

You're mapping a drive from a Windows 11 23H2 workstation to a Windows Server 2016 file share, or maybe an older NetApp. The credentials are right. DNS resolves. Ping works. And then Explorer spits out "The specified network name is no longer available" or a bare 0XC05D0000 from PowerShell. The event log on the client shows STATUS_SMB_NO_PREAUTH_INTEGRITY_HASH_OVERLAP. Or you're on Server 2022 and an SMB 3.1.1 connection from a fresh Linux cifs-utils 6.x client just dies during negotiate. Same code.

The reason this is confusing is that the error fires before authentication. You haven't sent a username yet. The negotiate is what fails. So credential troubleshooting is a dead end.

What's actually happening here

SMB 3.1.1 introduced something called the preauthentication integrity hash. It's a SHA-512 hash chain that both sides build during the negotiate and session setup, and it ties the negotiate request and response together so an attacker can't rewrite the negotiate fields in flight. The negotiate packet carries a list of hash algorithm IDs the client is willing to use. SHA-512 is the only one defined for SMB 3.1.1 in the spec, but Windows also has SHA-256 in the table.

STATUS_SMB_NO_PREAUTH_INTEGRITY_HASH_OVERLAP means exactly what it says: the client's offered set of hash algorithms and the server's offered set have zero overlap. Neither side sees a value in the other's list that it can use. The negotiate fails, the connection tears down, and the client falls back — or doesn't, depending on policy.

The classic trigger is a dialect mismatch. The client offers SMB 3.1.1 with preauth integrity. The server either doesn't support 3.1.1, or it does but its preauth hash table is empty because a third-party SMB stack (looking at you, older NetApp ONTAP, EMC VNX, and some Synology firmware) implemented the negotiate context but not the hash list. There's a second trigger worth knowing about: if someone has been fiddling with Smb2Dialect registry values or GPO SMB hardening on the client, you can end up with a client that advertises 3.1.1 but with a corrupted or missing hash list.

If you see this on a brand-new Server 2019 or 2022 box talking to another recent Windows box, suspect a security product — an SMB inspection or encryption appliance sitting in the path that rewrites negotiate packets. Palo Alto and some Fortinet configs used to do this with SMB inspection enabled.

The fix

Confirm the dialects on both ends. On the client, run:
```
Get-SmbClientConfiguration | Select-Object -ExpandProperty Smb2Dialect
```
On the server:
```
Get-SmbServerConfiguration | Select-Object -ExpandProperty Smb2Dialect
```
If the client says 3.1.1 and the server says anything lower, you've found it. The numbers are a bitmask: 0x0111 is 2.0.2, 0x0210 is 3.0, 0x0310 is 3.0.2, 0x0400 is 3.1.1. The server needs 0x0400 to negotiate preauth integrity.
Update the server if you can. SMB 3.1.1 landed in Server 2016 and Windows 10. If your file server is Server 2012 R2, it tops out at SMB 3.0.2 and cannot do preauth integrity at all. The real fix is upgrade the server, not patch the client. A 2012 R2 file server in 2024 is a compliance problem anyway, not just a compatibility one.
If you can't upgrade, pin the client to 3.0.2. This is a downgrade, and you should know it. Set on the client:
```
Set-SmbClientConfiguration -Smb2Dialect 0x0310 -Force
```
Or via registry at HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters, DWORD Smb2Dialect = 0x310. Reboot or restart the Workstation service. You lose preauth integrity and you lose the SMB 3.1.1 cipher negotiation (AES-128-GCM vs the older AES-128-CCM), but the share works.
Check for an SMB inspection appliance. Tcpdump or Wireshark the negotiate exchange. In Wireshark, filter smb2.cmd == 0 and expand the negotiate contexts. Look at the "Preauthentication Integrity Capabilities" context. If the hash algorithm count is zero, or the list doesn't match what the actual server software ships with, something in the path is rewriting the packet. Turn off SMB inspection on the firewall and retest.
Verify there's no stale dialect registry override. Group Policy under Computer Configuration > Administrative Templates > Network > Lanman Workstation has a "Minimum SMB2 dialect" setting. If someone set it, it may be forcing a dialect that the server's hash list doesn't cover. Check:
```
reg query "HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters" /v Smb2Dialect
```
Delete the value if you don't need it, restart Workstation, retest.

If it still fails

Grab a packet capture on both sides simultaneously. If the server-side capture shows a different negotiate response than what the client received, you've got a middlebox. That's the answer, and no client-side setting will fix it.

Also check the server's SMB event log. Event ID 30803 on the server side logs the negotiate failure with the offered hash list. If the server logs a hash list that includes SHA-512 but the client still fails, the client's SMB stack is the problem — usually a third-party filter driver from a backup agent or antivirus. Disable those on the client temporarily to confirm.

One more thing people miss: if you're using SMB over QUIC on Server 2022, the preauth integrity path is different and this error can appear while the QUIC listener is half-configured. Check Get-NetFirewallRule -DisplayName '*SMB*' for the UDP 443 rule. If it's disabled, the client tries QUIC, fails negotiate, and the error surfaces here rather than as a connection timeout.