A mapped drive that is there on Monday and gone on Tuesday is one of the oldest tickets in IT, and it still comes in every week. The letter shows a red X, or it is missing entirely, or it is there but says access denied until the user reboots.
The causes group neatly: how the drive was mapped, whether the network was ready when Windows tried, and whether the credentials Windows used are still good. Work through those three and you will find it.
Red X, missing, or access denied
The symptom tells you where to start. A red X on the drive means the mapping exists but Windows could not connect to it at the time it tried, which is usually a network-timing problem. Double-clicking it often reconnects immediately, and the user assumes it was broken when it was only asleep.
A drive that is missing entirely was never created in this session, which points at Group Policy or a logon script that did not run, or ran before the network was ready. A drive that is present but gives access denied is credentials or permissions on the share. Ask the user which of the three they see before you do anything.
net useGroup Policy drive maps and the Replace trap
Most fleets map drives with Group Policy Preferences under User Configuration > Preferences > Windows Settings > Drive Maps. Each item has an Action: Create, Replace, Update or Delete. Replace deletes the drive and recreates it on every policy refresh, which by default is every 90 minutes or so. If the file server is unreachable at that moment, on a VPN or a bad Wi-Fi roam, the drive is deleted and not recreated until the next refresh. Use Update instead. It creates the drive if missing and leaves it alone if present.
Also check the Common tab. Item-level targeting that depends on a security group evaluated at logon, or Run in logged-on user's security context, changes when the mapping applies. And look at Computer Configuration > Policies > Administrative Templates > System > Logon > Always wait for the network at computer startup and logon. Without it, Windows uses cached policy and logs the user in before the network is up, so anything that needs the file server fails on the first pass.
VPN users and logon timing
On a laptop that connects to the VPN after logon, drive maps at logon are guaranteed to fail: the file server was not reachable when Windows tried. For those users, map the drive with Update and run gpupdate once the VPN is up, or use a logon script that waits for the server to respond before mapping, or map it manually with net use and the persistent flag. A device tunnel or always-on VPN removes the timing problem entirely and is the better fix for a mobile fleet.
Whatever you choose, map by DNS name, not by IP address. Names survive server moves and work correctly with Kerberos. A drive mapped by IP falls back to NTLM and breaks in other ways once NTLM is restricted.
net use S: \\fileserver.corp.example.com\share /persistent:yesCredentials and SMB settings
Access denied on a drive that used to work is usually a saved credential. Open Control Panel > Credential Manager > Windows Credentials and remove any entry for the file server; Windows will use the user's domain logon instead, which is what you want. If the user changed their password recently, a stale saved credential also causes account lockouts, so this fix does double duty.
Two settings on the server side cause drives to vanish after idle time. The Server service disconnects idle sessions after a timeout, which is normally harmless because Windows reconnects on the next access, but some applications handle it badly. And if the share is on an old NAS that only speaks SMB1, current Windows builds have SMB1 removed and the mapping will fail with an unhelpful error. Upgrade the NAS or its firmware rather than re-enabling SMB1. Finally, a drive mapped in a standard session is not visible to a program running elevated, which looks like a disappearing drive to admins; the EnableLinkedConnections registry value changes that behaviour if you really need it.
Consider retiring mapped drives
Drive letters are a habit, not a requirement. A DFS namespace lets you present shares under one path that survives server changes, and it can be mapped once and left alone. For teams already in Microsoft 365, SharePoint libraries with OneDrive shortcuts appear in Explorer without any mapping, work off the VPN, and survive laptops being rebuilt.
Neither is a quick change, and some line-of-business applications insist on a drive letter. But if the same disappearing drive ticket is a weekly event, the honest fix is to stop depending on the mapping. RackLedge has done both migrations for clients and can advise which fits your applications.
Frequently asked questions
Why does the drive show a red X but open fine when clicked?
Windows tried to connect at logon before the network was ready and marked it disconnected. Clicking it reconnects. Enable Always wait for the network at logon and use Update rather than Replace in the drive map policy.
The drive maps for some users and not others in the same office. Why?
Check item-level targeting on the drive map item, group membership, and whether the affected users have a stale credential for the server in Credential Manager.
Takeaway
Sort the ticket by symptom: red X is timing, missing is policy, access denied is credentials. Switch drive maps from Replace to Update, make Windows wait for the network, clear stale saved credentials, and map by name. If the ticket keeps coming back anyway, it is time to move the data somewhere that does not need a drive letter.