Home Networking

Troubleshooting Mapped Drive Issues After Restart

Mapped drives that disappear after a Windows restart often result from the system mapping before network or authentication are ready, wrong saved credentials, or a policy/logon script change. Start with reachability, persistent mappings or a delayed task, then collect logs if needed.

8 min read

Mapped drives that disappear after a Windows restart are usually caused by (1) the system attempting the mapping before network or authentication is ready, (2) missing or incorrect saved credentials, or (3) a Group Policy or logon script changing mappings. Start by confirming network and server reachability, then apply a persistent mapping or a delayed scheduled task and add the correct credentials to Credential Manager. If those steps fail, collect logs and escalate to server, DNS, or domain admins with the files listed below.

What you’re seeing and first quick checks

Typical observations.

  • The mapped drive letter is missing from File Explorer after sign-in, shows a red X, returns an authentication prompt, or produces a "network path not found" style error when accessed.

When it usually appears.

  • The symptom can appear immediately at sign-in or after a short delay when network services finish initializing.

Quick checks to run before changing anything.

  • Confirm the workstation has a network connection (wired or Wi‑Fi) and other network services work.
  • Try accessing the share directly from Run to rule out Explorer UI issues.
Run
\\server\share
  • Open File Explorer and note whether the mapped letter is present, absent, or shows a red X (disconnected).
  • Check Credential Manager for saved Windows credentials for the share; a missing or wrong credential can block automatic reconnection.
  • Determine scope: is the problem only for your user account or for all users on the machine? Try signing in with another account or check a colleague’s machine.

What the checks tell you.

  • If direct access to \\server\share succeeds, the network and server are reachable and the problem is likely timing or persistence. If direct access fails, investigate network, DNS, or server-side authentication first.

Before you start (applicability and prerequisites)

Scope and prerequisites.

  • This guide applies to Windows clients joining a domain or using local accounts mapping network shares via SMB.
  • You need an account that can create mappings and, if saving credentials, permission to store credentials in Windows Credential Manager.
  • If the workstation is managed by domain Group Policy, some local changes may be overwritten; check with your domain admin before changing domain-managed settings.

Safe checks and stopping conditions.

  • Stop if a command returns access denied; that indicates permissions you must not bypass.
  • If you’re unsure about changing SMB settings or enabling legacy SMB, check current vendor guidance before making protocol or registry changes.
  • Collect the outputs listed in the escalation section if a local fix doesn’t work.

Safe step-by-step fixes to try now

  1. Confirm current mappings.
Command Prompt
net use
  1. If the share is reachable manually, create a persistent mapping with explicit credentials.
Command Prompt
net use Z: \\server\share /persistent:yes
  • Expected result: "The command completed successfully." If it prompts for credentials, enter the correct ones. If it fails with access denied or network path not found, stop and troubleshoot reachability or permissions.
  1. Add or correct saved credentials in Credential Manager so Windows can reconnect at sign-in.
  • Open Credential Manager > Windows Credentials > Add a Windows credential.
  • Enter the server host name as the network address, the username in the required form (for domains use DOMAIN\username), and the password.
  • Expected result: Windows will use the saved credentials at sign-in. If it doesn’t, proceed to step 4.
  1. If the problem is timing (network or authentication not ready at sign-in), create a scheduled task that runs at logon and maps the drive after a short delay.
PowerShell (run as Administrator)
$Action = New-ScheduledTaskAction -Execute 'cmd.exe' -Argument '/c net use Z: \\server\share /persistent:yes'
$Trigger = New-ScheduledTaskTrigger -AtLogOn
$Settings = New-ScheduledTaskSettingsSet -AllowStartIfOnBatteries -DontStopIfGoingOnBatteries
Register-ScheduledTask -TaskName 'MapZAfterLogon' -Action $Action -Trigger $Trigger -Settings $Settings -RunLevel Highest
  • Then edit the task to add a 30–60 second delay if needed.
  • Expected result: the mapping appears after the delay. If it still fails, increase the delay slightly and check network readiness.
  1. Temporarily disable Fast Startup to test if session-state preservation is interfering with reconnects.
  • Control Panel > Power Options > Choose what the power buttons do > Change settings that are currently unavailable > uncheck "Turn on fast startup".
  • Expected result: if Fast Startup was the issue, disabling it will allow a clean initialization and may fix persistence. Re-enable it later if your environment requires it.
  1. If mappings are still inconsistent, check for Group Policy or logon scripts overriding mappings.
