Mapped Drive will not connect after reboot

Anonymous
2020-07-24T15:46:02+00:00

After a recent windows update I have had multiple issues with my network drives on my home network.  Some of these were caused by my router which I have replaced.  Now I have all but one drive working correctly.  I cannot figure out the one remaining problem. 

If I map the drive by the name (\MyBookWorld\Public) the map works OK until I reboot.  After reboot, I get the error of "The Specified network name is no longer available".  I cannot connect to drive via start>>run either.  If I try to access the drive by IP address using start>>run, it works.

If I disconnect the map drive and reboot, I can connect from start run to the drive after every reboot. 

If I map the drive by IP address, reboot and then try to use the drive, I get "Microsoft Windows Network:  The local device name is already in use".  Net use shows the drive disconnected and has an entry to the unc name.  It works if I use start>>run to the UNC name.

I have verified that smb is enabled on the machine.  I have made sure the services of "comptuer browser", "LanmanServer", and "LanmanWorkstation" are set to automatic start.

I have removed the mapping, made sure that it was not in the net use list in the command prompt and made sure the registries at HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2 for this drive have been removed.

I have added the mapping to the Hosts file.

I tried mapping to a different drive letter and get the same problem.  Any ideas on what in Windows is messing this up?

Windows for home | Windows 10 | Internet and connectivity

Locked Question. This question was migrated from the Microsoft Support Community. You can vote on whether it's helpful, but you can't add comments or replies or follow the question.

0 comments No comments

52 answers

Sort by: Oldest
  1. Anonymous
    2021-02-23T02:52:26+00:00

    I have updated some computers to 2004 and simply adding the provider flags to the letter and a reboot has resolved the issues

    located the Computer\HKEY_CURRENT_USER\Network\Z (what ever your mapping drive)

    "ProviderFlags"=dword:00000001 (32 bit d-word / hex value 1)

    please try it. hope you are Lucy~

    Was this answer helpful?

    0 comments No comments
  2. Anonymous
    2021-03-26T16:22:28+00:00

    I just started getting users reporting this issue. It sees the 2004 and 20H2 updates broke our mapped drives. These are users offsite that connect to VPN and then click their mapped (but disconnected drives) and it reconnects because the password was saved. Now it either removes the drives on a reboot and it's simply not mapped anymore. Or it will be mapped and throw an incorrect password the first time they try to re-connect, which is causing AD accounts to become locked after some many "Bad" password attempts.

    I've tried the above Registry key:

    HKEY_CURRENT_USER\Network\x (whatever letter your mapping the drive too)

    "ProviderFlags"=dword:00000001 (32 bit d-word / hex value 1)

    This does not work for us. The only workaround so far, is put a batch file on the desktop with the "net use" command to map the drive with /PERSISTENT:NO. Then after a restart, the user joins VPN and double clicks the batch file to map the drive.

    Was this answer helpful?

    0 comments No comments
  3. Anonymous
    2021-04-26T01:14:22+00:00

    20H2 made it worse

    Was this answer helpful?

    0 comments No comments
  4. Anonymous
    2021-04-26T08:36:02+00:00

    Hi!

    Yeah the new Synolgy DS1821+ works flawlessly.
    My old DLINK NAS DNS-345 not so much!

    I got this message today when trying to map it.

    Found this information: Microsoft

    And this information from DLINK: DLINK

    Meaning that my old NAS does not Support SMB2 and I have to activate it in Windows, See DLINK link how. Most likely after each windows update it seams too, as Microsoft deems it nessecary due to SMB1 not being safe enough.

    Was this answer helpful?

    0 comments No comments
  5. Anonymous
    2021-05-04T07:24:09+00:00

    "..Or it will be mapped and throw an incorrect password the first time they try to re-connect, which is causing AD accounts to become locked after some many "Bad" password attempts."

    I guess the VPN account of your offsite user are same as NT account but password is not the same which will cause AD account locked out.   change the VPN account name will make it works.

    Was this answer helpful?

    0 comments No comments