
{/* banner prompt: A matte clay-render still life in soft diffuse studio lighting: a cream-and-grey clay desktop computer on a low pedestal with a small terracotta drive-letter tile marked X floating just out of reach above it, connected by a dangling clay cable whose plug misses its socket, a faint clay signal-wave arcing off to one side into empty space, simple sage-green background with one terracotta accent block, soft long shadows, fingerprinted clay texture, minimal props, cinematic depth, 16:9, no text, no words */}

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:

![The Windows "Location is not available" dialog: "X:\... is unavailable. If the location is on a network, make sure you're connected to the network or Internet, and then try again."](https://storage.googleapis.com/www-tyolab-com-blog-assets/images/blog/2026/09/when-a-mapped-network-drive-keeps-going-not-available/location-not-available.png)

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, to 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:

```text
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, which is 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:

```powershell
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:

<Table data={
    {
        headers: ['Event ID', 'Count', 'Meaning'],
        rows: [
            ['30833', '15', 'The initial connection to the share was established'],
            ['30822', '10', 'Failed to establish an SMB multichannel network connection'],
            ['30827', '5', 'Could not find a certificate mapping that matches the server name'],
        ]
    }
} />

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:

```text
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:

```text
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:

```powershell
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:

<Table data={
    {
        headers: ['Symptom', 'Before', 'After (22 h)'],
        rows: [
            ['30822 multichannel failures', 'every reconnect', '0'],
            ['30827 QUIC certificate errors', 'every reconnect', '0'],
            ['Redirector "did not select" churn', 'every ~10 min', 'gone'],
            ['Reconnects', 'slow, stalling', 'clean and instant'],
        ]
    }
} />

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:

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

That was not the cause of *this* case, since 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, with 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.


0a4b5a511cb1e85d2ff6ff3d56a8a0b31344d0e580776eb63bf2fdf3eb2e07f6

A mapped network drive kept showing 'Location is not available' despite a healthy link; here is how to diagnose SMB Multichannel churn from the Windows event log and fix it with one line of PowerShell.

A mapped drive to a remote-office file server kept flapping to 'Location is not available', yet the network link was rock solid. The culprit was SMB Multichannel quietly chasing an address it could never reach. Here is how the Windows SMB event log gave it away, and the one-line fix.

When a Mapped Network Drive Keeps Going 'Not Available'


I run a custom trading gateway on a Windows 10 machine, primarily because it needs to interface with MetaTrader 5. I rely on MetaTrader to access market data and place orders for specific symbols and exchanges, like the ASX, that aren't available through my other tools. This setup is usually reliable, with the gateway using an SMB-based shared drive for data storage. However, that stability broke after I upgraded the machine to Windows 11, a necessary move with Windows 10 support ending. The first challenge I hit was the gateway losing access to its SMB share, which means I could no longer save the market data to the shared drive where my other pieces of trading software read the data from.

![](https://storage.googleapis.com/www-tyolab-com-blog-assets/images/blog/2025/10/fix-cannot-connect-to-smb-share-on-windows-11/windows-no-access.jpg)

After some investigation, I found that Windows 11 had tightened its security around SMB guest authentication, which was causing the connection issues. The data server hosting the SMB share only supported guest access without authentication, and with the new security measures in place, Windows 11 was blocking the connection.

## Quick sanity checks

Before diving into configuration changes, I ran through a checklist to rule out common issues:

- Verified the NAS was still reachable by IP using `ping` and `Test-NetConnection`.
- Confirmed other machines on the LAN could mount the share, isolating the failure to the trading PC.
- Cleared cached credentials with `cmdkey /list` and `net use * /delete`.
- Rebooted after installing the latest cumulative Windows updates in case a patch hardened SMB defaults.


> ⚠️ **Security note:** Insecure guest logons remove authentication from SMB connections. Only use this on a machine you control, on a trusted network, and keep it firewalled from the public internet. Disable the setting again once you retire legacy storage.

## The fix: allow guest logons again

A simple way to allow guest logons again is to enable the "insecure guest logons" setting via Group Policy as follows.

1. **Enable Insecure Guest Logins via Group Policy:**

   - Press **Win + R**, type `gpedit.msc`, and press Enter to open the Group Policy Editor.
   - Navigate to **Computer Configuration** > **Administrative Templates** > **Network** > **Lanman Workstation**.
   - Double-click **Enable insecure guest logons** and set it to **Enabled**.
   - Apply the changes and restart your computer.

![](https://storage.googleapis.com/www-tyolab-com-blog-assets/images/blog/2025/10/fix-cannot-connect-to-smb-share-on-windows-11/gpedit.png)

However, if you are using Windows 11 Home, you will need to use the Registry Editor method, as Group Policy Editor is not available.

2. **Enable Insecure Guest Logins via Registry Editor:**

   - Press **Win + R**, type `regedit`, and press Enter to open the Registry Editor.
   - Navigate to `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters`.
   - If the `AllowInsecureGuestAuth` entry does not exist, right-click and select **New** > **DWORD (32-bit) Value**, and name it `AllowInsecureGuestAuth`.
   - Set the value of `AllowInsecureGuestAuth` to `1`.
   - Close the Registry Editor and restart your computer.


After making the group policy change, you may still not be able to connect to the SMB share. The difference is that you probably don't have to wait for a few minutes for that error to come up. If you try to connect to the SMB share via `net use`, you may see an error like this:

```
C:\> net use Z: \\data-server\share
System error 3227320323 has occurred.
```

Try running the following command via PowerShell:

```powershell
Set-SmbClientConfiguration -RequireSecuritySignature $false
```

The above command is a PowerShell cmdlet that controls the SMB client "RequireSecuritySignature" setting. Running it sets whether the SMB client requires SMB packet signing for connections (our instance sets `RequireSecuritySignature` to `$false`). The `error 3227320323` indicates that the SMB client is requiring security signatures, but the server does not support it. So when set to true (the default), connections to servers that do not support signing will fail.

Restart your computer after running the command. After that, you should be able to connect to the SMB share again.

## Conclusion

After upgrading to Windows 11, I encountered SMB share connectivity issues due to Windows 11's stricter security policies around guest authentication. By enabling insecure guest logons through Group Policy (or the Registry Editor for Windows 11 Home) and disabling the security signature requirement with PowerShell, I was able to restore access to my legacy SMB share. This allowed my MetaTrader 5 gateway to resume saving market data to the shared drive.

Remember that these changes reduce security, so only apply them on trusted networks and on machines you control. Keep your firewall enabled and consider upgrading your storage solution to support modern authentication methods when possible.

2bcf2f01dea26dfa4c1a354137a47432623e072b57ca54cdc6a9cdb041fb777d

Troubleshooting checklist and final registry and group policy changes to let a MetaTrader 5 gateway reconnect to a legacy SMB share on Windows 11.

Steps I used to restore MetaTrader 5 access to an SMB share after Windows 11 hardened guest authentication.

Tag: Smb

Tag: Smb

When a Mapped Network Drive Keeps Going 'Not Available'

Fix: Cannot Connect to SMB Share on Windows 11