1

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:

not2qubit
  • 14,531
  • 8
  • 95
  • 135
  • 2
    Are you running PowerShell as an administrator? – tonypags Jun 30 '22 at 21:00
  • The New-PSDrive docs *never* say the drive will be visible by "other shells". `-Scope Global` means the drive will be visible outside the script's local scope – Panagiotis Kanavos Jul 01 '22 at 13:08
  • @PanagiotisKanavos, I'm guessing that quote is from non-PowerShell docs, given that establishing persistent drive mappings is not a PowerShell feature (only surfaced via `New-PSDrive`). And the quote _does_ apply, with the following constraints: By default, a mapping is immediately visible to all other shells created _by the same user_ AND if those shells have the _same session type_ (regular (non-elevated) vs. elevated (run as admin)). However, a system can be configured to make them visible irrespective of session type. – mklement0 Jul 01 '22 at 15:17
  • The word `shell` [doesn't even exist in the command docs](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/new-psdrive?view=powershell-7.2) and would be a very weird term to use in official documentation because it's a term used in the console subsystem. Other shells are Bash and zsh. The docs talk about sessions. I suspect that's what the OP is actually talking about. Even `console` would be inaccurate, because applications can create their own PS sessions in code – Panagiotis Kanavos Jul 01 '22 at 15:25
  • @PanagiotisKanavos, a persistent drive mapping _has nothing to do with PowerShell_, PowerShell just facilitates its creation, as `net.exe use` and File Explorer do. I have no idea where the quote came from, perhaps not2qubit paraphrased - it ultimately isn't that important. Yes, the word _processes_ would have been better. A more pertinent interpretation of "other shells" is other shell _sessions_, _irrespective of what shell binary underlies them_ (`cmd.exe`, PowerShell, ...). I've added a clarification re shell vs. processes to my answer; let me know if you think something is missing/wrong – mklement0 Jul 01 '22 at 20:24
  • Would it be possible using [`New-SmbShare`](https://learn.microsoft.com/en-us/powershell/module/smbshare/new-smbshare?view=windowsserver2022-ps) or [`New-SmbMapping`](https://learn.microsoft.com/en-us/powershell/module/smbshare/new-smbmapping?view=windowsserver2022-ps)? (TBH, I'm not exactly sure what the difference is between these 3?) – not2qubit Jul 05 '22 at 22:48
  • 2
    There's [`New-SmbGlobalMapping`](https://learn.microsoft.com/en-us/powershell/module/smbshare/new-smbglobalmapping), whose help states (emphasis added): "creates an SMB global mapping on the SMB client to an SMB share. Global mappings _allow all users to use the same mapping. Its primary use is for Windows Containers_." Not sure about the container angle. As for `New-SmbShare` vs. `New-SmbMapping`: the former is used on the _server_ to create a share that _clients_ can connect to; the latter is used on a _client_ to map a drive letter to a server's share. – mklement0 Jul 05 '22 at 23:30

1 Answers1

2

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:

    • by the same user and
    • have the same session type: regular (non-elevated) vs. elevated (run as admin).

  • If your system is configured accordingly (see below): Processes that were created:

    • by the same user
    • irrespective of session type.

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.

mklement0
  • 382,024
  • 64
  • 607
  • 775
  • The `New-PSDrive` docs never talk about other users or shells anyway. `-Scope Global` means the drive will be visible outside the local scope - the script – Panagiotis Kanavos Jul 01 '22 at 13:09
  • 1
    @PanagiotisKanavos, yes, but I just wanted to point that out explicitly. Also, that running as the _same_ user, but _with elevation_ does _not_ work, is far from obvious. That needing to _also_ use `-Global` with `-Persist` in scripts makes no sense, given that the former is related to PowerShell scopes, whereas the latter is an unrelated, system concept applying to a user's OS session as a whole. Sadly, they decided not to fix that; see [GitHub issue #15752](https://github.com/PowerShell/PowerShell/issues/15752). – mklement0 Jul 01 '22 at 13:18
  • It is, if you remember that Administrator sessions are isolated themselves. Which I always remember *after* something fails – Panagiotis Kanavos Jul 01 '22 at 13:24
  • Hi guys, thanks for a lot of useful information. But I'm still looking for a simple solution that from a UX point of view should be obvious, i.e. any mapped network drive/share that is created from that user login session, is expected to be accessible from all shells and file browsers etc. (Just like creating any old folder would be.) `How can I make this work?` – not2qubit Jul 05 '22 at 22:36
  • @not2qubit, you can't achieve this _across different user accounts_. In order to establish persistent mappings for multiple users, you'll probably have to use GPOs, as described [here](https://activedirectorypro.com/map-network-drives-with-group-policy/). – mklement0 Jul 05 '22 at 22:48