1. I map a share from another machine using my user account.
  2. I launch an elevated command prompt (cmd.exe, right click, Run as administrator).
  3. Navigating to shared drive (Z:) results in:

The system cannot find the drive specified

Now if I open a non elevated command prompt, I can navigate to Z: just fine.


Opening a Windows Explorer as administrator and recreating the network shares didn't work for me. Then, I found this solution: create the share on the command prompt itself. It worked for me.

net use f: \\remoteserver\subfolder      

Even if the drive is already mapped in windows explorer, still it worked.

Note: Only use a single backslash before subfolder

| improve this answer | |
  • I wasn't in the system directory so had to use "%systemroot%\System32\net" use f: \\remoteserver\subfolder – SharpC Jun 2 at 7:04
  • The system dir is usually in your %PATH%. I wonder if you're under some specific conditions? – msb Jun 2 at 7:37
  • Batch file. :-) – SharpC Jun 2 at 13:20

Probably that is not a problem of file permissions but it's related with:

  • Network shares being associated with sessions (i.e. different users may have a different set of network shares). Note that an user can have more that one session.
  • How User Account Control works.

Since almost all users used an administrator account in XP (as most programmers didn't bother to make their programs work with limited accounts), Microsoft made a "limited version" of administrator accounts starting with Vista, an in some situations the two "versions" counts as different users (since they are separate sessions).

Try launching an elevated Windows Explorer (i.e. a Windows Explorer launched with "Run as administrator") and recreate all network shares, that should do the trick.

The reason for having to recreate the shares is explained on this MSDN blog entry:

Mapped Network Drives with UAC on Windows Vista

Edit: relevant bits from the blog entry (emphasis mine):

To simplify things, let's assume you are running as an administrator with UAC enabled (although, to be more secure, it is better to run as a standard user). When you log in, you create a new token. We then detect that you have UAC enabled, we log in a second time, and end up with a new (highly restricted) token, which we use to launch the shell. There are two separate login events.
This convenience feature makes it easier to run into issues with mapped network drives. Prior to Windows 2000 SP2, device names remained globally visible until explicitly removed or the system restarted. For security reasons, we modified this behavior beginning with Windows 2000 SP2. From this point forward, all devices are associated with an authentication ID (LUID) - an ID generated for each logon session.
Because these mapped drives are associated with LUID, and because elevated applications are using a different LUID generated during a separate login event, the elevated application will no longer see any mapped drives for this user.

| improve this answer | |
  • 4
    i used an elevated Windows Explorer, and the elevated Command prompt still cannot find the mapped drive. – icelava Dec 27 '11 at 3:04
  • 1
    My understanding is that in Windows 7 when I "Run as administrator", its not actually running as the account with the name "Administrator" (Windows XP-ish), but rather as my account but with some super user bit set. I don't understand then why there is any difference between the two scenarios I described. – mindless.panda Mar 6 '12 at 16:15
  • 1
    There is a difference because the two "versions" of any administrator accounts for some aspects works as different account, even if they are really the same account with different permissions (that is explained in the blog I linked). – Alberto Martinez Mar 11 '12 at 14:12
  • 1
    @mindless.panda : You are absolutely right. The "Run as administrator" option refers entirely to the UAC-related Administrator setting. It simply has nothing to do with the Administrators group. If you disable UAC (which may require a reboot to fully take effect), you may find the "Run as administrator" option doesn't even exist while UAC is disabled. Note that an Administrator command prompt can still use the shared drives as UNC, e.g. \\servername\dirname --it's just the drive letters that get lost just because that's how Microsoft designed it. Remake 'em, and all's good in that prompt. – TOOGAM Feb 3 '15 at 20:29
  • I'm administrator, I can't launch an explorer window elevated (Win 8) – user15507 Apr 3 '17 at 16:52

Alberto Martinez answer describes why the mapped network drive is not accessible.

Here is registry fix to solve the problem:

  • Open regedit and go to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
  • Add a new DWORD (32-bit) Value named EnableLinkedConnections.
  • Adjust the value to 1 (or 00000001).

Exit regedit and restart the computer.

| improve this answer | |

I map a share from another machine using my user account.

that network drive is available ONLY in user account mapped the network drive.

| improve this answer | |

One other work-around that took me ages to find is to run net use from a scheduled task as the NT AUTHORITY\SYSTEM account. Apparently drives mapped under this account show up for all users and all elevation levels.

I've tested this and it works even on NFS shares (which can be a bit finicky). Just create a scheduled task set to run at system startup, and specify the following command:

net use //server/share Z: /persistent:no

It might possibly work to run it just once with /persistent:yes, but I haven't tried that. Granted, "just map it again" works too, but that drive still won't be visible to scheduled tasks running in different contexts. The downside is that all real users see it too, so not so good for multiuser setups.

(re-post from https://superuser.com/a/832042/7076 which is closed as duplicate)

| improve this answer | |

I had a similar problem today (24th Oct 2020) but in reverse.

Running on Windows 10 Enterprise, build 1909:

  • Log in using account with local admin rights.
  • Map some network drives using drive letters, eg Z:\my_mount using that account.
  • These are visible and usable in Windows Explorer and other applications.

So far, so good. However:

  • Still using that account, start Visual Studio, which runs as administrator, and you can't "see" these mapped drives it its file explorer. Nor will it find such files in an existing project where these are referred to by mapped letter, ie Z:\my_mount\filename. Even though you mapped them and tested them using identically this same user name a few seconds previously.
  • It will find them if you reference them by their UNC path, ie \server\my_mount\filename.

This drive letter mapping has worked in Visual Studio for as long as I can remember, and the change completely puzzled our corporate IT department who, collectively, swore blind it was nothing to do with them. Hmmm...

Apply the EnableLinkedConnections registry hack and magically it all works again. So thank you to Alberto Martinez.

| improve this answer | |

Start cmd as administrator, type in the command net use z: \\net\path /persistent:yes and you're done. Another thing I did, and this is extending past the op's question, was after pinning the cmd to the task bar and in properties->Advanced setting it to run as admin, I added /K z: to the end of the 'target' text box, so it became: %windir%\system32\cmd.exe /K z:. Because setting the "Start in" parameter didn't seem to work. This resulted in an icon on my taskbar that starts a cmd window as admin and with the prompt on the mapped drive. And don't forget to go to the properties again and customizing the font, colors, window size and position, as well as text scroll back buffer and command history buffer sizes!

| improve this answer | |

Opening a Windows Explorer as administrator and recreating the network shares didn't work for either (as user MSB's earlier comment). Running this in elevated command prompt would work, but cumbersome when having many mapped drives.

net use f: \\remoteserver\subfolder

My solution was running a 3rd party file manager with elevated privilegies. That would list the drives, even as they were not connected (and could not be reached from elevated cmd). Upon clicking on each drive in the file manager, it would be connected automatically, and it would then of course work from elevated cmd too. I tested this with two 3rd party filemanagers, total commander and double commander.

| improve this answer | |

Verify your network path, and disconnect the mapped drive (Z:) Run CMD as administrator, once there, use the "net use" command to map the drive again. net use Z: \SharePath then try access it again.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.