Elevated command line prompt can't access shared drives

Question

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.

Note added by barlop

With net use, An administrative(elevated) cmd prompt can access mapped drives created from an administrative cmd prompt, but the issue is that an administrative cmd prompt can't access a drive created from a non-administrative cmd prompt, and vice versa. So a mapped drive created by net use, from a non-administrative cmd prompt, can't be seen from an administrative cmd prompt. Net use can be used with local drives too and same issue for that. The Subst has the same problem.

Answer 1

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

Answer 2

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.

Answer 3

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.

Answer 4

Another 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)

Answer 5

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

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

Answer 6

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.

Answer 7

A far from ideal solution, is mklink, as it's not creating a new drive, but it is creating a directory on your local drive, that links to a network drive.

mklink doesn't have the problem that you are running into, that net use and subst have, which is that administrative cmd prompts and non-administrative cmd prompts can't see the results of each others net use or subst mappings.

You can use mklink, (some don't realise that mklink can be used for network "shares"). By the way likewise net use can be used for local directories too, just net use has the issue, as does subst(subst of course can't link to network drives).

Creating a symbolic link to mapped network drive in Windows

C:\Windows\system32>mklink /d c:\asdfbba \\192.168.0.30\carp
symbolic link created for c:\asdfbba <<===>> \\192.168.0.30\carp

C:\Windows\system32>dir c:\asdfbba
 Volume in drive C has no label.
 Volume Serial Number is 4645-5DCE

 Directory of c:\asdfbba

25/01/2022  20:31    <DIR>          .
25/01/2022  20:31    <DIR>          ..
25/01/2022  20:31               126 blah.txt
               1 File(s)            126 bytes
               2 Dir(s)  424,086,941,696 bytes free

C:\Windows\system32>

One weakness of mklink compared to net use, is that with mklink you can't specify a new drive letter. mklink will happily create whatever link, just not whatever drive.

C:\Windows\system32>mklink /d c:\asdfbbadsfsff \\192.168.0.30\acrp
symbolic link created for c:\asdfbbadsfsff <<===>> \\192.168.0.30\carp

C:\Windows\system32>mklink /d n:\asdfbbadsfsff \\192.168.0.30\carp
The system cannot find the path specified.

C:\Windows\system32>

You could make a c:\nw directory to make clearer that a thing in there is on the network, and you could get the link to be to c:\nw\blahcomp\carp for shared directory \\192.168.0.30\carp. You'd have to mkdir c:\nw\blahcomp then mklink /d c:\nw\blahcomp\crp \\192.168.0.30\carp (when you give mklink the first argument / the first actual parameter, if it's just one level then it isn't funny, but if it's multi-level e.g. c:\blah\bleh that you want to be your local link, then it willl create the last subdirectory (bleh), but you have to mkdir the parent of it.

Answer 8

I struggled with this for awhile. It is now working correctly for me, but I don't know what fixed it. (My PC has a fresh install of Windows 11 Pro for Workstations 23H2 (Version 10.0.22631), and my server is CentOS Linux.)

Note: Microsoft has a document about this exact problem, but it was written for Windows 7: https://learn.microsoft.com/en-us/troubleshoot/windows-client/networking/mapped-drives-not-available-from-elevated-command

Here are things I tried which might have contributed to the eventual success.

First, In "Network" I enabled network discovery and file sharing. (No joy.)

Then in Settings:

System -> (perhaps "Optional Features" -> ) "More Windows Features" -> enable SMB... (everything) [SMB 1.0 CIFS File Sharing Support]

(Alternately, I've read that from an elevated/Administrator prompt you can do: "DISM /Online /Enable-Feature /All /FeatureName:SMB1Protocol" which should be equivalent.)

Then restart.

Then I went to "This PC" (not "Network!" WHY WHY WHY, Microsoft??), clicked "...", then "Map network drive" with "Reconnect at sign-in" checked, and mapped my X: drive letter to my Samba share.

That enabled visibility of X: from non-elevated command prompts, but not from elevated ("as Administrator") command prompts.

Then I opened an elevated / Administrator CMD.EXE command prompt. From there:

I ran C:\Windows\explorer.exe

(Since I started it from an elevated command prompt, I hoped it would be running elevated, too.)

From the resulting Windows File Explorer window, I went to "This PC," clicked "...", then "Map network drive" with "Reconnect at sign-in" checked, and mapped my X: drive letter to my Samba share. (I might have "disconnected" it first -- sorry, I don't recall.) Then I closed the Windows File Explorer window.

(At first I thought that hadn't worked, but now I'm unsure.)

Back at the elevated / Administrator command prompt...

net use /persistent:yes
net use X: \\MYSAMBASERVER\myvolume /global
net use /persistent:yes

I probably also did this from a regular (not elevated) command prompt, but I doubt it was useful:

net use X: /delete
net use /persistent:yes
net use X: \\MYSAMBASERVER\myvolume /global
net use /persistent:yes

(There were several reboots along the way, too.)

And, now, after a reboot, both regular and elevated command prompts (and PowerShell prompts) can see my X: network drive.

Notes:

1. "net use /persistent:yes" is a standalone command, not an option to be added to the mapping command. From the documentation it is unclear whether it applies to future drive letter mappings or to already established mappings, so I did it both before and after the mapping command.

2. "wmic netuse" displays the "persistence" of an existing drive mapping, but it seems to have nothing to do with whether or not the drive mapping is reestablished after a reboot.

3. Running "net use" commands as a Scheduled Task never worked for me. I even tried running them from a .bat file, via a .lnk to the .bat file which forced the .bat file to run "as Administrator." It did no good.

4. I also could never manage to get anything to run as the "NT AUTHORITY\SYSTEM" account (which doesn't appear to exist on my system).

5. I don't know what, if anything, the /global option does. It is not mentioned in the net use documentation which I found.

Answer 9

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!

Answer 10

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.