As the title says, if I try to add -persist
to the cmdlt, it returns an error:
New-PSDrive : The network resource type is not correct
At line:1 char:1
+ New-PSDrive -Name P -Root <redacted> ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (P:PSDriveInfo) [New-PSDrive], Win32Exception
+ FullyQualifiedErrorId : CouldNotMapNetworkDrive,Microsoft.PowerShell.Commands.NewPSDriveCommand
For reference, this is an administrator session in PowerShell, but I get the exact same responses if I do this in a regular user session:
PS> $PSVersionTable.psversion
Major Minor Build Revision
----- ----- ----- --------
5 1 16299 666
From the start: I validate that the drive letter I want to use is available (P, in this case)
PS> get-psdrive
Name Used (GB) Free (GB) Provider Root CurrentLocation
---- --------- --------- -------- ---- ---------------
Alias Alias
C 36.80 22.11 FileSystem C:\ windows\system32
Cert Certificate \
D FileSystem D:\
Env Environment
Function Function
HKCU Registry HKEY_CURRENT_USER
HKLM Registry HKEY_LOCAL_MACHINE ...ntrol\NetworkProvider\Order
Variable Variable
WSMan WSMan
then I try to run: (I have already defined $locale
as a variable as, e.g., '\\foo\bar\'
).
New-PSDrive -PSProvider FileSystem -Name P -Root $locale -Scope global
Name Used (GB) Free (GB) Provider Root CurrentLocation
---- --------- --------- -------- ---- ---------------
P FileSystem \\foo\bar\
Happy days. That works. But of course, it's not visible to Windows Explorer, because it's just in this PS session. So, I destroy it (remove-psdrive P
) and validate it's gone (get-psdrive
), not shown here, then try to create a persistent version (same command, just with -persist
):
PS> New-PSDrive -PSProvider FileSystem -Name P -Root $locale -Scope global -Persist
New-PSDrive : The network resource type is not correct
At line:1 char:1
+ New-PSDrive -PSProvider FileSystem -Name P -Root $locale -Scope globa ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (P:PSDriveInfo) [New-PSDrive], Win32Exception
+ FullyQualifiedErrorId : CouldNotMapNetworkDrive,Microsoft.PowerShell.Commands.NewPSDriveCommand
And it fails. For context, I'm doing this so I can script using RoboCopy with remote PSDrives (we want to use robocopy because of its built-in reporting, attribute management, and the ability to maintain file structure at the destination, and we want to use PSDrives so we can specificy credentials for the target drives).
Does anyone have any ideas?
Edit: Oh man... I can't believe this.... But just in case someone else finds this, I'm going to leave it. The problem was the trailing \
in my path. I removed that, and it persisted just fine.
Update:
This problem has been fixed as of (at least) PowerShell 7.0.5 - however, it persists in Windows PowerShell (v5.1) and is unlikely to get fixed there.
A related problem that still exists as of v7.1 (the latest stable version as of this writing) is that using -Persist
also results in misleading error messages under true error conditions:Thanks, dgm.
The network resource type is not correct
error.The specified network resource or device is no longer available.
-Persist
, the error message is more sensible: The specified drive root "\\foo\bar" either does not exist, or it is not a folder.
(though it doesn't indicate which of the two error condition applies).[Windows PowerShell and PowerShell Core 6.x only] As you've discovered:
Don't specify drive root paths with a trailing \
, because doing so causes New-PSDrive
to fail with obscure error message New-PSDrive : The network resource type is not correct
when -Persist
is used:
# Trailing '\': only OK *without* -Persist.
New-PSDrive -root \\foo\bar\ -name N -PSProvider filesystem
# !! Breaks with -Persist:
New-PSDrive -root \\foo\bar\ -name N -PSProvider filesystem
# No trailing '\': OK both with and without -Persist
New-PSDrive -root \\foo\bar -name N -PSProvider filesystem
I've reported this unexpected behavior on GitHub, and a fix has been green-lighted for PowerShell Core, though it's unclear in what future version it will be available (written as of PowerShell Core 6.2.0-preview.1).