Command Prompt
gpresult /h C:\temp\gp.html
  • Open the generated file and look for logon scripts or drive-mapping GPO settings.
  • Expected result: if a GPO or script is altering mappings, the report identifies it and you can coordinate a change with your domain admin.
  1. Test SMB and server reachability for deeper issues.
PowerShell
Test-Connection server -Count 3
Get-SmbClientConfiguration | Select-Object -Property RequireSecuritySignature,EnabledProtocols
  • Expected result: ping succeeds and SMB client configuration is reasonable for your environment. If you suspect SMB protocol mismatches, check current vendor documentation before enabling legacy protocols.

How to verify the fix and test persistence

Follow this verification sequence after applying a fix.

  1. Confirm the mapping appears.
Command Prompt
net use
  • Expected output lists the mapped letter and the remote path. If it shows "Disconnected", authentication or network problems remain.
  1. Confirm SMB mapping status.
PowerShell
Get-SmbMapping
  • Expected output lists the local path, remote path, and connection status.
  1. Reboot the machine twice to test persistence and race conditions: first a normal restart, then another restart. After each restart, wait the same interval a user normally would and check net use/Get-SmbMapping.
  1. Perform a file operation on the mapped drive (open, read, write if you have permissions) to confirm functionality.
  1. Check Event Viewer if problems persist.
  • Open Event Viewer > Windows Logs > System and Application and look for errors with sources such as "Mup", "Workstation", "GroupPolicy", or authentication-related events around sign-in time. These entries help pinpoint timing or credential failures.

When to escalate and what to collect

Escalate when local fixes don’t work or when multiple users are affected.

Collect these items before contacting other teams so they can start triage quickly:

  1. Windows build and edition (use winver or systeminfo) and confirm it with the recipient, because some builds affect SMB behavior.
  1. net use output and Get-SmbMapping output captured after sign-in and after a failure.
Command Prompt
net use > C:\temp\netuse.txt
PowerShell
Get-SmbMapping | Out-File C:\temp\smbmapping.txt
  1. Relevant Event Viewer logs around sign-in time (System and Application) exported to files.
  1. ipconfig /all and DNS resolution for the server.
Command Prompt
ipconfig /all > C:\temp\ipconfig.txt
nslookup server > C:\temp\nslookup.txt
  1. Group Policy results.
Command Prompt
gpresult /h C:\temp\gp.html

Who to involve and when.

  • Server admin: server unreachable, server-side authentication errors, or share permission issues.
  • Network/DNS team: DNS resolving incorrectly, routing/DHCP problems during early logon.
  • Domain admin: if a GPO or logon script is removing or overriding mappings.
  • Vendor/Microsoft support: when you suspect a Windows build regression; provide the Windows build and the collected logs.

Preventive options

Practical measures to reduce recurrence.

  • Use persistent mappings with saved credentials where policy and security allow.
  • For domain environments, prefer Group Policy Preferences for drive maps when you need centralized control; coordinate with your domain admin so mappings apply after network and policy processing.
  • Use a short delayed scheduled task for clients with slow network initialization instead of forcing older SMB protocols.
  • Keep clients and servers patched per your organization’s lifecycle policy and check vendor documentation for SMB recommendations before changing protocol settings.

Conclusion

If a mapped drive vanishes after restart, first confirm network reachability and credentials, then create a persistent mapping or a delayed scheduled task to avoid timing races. If local fixes fail, collect the outputs listed above and escalate to server, network, or domain admins with those files. Check current vendor documentation before changing SMB protocol or registry settings.

Frequently Asked Questions

Why does a mapping work when I type the path but not at sign-in?

That usually indicates a timing problem: network drivers, domain authentication, or Group Policy haven’t finished when Windows first tries to reconnect the drive. A persistent mapping plus saved credentials or a short delayed scheduled task normally fixes this.

Is it safe to enable older SMB versions to restore connectivity?

Enabling legacy SMB can increase security risk. Don’t change SMB protocol settings without approval from your security or server team, and verify current vendor guidance before making protocol or registry changes.