[Fix] Mapped Network Drives don’t work in Windows 10 v2004

After updating to Windows 10 version 2004, mapped network drives don’t reconnect after a restart. Here are some of the symptoms you may be experiencing:

• Mapped drives that link to your NAS (e.g., Synology, ReadyNAS, etc.) or Windows 2000/XP/2003 computers do not work after upgrading to Windows 10 v2004. Remapping the drive works only for the current session. Enabling the SMB 1.0/CIFS File Sharing support in Windows Features dialog also doesn’t help.
• As soon as the computer restarts, a red X sign appears on the mapped drive, and the drive doesn’t reconnect. The following error appears when you attempt to access the mapped drive:

  Restoring Network Connections

  An error occurred while reconnecting z: to \\computername\share_name

  Microsoft Windows Network: The local device name is already in use.

  This connection has not been restored.

  

• The UNC paths to network shares work correctly, but only if you haven’t already mapped a drive letter to the share. If not, the following error occurs when you access the share using the UNC path: (e.g., \\computername\share_name)

  \\computername\share_name is not accessible. You might not have permission to use this network resource. Contact the administrator of this server to find out if you have access permissions.

  Multiple connections to a server or shared resource by the same user, using more than one user name, are not allowed. Disconnect all previous connections to the server or shared resource and try again.

  

• When you try to connect to the network share using \\servername\share_name or \\IP_Address\share_name using the correct domain\username and password, you may get the error code 0x80070043 - The network name cannot be found.

Many users have rolled-back Windows 10 to version 1903 or v 1909 due to the above issues.

Let’s see how to fix this issue without having to rollback Windows 10 to v1909 or v1903.

Fix: Mapped Network Drives Don’t work in Windows 10 v2004

There are several fixes or workarounds for this issue. On my systems, I had to remove the Windows credentials for the target computer using the Credential Manager. Then, I remapped the drives, typed in the username and password for the network share. That did the trick on my Windows 10 v2004 systems.

Reset the stored credentials using Credential Manager

Removing the stored username & password for the network share, and then remapping the network drive helps in some cases.

1. Open Control Panel → User Accounts → Credential Manager
2. Select Windows Credentials
3. Under Windows Credentials, click the chevron next to the name of the network computer (or NAS) that hosts the share.
   
4. Click Remove to delete the stored credentials of that particular computer or share.
5. When the Delete Windows Credential dialog appears asking, “Are you sure you want to permanently delete this Windows credential?”, click Yes to continue
6. Exit the Credential Manager window.
7. Open This PC and disconnect the mapped drive.
   
8. Restart Windows.
9. Map the network drive again, with the Reconnect at sign-in option enabled.
10. Restart Windows to check if the drive mapping works.

That should fix the problem. If not, follow the next procedure.

Add the “ProviderFlags” registry value

Adding the ProviderFlags (DWORD 32-bit) registry value and set its data to 1 helps some users, especially if your mapped network drive points to an old SMBv1 share. Follow these steps:

1. Right-click Start, click Run, type regedit, and then click OK.
2. Locate the following registry subkey:

   HKEY_CURRENT_USER\Network\[drive letter]

   Note: The [drive letter] placeholder represents the mapped drive.

3. Create a new DWORD (32-bit) value named ProviderFlags
4. Double-click ProviderFlags value. In the Value data box, type 1
   
5. Repeat the above procedure for each mapped network drive on the computer.
6. Click OK, and exit Registry Editor.
7. Restart Windows.

See if the mapped network drive persists across reboot.

Credits to user LeeB1430 for the above fix.

Remove the S4U-based Scheduled Task(s)

After updating to Windows 10 2004, many users have found that Windows forgets the stored credentials in various applications, including Outlook, Edge, Chrome, etc. The mapped network drive issue you’re facing could be caused by some problematic scheduled tasks.

I've been experiencing a really bad Windows 10 bug since the 2004 update. I got so annoyed I spent my weekend debugging it. A specific type of scheduled task can break CryptUnprotectData(). If you've seen apps losing state, eventid 8198, or NTE_BAD_KEY_STATE, could be this.

— Tavis Ormandy (@taviso) September 28, 2020

To fix this issue, check out the article Windows 10 forgets stored credentials or passwords for Outlook, Edge, Chrome, etc.

Map network drives using a batch file

If none of the above fixes help, then, as a workaround, you can map the network drive at every startup using a batch file.

1. Copy the following lines and paste them in Notepad. Change the network or computer name, the share name, and the drive letter accordingly to match yours.

   timeout /t 30
   net use z: "\\networkname\sharedfolder" /persistent:no

   The parameter persistent:no is equivalent to unchecking the Reconnect at sign-in option in the Map Network Drive dialog box.

2. Save the file as mapdrive.bat
3. Open the Startup folder of your user profile by typing shell:startup in the Run dialog.
   (To know more about the shell: commands, check out this article.)
4. Place the batch file mapdrive.bat or its shortcut in the Startup folder.

That’s it. The drive mappings are created at every startup rather than making it persistent across reboots.

Note: A similar workaround using PowerShell is available in the Microsoft Knowledgebase article Mapped network drive may fail to reconnect in Windows 10.

Hope one of the fixes or workarounds helped you access your mapped network drives without any issues in Windows 10 2004.