无法以管理员身份在 PowerShell 中访问网络驱动器

我在 Windows7x64虚拟机中运行 PowerShell。我在主机上有一个共享文件夹,映射为网络驱动器(Z:)。当我正常运行 PS 时,我可以很好地访问该驱动器,但如果我以“管理员”身份运行它,它会告诉我:

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

如何以管理员身份访问网络驱动器?

118258 次浏览

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

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.

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

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
}
}
}

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.