STATUS_SERVER_UNAVAILABLE 0xC0000466 Fix (Windows)

I know that STATUS_SERVER_UNAVAILABLE error is infuriating — you double-click the mapped drive and Windows acts like the server never existed.

Here's the fastest path out: kill the stale mapping, flush DNS, and remap by IP so you can tell whether the problem is the server or your own name resolution.

The 3-command fix (try this first)

Open an elevated Command Prompt. Not PowerShell — the classic net use tool handles stale SMB sessions better in my experience.

net use * /delete /y
ipconfig /flushdns
net use Z: \\192.168.1.40\Shared /persistent:yes

Swap 192.168.1.40 for your file server's IP and Shared for the share name. If that connects, the server is fine and DNS or a stale session was the culprit. If it still throws 0xC0000466, the server side is genuinely down or unreachable — jump to the variations section.

Why this works

Windows caches SMB sessions, credentials, and DFS referral targets aggressively. When a file server reboots, gets a new IP from DHCP, or fails over to another node, that cache lies to Explorer. net use * /delete /y wipes every mapped drive and the underlying session table entry, forcing a fresh negotiation.

Flushing DNS matters because 0xC0000466 is often a name resolution failure dressed up as a server-down error. Your machine asks DNS for fileserver.contoso.local, gets a cached A record pointing at an old IP, tries to open SMB there, and nobody answers. Windows reports STATUS_SERVER_UNAVAILABLE because from its perspective, the server simply isn't there.

Mapping by IP bypasses that whole layer. If IP works and name doesn't, you've isolated the problem to DNS in about 30 seconds.

If the IP also fails — check these in order

Ping the server. ping 192.168.1.40. No response means network or firewall, not SMB.
Test the SMB port. Test-NetConnection 192.168.1.40 -Port 445 from PowerShell. A green TcpTestSucceeded means SMB is listening; red means the Server service is stopped or a firewall is blocking 445.
Check the Server service. On the file server itself, Get-Service LanmanServer. If it's stopped, start it. I've seen this after a botched Windows Update on Server 2019 more times than I can count.
Confirm SMBv1 isn't required. If the share lives on an ancient NAS (Buffalo TeraStation, older Synology DSM 5.x), it may only speak SMBv1. Windows 10 1709+ and every Windows 11 build disable SMBv1 by default. You'll get 0xC0000466 with no other clue.
Kerberos clock skew. If your workstation and the domain controller disagree by more than 5 minutes, authentication silently fails and SMB reports the server as unavailable. Run w32tm /resync.

Less common variations

Works after reboot, breaks in 10 minutes

That pattern screams DFS Namespace referral issue. Your client is bouncing between namespace targets, hitting a dead one, and giving up. Check with dfsutil /pktinfo. If you see stale targets, clear the referral cache: dfsutil /pktflush.

Only one user affected on a shared machine

Credential Manager is holding a bad entry. Open Credential Manager, look under Windows Credentials, and delete anything referencing the file server. Then re-map. This is common in RDS or Citrix environments where profiles get messy.

Offline Files is the actual villain

If the share is set to "Always available offline," Windows tries to serve it from cache and freaks out when the cache is stale. In Sync Center, disable offline files for that share, or run:

REG ADD "HKLM\SYSTEM\CurrentControlSet\Services\CSC\Parameters" /v FormatDatabase /t REG_DWORD /d 1 /f

Reboot. It rebuilds the offline cache. Warning: any unsynced changes in the offline cache are gone.

VPN users hitting it constantly

Split-tunnel VPNs route SMB traffic over the wrong interface. The server replies on the tunnel, the client expects it on the LAN, and Windows throws 0xC0000466. Add a static route for the server subnet through the VPN adapter, or fix the split-tunnel config. Don't try to patch this on the client — fix the routing.

Prevention so it doesn't come back

Give your file server a static IP or a DHCP reservation. Half the 0xC0000466 tickets I've closed traced back to a DHCP lease flip.
Use a DNS CNAME for the share name instead of hardcoding IPs. When the server moves, you change one record.
Set KeepConn registry value under HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters to 3600 or higher so idle sessions stay alive through lunch.
On the server, verify LanmanServer is set to Automatic and add a recovery action (restart the service on first failure) in the Services MMC.
Document the DFS target list. Every admin who's been paged at 2am knows stale DFS targets are the gift that keeps on giving.

Ninety percent of STATUS_SERVER_UNAVAILABLE calls end at the three-command block at the top. The rest are DNS, SMBv1, or DFS — and now you know exactly which rock to look under.