I've been trying al sorts of varieties of the following, trying to mount a network share in such a way it can be visible for both other shells and in File Explorer. According to the MS documentation of the related commands, saying one can use -Persistent
and -Scope Global
to make them "immediately visible to other shells", it just doesn't work.
$mDL = 'Z' # Mount to this Drive Letter
$dDesc = 'ML-DATA' # Description of PSDrive
$NLRoot = "\\somepath.windows.net\xxx"
$UserName = "localhost\someuser"
$cred = Get-Credential -Credential $UserName
New-PSDrive -Name $mDL -PSProvider "FileSystem" -Root $NLRoot -Credential $cred -Description $dDesc -Persist -Scope Global
The data container is in Azure, and everything seem to work apart from being visible from other parts in my system (Win10).
How can I make this drive visible from other PowerShell
instances and File Explorer?
UPDATE: 2022-07-06
My bad, the text was from the ss64 docs for New-SmbMapping, where it was stated:
When a drive mapping is created with New-SmbMapping the new drive will not be visible to any currently running processes (including Windows Explorer) until that process is restarted (or the machine is rebooted). The one exception to this is the PowerShell console, all PowerShell sessions on the machine will immediately get the new drive mappings.
It may also be that the MS documentation is not easily understood by non-specialists, because in the New-PSDrive docs, the following is stated in 2 places.
In Example-4
:
The mapped drive can be viewed on the local computer in PowerShell sessions, File Explorer, and with tools such as net use.
In the Paramters
list under -Persist
:
Mapped network drives are saved in Windows on the local computer. They're persistent, not session-specific, and can be viewed and managed in File Explorer and other tools.
So how can I make this share user and session type agnostic, in such a way that Z:
is visible "everywhere" and for "everyone" in both in File Explorer and whatever powershell/cmd they want to use?
Useful References:
I'm not sure if Azure-specific considerations apply, but, generally speaking:
tl;dr
"Immediately visible to all other shells" with respect to newly established persistent drive mappings applies to:
By default: Shell processes (such as PowerShell and cmd.exe
sessions) - more generally, (native) processes in general - that were created:
If your system is configured accordingly (see below): Processes that were created:
Note: All the information in this answer also applies to non-persistently mapped drives, assuming they are established with system-level features, such as net.exe use
or File Explorer. PowerShell does not allow you to create such mappings: if you omit -Persist
in a New-PSDrive
call, you'll get an (always non-persistent, session-specific and possibly scope-specific) PowerShell-only drive.
Persistently mapped network drives are user-specific:
As is to be expected, other users won't see a given user's persistently mapped drives.
Surprisingly, even in the context of the same user, trying to establish a persistent drive from an elevated session (run as administrator) does not work: the request to make the mapping persistent is quietly ignored (that is, the mapping is quietly only established for the current session and only visible to other elevated sessions of the same user).
By default, elevated vs. non-elevated sessions do not share drive mappings, so that no drive mappings initially exist in an elevated session.
As an aside:
Your New-PSDrive
command shows the use of both -Persist
and -Scope Global
, which is indeed required to successfully establish a persistent drive from a script (from a scope other than the global one, i.e. other than directly from the interactive prompt).
If you use -Persist
alone, it is quietly ignored: that is, a non-persistent, scope-local PowerShell-only drive is established.
Given that establishing a persistent drive mapping is unrelated to PowerShell's scopes, and that a successfully established persistent drive (or a non-persistent one established with net use
or from File Explorer) is by definition visible in all PowerShell scopes, there should be no need to also specify -Scope Global
- unfortunately, it was decided not to fix this usability problem: see GitHub issue #15752.