Cannot access network drive in PowerShell running as administrator

Question

I am running PowerShell on a Windows 7 x64 virtual machine. I have a shared folder on the host displayed as a network drive (Z :). When I launch PS, I can access this drive just fine, but if I run it "as an administrator", it will tell 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: (Z:String) [Set-Location], DriveNotFoundException + FullyQualifiedErrorId : DriveNotFound,Microsoft.PowerShell.Commands.SetLocationCommand 

How to access network drives as an administrator?

Answer 1

In the end, the fix was just to reprogram the drive letter while working as an administrator:

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

This does not need to be done from a single PowerShell instance (or from PowerShell in general) - it is just what you need to do once for the entire login session.

Answer 2

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

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

Answer 3

Another workaround that took me several years to complete is to start net use from a scheduled task as an NT AUTHORITY \ SYSTEM account. Apparently, drives connected under this account are displayed for all users and all levels of access rights .

I checked this, and it works even on NFS resources (which can be a little finicky). Just create a scheduled set of tasks to start at system startup and specify the usual command:

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

Perhaps this may work to run it only once with /persistent:yes , but I have not tried this. Of course, “just match it again” also works, but this drive will still not be visible to scheduled tasks running in different contexts. The downside is that all real users see this too, so it’s not so good for multi-user installations.

Answer 4

I use the following hacker solution where I recreate the “missing” PSDrives in profile.ps1 when Powershell is running in enhanced 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 } } } 

Answer 5

How to display a new psdrive to access this data? PSDrives work just as well, if not better, than system mapped drives when writing scripts or accessing online datastores in powershell.

Instructions for using the New-PSDrive cmdlet are provided here: Technique: New-PSDrive

If you do not want to create a new psdrive every time you can add it to the profiles for both the administrator and your user account, and it will be automatically available every time you open PowerShell.

~ Dan

Answer 6

It seems like a known issue for Microsoft with Vista.
Microsoft Known unsafe fix base article .

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

Answer 7

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 started it as an administrator, it simply displayed a command prompt window and instantly disappeared; It worked fine when I ran the contents of a file from an elevated command prompt.

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