When a Mapped Network Drive Keeps Going 'Not Available'eric

Every so often a support problem is interesting not because it is hard, but because every obvious explanation is wrong. This was one of those. A user at a branch office had a mapped drive — good old X: — pointing at the head-office file server. Several times an hour it would simply stop working. Open it from Explorer or try to save into it from a browser, and Windows threw up the dialog everyone has seen and nobody has ever found helpful:

Click OK, wait a moment, try again, and it usually worked. Then a few minutes later it would be gone again. The user's summary was blunt and accurate: "X: is very unstable, it keeps saying not available."

The dialog's own advice — check that you are connected to the network — is a dead end here, because the network was never the problem. Let us walk through how to prove that, and then find the thing that actually was.

Ruling out the usual suspects

An intermittently missing network drive has a short list of usual causes, and it pays to knock them down with evidence rather than assumption.

Was it a permissions problem? No. Reads worked, and a scripted write test — create a temp file at the share root, in a subfolder, and via the raw UNC path — succeeded every time. If the account could not write, it would fail consistently, not intermittently. Permissions were fine.

Was it a bad link? This is the one everybody reaches for, and it was wrong too. The server was reached over the internet, so a flaky WAN would have been a plausible story. Except the numbers said otherwise:

Copy Resolve  fileserver  -> 202.1.123.10   (the public/reachable address)
Ping     8 of 8 replies, 0% loss, 30-31 ms, near-zero jitter
TCP 445  reachable: True

Zero packet loss, rock-steady 30 ms, and port 445 open. That is a healthy path. Whatever was happening, the link between the two sites was not dropping.

Was the drive just idle-disconnecting? Windows does tear down idle SMB sessions and a mapped drive can show a red X until you touch it again — mildly annoying but cosmetic. That was part of the picture, but it did not explain why reconnecting was so unreliable. So we went to the one place that actually knows: the SMB client's own event log.

The SMB client keeps a detailed diary

This is the part worth stealing for your own toolkit. The Windows SMB client logs its connection lifecycle in two logs that almost nobody opens, under Applications and Services Logs → Microsoft → Windows → SMBClient:

• SMBClient/Connectivity — connects, reconnects, and connection failures.
• SMBClient/Operational — the redirector's decisions about which connection to actually use.

You can read them straight from PowerShell. Group by event ID first to see the shape of the problem:

Copy Get-WinEvent -LogName 'Microsoft-Windows-SmbClient/Connectivity' -MaxEvents 40 |
  Group-Object Id | Sort-Object Count -Descending |
  Select-Object Count, Name

On the misbehaving machine, that came back looking like this — a connection being re-established over and over, interleaved with two kinds of failure:

A stable drive connects once and stays put. Fifteen "initial connection established" events in a few minutes is not stability — it is a drive reconnecting constantly. And sitting right next to each burst were multichannel failures and a certificate error. The full text of a single 30822 event is where the case cracked open:

Copy Failed to establish an SMB multichannel network connection.
Error: {Device Timeout}
Server name:    fileserver
Server address: 192.168.10.8:445      <-- a private address
Client address: 192.168.20.245        <-- a different private subnet
Connection type: TCPIP

... and a second one:
Server address: 192.168.10.8:443
Connection type: Quic

And in the Operational log, the matching verdict:

Copy The SMB redirector did not select the connection initiated with the following parameters:
  IP Address: 192.168.10.8:445
  The failure status associated with this decision:
  The network path cannot be located.

The root cause: SMB Multichannel dialling the wrong number

Here is what was actually going on.

The file server is dual-homed. From the branch office you reach it over the internet at its public address (203.0.113.10). But when an SMB session sets up, part of the negotiation is SMB Multichannel: the server helpfully tells the client about all the network interfaces it has, so the client can open extra parallel connections for throughput and resilience. Great feature — on a LAN.

The trouble is that one of the interfaces the server advertised was its internal LAN address, 192.168.10.8. The branch office is on a completely different private subnet (192.168.20.0/24), with no route to the server's internal network. So every time the drive reconnected, the client dutifully tried to open a multichannel connection to 192.168.10.8 — an address it can never reach — and sat there until it hit a device timeout. For good measure it also tried SMB over QUIC (UDP 443) to the same dead address, which failed on a certificate mismatch (the 30827 events).

None of those extra channels can succeed, so the redirector eventually falls back to the one connection that works — the public path. But by then the user has already been staring at "Location is not available," because the drive appeared dead during the seconds Windows spent timing out on the phantom address. Combine that with the normal ~10-minute idle disconnect, and you get a drive that feels broken several times an hour on an otherwise perfect link.

Microsoft's own guidance text in the 30822 event even says these extra-channel failures "will not result in an application error" — and strictly that is true, the failure is harmless. What is not harmless is the time spent failing. That delay is the whole user-visible symptom.

The fix: one line

On a single-link workstation, SMB Multichannel buys you nothing — there is only one path to the server. So the correct move is to stop the client from probing for extra channels at all:

Copy Set-SmbClientConfiguration -EnableMultichannel $false -Force

It is a client-side setting, it takes effect on the next connection, and it is trivially reversible ($true to restore). No feature is lost on a machine with a single route to the server; the client simply stops chasing addresses it cannot reach and goes straight to the working one.

The proof is in the same event log afterwards. With Multichannel disabled and 22 hours of normal use:

The reconnects that remain are normal, healthy idle reconnects — they just complete instantly now, via the good path, instead of stalling on a dead one. The drive stopped vanishing.

A related trap, while we are here

There is a second, unrelated reason a mapped drive can read "not available" that is worth knowing, because it looks identical from the user's chair: the UAC linked-connection split.

If the signed-in user is a local administrator, Windows gives them two security tokens — a normal one and an elevated one — and mapped drives are not shared between them. So a drive mapped in the normal session is invisible to any app running as administrator. Launch a program elevated, and your perfectly good X: is simply not there. The fix is a documented registry value:

Copy HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
EnableLinkedConnections = 1   (DWORD)   then reboot

That was not the cause of this case — the flapping was — but it is the first thing to check if a drive is visible in Explorer yet missing inside one specific elevated application.

Takeaways

• "Location is not available" is a symptom, not a cause. The dialog blames the network; believe the evidence instead.
• Prove the link before you blame it. Loss, latency and a TCP 445 check take thirty seconds and rule out the most tempting wrong answer.
• The SMBClient event logs are gold. Connectivity and Operational under Microsoft-Windows-SmbClient tell you exactly which address the client tried and why the redirector rejected it — no packet capture required.
• SMB Multichannel assumes a LAN. Point a client at a dual-homed server across the internet and it will happily try to reach the server's private interfaces. On a single-path client, EnableMultichannel $false is a clean, reversible fix.

Sometimes the machine really is doing exactly what you told it to. It was just trying to call a number that no longer answers.