Why Does My Mapped Drive Disappear After Restarting Windows?

Short answer: Mapped drives usually disappear after a Windows restart because Windows tries to reconnect them before the network or VPN is ready, or because authentication or a policy on the PC or server prevents persistent reconnection. Start with the simple GUI option to reconnect at sign‑in and verify stored credentials; if that fails follow the ordered diagnostic and fixes below. If your PC is managed by an organization, IT policies or domain settings can override these fixes and you should involve your administrator.

Symptom: what you see and when it happens

You mapped a network share to a drive letter (for example Z:) and it worked, but after you restart or sign back in the drive is missing or appears with a red X in File Explorer.

This can happen immediately after signing in or only after a full reboot. The drive can be absent from File Explorer while net use either shows it as disconnected or doesn’t list it at all. If you get a specific error message when Windows tries to reconnect, record the exact text or error code.

Before you start (applicability, permissions and safe checks)

Scope: these steps cover user‑level diagnosis and fixes you can run on a personal or work PC where you have local user or administrative control. If the PC is domain‑joined or centrally managed, Group Policy or server settings may prevent persistent mappings; you will need IT help for those.

Prerequisites and safe checks:

• Be connected to the network used for the share (LAN, corporate Wi‑Fi, or VPN if required).
• Have the correct username and password for the share or permission to add credentials to Credential Manager.
• For commands and scheduled tasks you may need Administrator rights; if you don’t have them, stop and contact IT.

When to stop and call IT immediately:

• You see Group Policy explicitly removing mappings or applying drive‑map scripts that you cannot change.
• The share requires domain credentials you can’t update yourself.

Common causes (brief) — what leads to the symptom

• Network not ready at sign‑in: Windows reconnects drives early in the logon process; if Wi‑Fi, Ethernet, or VPN isn’t up yet the reconnect fails.

• Missing or incorrect credentials: Windows needs a valid stored credential to authenticate automatically at sign‑in.

• Drive letter conflict: another device or virtual drive is using the letter at startup.

• Group Policy or logon scripts: domain policies or scripts can remove or replace user mappings.

• Server, DFS or share permission issues: the server or namespace could be offline or permissions changed.

• Temporary or roaming profile problems: if Windows loads a temporary profile the saved mappings may not be present.

Each cause requires a different test and fix; the diagnostic sequence below keeps checks reversible and local changes safe.

Step-by-step fixes (safe, ordered from easiest to advanced)

1. Use the File Explorer reconnect option.

1. Open File Explorer and choose This PC > Map network drive.
2. Select the drive letter and enter the share path \\server\share.
3. Check Reconnect at sign‑in and finish mapping.

Expected result: the drive reconnects automatically after sign‑out/sign‑in. If it fails, continue.

2. Map the drive persistently with net use (use if the GUI option didn’t help).

net use Z: \\server\share /persistent:yes

Expected result: net use lists the mapped drive and it should persist after sign‑in. If you get an error, note the exact message.

3. Add or fix stored credentials in Credential Manager.

1. Open Credential Manager > Windows Credentials.
2. Add a Windows credential for the host (for example SERVER or \\server) with the correct username and password.

Expected result: Windows can authenticate at sign‑in and reconnect the drive. If authentication still fails, verify the account with the server owner or IT.

4. Try a different drive letter to avoid conflicts.

1. Remove the existing mapping (if present) with net use Z: /delete or from File Explorer.

net use Z: /delete

2. Map using an unused letter (for example Y:) from File Explorer or net use.

Expected result: if a letter conflict caused the issue, the new letter remains after restart.

5. Use a delayed reconnect via a scheduled task (for flaky or delayed network connections).

1. Create a scheduled task that runs at logon and waits for a short delay before running net use.

Start-Sleep -Seconds 20
net use Z: \\server\share /persistent:yes

Expected result: the task runs after the network is ready and re‑establishes the mapping.

6. Use Group Policy Preferences or a logon script (only if you administer the domain).

• Create a GPO Drive Map preference or a logon script that runs net use and target it to the correct OU. If you are not the admin, escalate to IT.

7. Check server/DFS and profile issues if client fixes fail.

• Test the share from another machine. If the problem affects multiple machines, the server or DFS namespace is the likely cause. Contact the server owner or IT.

• If you signed into a temporary profile, sign out and check Event Viewer for profile load errors and coordinate with IT.

Diagnostic checks before and during fixes

1. Confirm current mappings and status.

net use

Expected output: a list of mapped drives and their status. If the drive is listed as "Disconnected" or an error code appears, record it.

2. Test basic network and server reachability.

• Ping the server or use PowerShell Test-Connection, or enter \\server in File Explorer. If the server is unreachable, the issue is network or server‑side.

3. Check Event Viewer for errors at sign‑in time.

• Open Event Viewer and inspect System and Application logs around the time you sign in for network, credential or Group Policy errors.

4. Check applied Group Policy (for domain PCs).

gpresult /h gpresult.html

Expected result: the report shows applied GPOs; if a drive mapping policy is listed and you don't control it, contact your admin.

What checks tell you and next steps:

• Network not ready: use the scheduled task delay method and retest.

• Authentication failure: fix credentials in Credential Manager or ask IT to reset the account.

• Drive letter conflict: remap to a different letter.

• Group Policy removal: escalate to domain admin with the gpresult output and Event Viewer errors.

• Server/DFS problem: provide the server owner with evidence that other clients also fail.

Verify the fix

After you apply a fix, do the following verification steps.

1. Restart the PC and sign in.

2. Confirm the mapped drive appears in File Explorer.

3. Re-run net use and expect the drive to be listed with status OK.

net use

If the drive is present and shows as connected, the fix worked. If it still fails, collect net use output, Event Viewer errors from sign‑in, and a note whether the share is reachable from other machines, then contact IT or the share owner.

Preventive steps

• Use Credential Manager to store valid credentials for persistent authentication.

• If you rely on VPN for the share, configure the VPN to connect before sign‑in or use a delayed reconnect script.

• For domain environments, ask IT to deploy Drive Map preferences or adjust logon scripts so mappings reconnect reliably.

These measures reduce the chance Windows attempts to reconnect before the network or credentials are ready.

Conclusion

If the mapped drive still disappears after these steps, gather the `net use` output and Event Viewer entries from the sign‑in time and contact your IT team or the server owner. They can check Group Policy, DFS and server permissions that you cannot change from the client.