0X000004E3 Error: Only Supported When Connected

Cause #1: Stale Mapped Drives That Failed to Reconnect

This is the culprit in about 80% of cases. You mapped a network drive, rebooted, and Windows never reconnected it. Now any app or script hitting that drive letter gets the 0X000004E3 error. The drive letter exists in Explorer, but the actual SMB connection is dead.

Here's the fix — don't bother checking the "Reconnect at sign-in" box in Explorer. It's flaky. Use a persistent net use command instead:

net use Z: \\SERVER\SHARE /persistent:yes

Run that from an elevated Command Prompt (right-click, Run as administrator). Test it by running dir Z: — if it works, you're good. If you get access denied, check your credentials or the share permissions. I've also seen cases where the drive letter was mapped from a group policy that expired. In that scenario, run gpupdate /force then net use Z: /delete and re-map it.

Sometimes you need to kill the dead mapping first. Run:

net use Z: /delete

Then re-map. That clears the ghost entry from the registry. Don't skip the delete step — leaving a stale mapping can cause this error to come back after the next reboot.

Cause #2: Offline Files or Folder Redirection Conflicts

This one's sneaky. If you have Offline Files enabled (common in corporate environments with redirected folders), the local cached copy can make Windows think the network path is available. But when an app actually tries to read from the server directly, the connection isn't live, and you get 0X000004E3. I've seen this most often with redirected Desktop or Documents folders on Windows 10 21H2 and 22H2.

First, check if Offline Files is on:

1. Open Control Panel, go to Sync Center
2. Click "Manage offline files"
3. Check the status on the General tab

If it's enabled, temporarily disable it (you'll need to reboot). Then see if the error stops. If it does, the fix is to either keep Offline Files off, or exclude the problematic share from offline caching. On the server side, set the share's Caching mode to "No files are available offline" — do this in the Share Permissions or via Set-SmbShare -Name SHARE -CachingMode None in PowerShell. That way Windows stops pretending the share is always connected.

Another variant of this: Folder Redirection itself fails. Check the event log under Applications and Services Logs > Microsoft > Windows > Folder Redirection. If you see error 0x80070035 or similar, the network path to the server is flaky. Fix that with a static DNS entry for the server in your hosts file — a quick workaround:

192.168.1.100 SERVERNAME

Add that to C:\Windows\System32\drivers\etc\hosts (as admin). It's hacky but works when DNS resolution is the real problem.

Cause #3: Windows Credential Manager Has Corrupted or Expired Credentials

This one's less common but still pops up. Windows stores saved credentials for network shares in Credential Manager. If the server password changed, or the credential entry got corrupted, you'll see 0X000004E3 even when the network is fine. The mapped drive shows up, but Windows tries to authenticate with bad creds and fails silently — until an app tries to use the drive.

Open Credential Manager from Control Panel (or search for it). Click "Windows Credentials" — look for any entries under "Generic Credentials" that reference your server or share. They'll look like TERMSRV/SERVERNAME or MicrosoftAccount:user@domain.com. Delete any entry for the server in question.

Now re-map the drive manually or via net use. Windows will prompt for fresh credentials. Enter them, check "Remember my credentials", and test it. One guy I helped had a typo in the saved password — someone changed the password on the server, but the old one was stored. Deleting the entry fixed it instantly.

If you're in a domain environment, also check if the computer account password is out of sync. That's rarer, but can cause this error for domain-joined machines trying to reach a file server. Fix it by resetting the machine's password with:

netdom resetpwd /server:DOMAIN_CONTROLLER /userd:DOMAIN\ADMIN /passwordd:*

Run that as admin. Reboot after. This forces a new secure channel.

Quick-Reference Summary Table

Start with cause #1. That's the one nine times out of ten. If you still see the error after doing all three, check the server itself — is the SMB service running? Can other machines connect? Sometimes the problem isn't on the client at all.