Cannot access network drive in PowerShell running as administrator

I'm running PowerShell in a Windows 7 x64 virtual machine. I have a shared folder on the host mapped as a network drive (Z:). When I run PS normally I can access that drive just fine, but if I run it "as administrator" it tells me:

Set-Location : Cannot find drive. A drive with the name 'Z' does not exist.
At line:1 char:13
+ Set-Location <<<<  Z:
    + CategoryInfo          : ObjectNotFound: (开发者_Go百科Z:String) [Set-Location], DriveNotFoundException
    + FullyQualifiedErrorId : DriveNotFound,Microsoft.PowerShell.Commands.SetLocationCommand

How do I access network drives as administrator?

In the end the fix was simply to re-map the drive letter while running as Administrator:

net use Z: "\\vmware-host\Shared Folders"

It doesn't have to be done from the same PowerShell instance (or from PowerShell at all) - it's just something that needs to be done once for the entire logon session.

In my case, I was able to simply use the UNC path instead of the drive mapping and it worked fine.

So, per your example, instead of using the mapped drive Z:\, I just used "\\vmware-host\Shared Folder" as the path.

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 usual command:

net use Z: \\server\share /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.

I'm using the following hacky solution where I recreate "missing" PSDrives in profile.ps1 when Powershell is running in elevated mode.

Gist

# Reconnect PSDrives for network connections when running with elevated privileges
$elevated = (([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator))
if( $elevated ) {
    net use | ?{ $_ -match ":\s+\\\\"  -and !$_.StartsWith("Unavailable") } | %{
        $tokens = $_.split(":")
        $psdrivename = $tokens[0][$tokens[0].length-1]
        $path = $tokens[1].trim().split(" ")[0].trim()

        if( !(get-psdrive | ?{ $_.Name -eq $psdrivename } )) {
            write-host ( "Restoring PSDrive for {0}: {1}" -f $psdrivename, $path )
            new-psdrive $psdrivename FileSystem $path | out-null
        }
    }
}  

How about mapping a new psdrive to acess that data? PSDrives work just as well if not better than system mapped drives when you are writing scripts or accessing network data stores in powershell.

Instructions for using the New-PSDrive cmdlet are here: Technet:New-PSDrive

If you don't want to have to make a new psdrive every time you could add it to the profiles for both the Administrator and your user account and it will automatically be available every time you open powershell.

~Dan

Seems like a known problem to Microsoft since Vista.
Microsoft Knowled base article with unsafe registry fix.

We are currently evaluating this approach as some of our guys have feelings that machine may not start after this ;-)

None of the other answers worked for me; but @TimothyLeeRussell's answer pointed me in the right direction.

In my case, I had a .bat file located on a network drive. When I ran it as administrator it would just flash a command prompt window and instantly disappear; it worked fine when I ran the file's contents from an elevated command prompt.

Finally I realized that I tried running the .bat file from the mapped network drive. I changed the execution of the file to use the UNC path and it worked.