PowerShell in Docker container does not map container drive mounts at start-up

Steps to reproduce

"'$('-' * 100)'",
'dir V:\',
"'$('-' * 100)'",
'dir FileSystem::V:\',
"'$('-' * 100)'",
'New-PSDrive V FileSystem V:\',
'dir V:\' | docker run -i --rm -v C:\Host\Path:V: microsoft/powershell pwsh -Command -

Expected behavior

V drive should be mapped at PowerShell start-up.

Actual behavior

Attempting to perform the InitializeDefaultDrives operation on the 'FileSystem' provider failed.
----------------------------------------------------------------------------------------------------
dir : Cannot find drive. A drive with the name 'V' does not exist.
At line:1 char:1
+ dir V:\
+ ~~~~~~~
+ CategoryInfo          : ObjectNotFound: (V:String) [Get-ChildItem], DriveNotFoundException
+ FullyQualifiedErrorId : DriveNotFound,Microsoft.PowerShell.Commands.GetChildItemCommand

----------------------------------------------------------------------------------------------------


    Directory: V:\


Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a----        6/30/2018   5:37 AM              0 Host file.txt


----------------------------------------------------------------------------------------------------

Name           Used (GB)     Free (GB) Provider      Root
----           ---------     --------- --------      ----
V                 156.80       1705.68 FileSystem    V:\




    Directory: V:\


Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a----        6/30/2018   5:37 AM              0 Host file.txt

Environment data

>ver

Microsoft Windows [Version 10.0.17134.112]

>docker --version
Docker version 18.03.1-ce, build 9ee9f40

I think this is expected. PowerShell drives created with the New-PSDrive command exist only in the PowerShell session used to create them unless they are mapped drives with the -Persist parameter.

this is an actual drive... you shouldn't have to create the drive...

Although, as a new platform, I'll classify it as an enhancement.

I was logged an issue when I noticed this behavior when using Azure Storage File Shares with a Windows Container flavored App Service. The problem stems in InitializeDefaultDrives failing, but the operating system mounted drive is mountable with New-PSDrive manually even though I.D.D. fails.

The guts of the problem seem to be that there is an #ifdef UNIX put in place for the FileSystemProvider when running on Unix/Linux that bypasses the problem of auto mounting azure file shares in Cloud Shell pwsh (which always runs on Unix now), but now that the App Service guys have added preliminary support for mounting storage file shares in Windows Containers, remoting into the container with pwsh gives a new context for this issue.

                        if (newDrive.DriveType == DriveType.Network)
                        {
                            // Platform notes: This is important because certain mount
                            // points on non-Windows are enumerated as drives by .NET, but
                            // the platform itself then has no real network drive support
                            // as required by this context. Solution: check for network
                            // drive support before using it.
#if UNIX
                            continue;
#else
                            displayRoot = GetRootPathForNetworkDriveOrDosDevice(newDrive);
#endif

So the problem is now the #else clause is running in this new container/docker context with a Windows base OS and an Azure Storage File Share because while [System.IO.DriveInfo]::GetDrives() returns the file share mounted drive, the code path for GetRootPathForNetworkDriveOrDosDevice blows up.

I guess we need some new runtime logic to harden this latter path from Azure file share pseudo network drives.

Travis Plunk (@TravisEz13)

Travis Plunk (@TravisEz13) A year ago this probably had little visibility. It's about to get a whole lot worse when Azure Storage File Shares come out of preview for Windows Container App Services, so if I may suggest you re-prioritize this. I've already seen some people move away from App Services to VMs to get past this problem because it didn't seem surmountable to them.

Aleksandar Nikolić (@alexandair)

Aleksandar Nikolić (@alexandair) The issue is that the file share is seen as a native windows drive by powershell's filesystemprovider and it attempts to create a PSDrive for it in the provider's startup, but it fails. But if we use new-psdrive z filesystemprovider -root z:\ it actually works.

Oisin Grehan (@oising)

Oisin Grehan (@oising) Does this issue only occur in docker mapped drives or is it specific to Azure Storage File Share. If it's the later, you should file a new feature request.

This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.

This issue has been marked as "No Activity" as there has been no activity for 6 months. It has been closed for housekeeping purposes.

Navigation Menu

Repository navigation

PowerShell in Docker container does not map container drive mounts at start-up #7212

Steps to reproduce

Expected behavior

Actual behavior

Environment data

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

PowerShell in Docker container does not map container drive mounts at start-up #7212

Description

Steps to reproduce

Expected behavior

Actual behavior

Environment data

Activity

alexandair commented on Jun 30, 2018

TravisEz13 commented on Jun 30, 2018

TravisEz13 commented on Jul 1, 2018

oising commented on Jun 12, 2019

oising commented on Jun 12, 2019

oising commented on Jun 12, 2019

TravisEz13 commented on Jun 12, 2019

microsoft-github-policy-service commented on Nov 16, 2023

microsoft-github-policy-service commented on Nov 16, 2023

microsoft-github-policy-service commented on Nov 23, 2023

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions