Windows 10 - named pipe path
Closed this issue · 4 comments
I've got Docker version 18.06.1-ce running and the named pipe is located at \\.\pipe\docker_engine
instead of \\.\pipe\docker_engine_windows
which leads to following error:
PS C:\Windows\system32> Import-Module dockeraccesshelper
PS C:\Windows\system32> Add-AccountToDockerAccess "JEML\lippertmarkus"
Ausnahme beim Aufrufen von "GetAccessControl" mit 0 Argument(en): "\\.\pipe\docker_engine_windows"
In C:\Program Files\WindowsPowerShell\Modules\dockeraccesshelper\0.0.1\Add-AccountToDockerAccess.psm1:36 Zeichen:5
+ $dSec = $dInfo.GetAccessControl()
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [], MethodInvocationException
+ FullyQualifiedErrorId : DirectoryNotFoundException
Es ist nicht möglich, eine Methode für einen Ausdruck aufzurufen, der den NULL hat.
In C:\Program Files\WindowsPowerShell\Modules\dockeraccesshelper\0.0.1\Add-AccountToDockerAccess.psm1:38 Zeichen:5
+ $dSec.AddAccessRule($rule)
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (:) [], RuntimeException
+ FullyQualifiedErrorId : InvokeMethodOnNull
Ausnahme beim Aufrufen von "SetAccessControl" mit 1 Argument(en): "Der Wert darf nicht NULL sein.
Parametername: directorySecurity"
In C:\Program Files\WindowsPowerShell\Modules\dockeraccesshelper\0.0.1\Add-AccountToDockerAccess.psm1:39 Zeichen:5
+ $dInfo.SetAccessControl($dSec)
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [], MethodInvocationException
+ FullyQualifiedErrorId : ArgumentNullException
Don't know if this has changed between the releases but I think it would be safe to check the existence of the pipe and maybe also autodetect the correct pipe path before setting the access rule. This way you could also handle errors that occur if the Docker daemon doesn't run and the pipe is therefore not present.
Good point, I'll improve that. To understand the effect: is Docker running in Linux container mode?
Docker is running in Windows container mode (as LCOWs work simultaneously anyway). But I found out that when running the docker engine as a service - and not just the dockerd binary in the command line - then both pipes are available (but with different access controls):
PS C:\> $npipe = "\\.\pipe\docker_engine"
PS C:\> $npipe2 = "\\.\pipe\docker_engine_windows"
PS C:\> $dInfo = New-Object "System.IO.DirectoryInfo" -ArgumentList $npipe
PS C:\> $dInfo2 = New-Object "System.IO.DirectoryInfo" -ArgumentList $npipe2
PS C:\> $dInfo.GetAccessControl()
Path Owner Access
---- ----- ------
JEML\lippertmarkus NT-AUTORITÄT\SYSTEM Allow FullControl...
PS C:\> $dInfo2.GetAccessControl()
PS C:\Windows\system32> $dInfo.GetAccessControl()
Path Owner Access
---- ----- ------
VORDEFINIERT\Administratoren NT-AUTORITÄT\SYSTEM Allow FullControl...
Setting the access control only on the first one did work for me.
@lippertmarkus should be fixed now. I first try to set the ACL on docker_engine_windows to match your case and the "standard" Win 10 case. Then I also do the same for docker_engine
@tfenster Thank you, this worked for me!
Unfortunately ACLs set on \\.\pipe\docker_engine
aren't restored after a restart like the ACLs on \\.\pipe\docker_engine_windows
which is only available when using the docker service which I can't use cause it's always eating up my whole RAM after a while (seems like a memory leak) - but that's another topic specific to me and doesn't belong here.