Error 'Access is denied' from NamedPipeClient when starting Docker 10.03.1 on Windows 10 1803

[maximdim]

• Windows Version: 10 Pro (1803)
• Docker for Windows Version: 18.03.1-ce-win65 (17513)

Expected behavior

Docker starts.

Actual behavior

Docker failing to start with the following error:

Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))
at Docker.Core.Pipe.NamedPipeClient.Send(String action, Object[] parameters) in C:\gopath\src\github.com\docker\pinata\win\src\Docker.Core\pipe\NamedPipeClient.cs:line 36
at Docker.Actions.DoStart(SynchronizationContext syncCtx, Boolean showWelcomeWindow, Boolean executeAfterStartCleanup) in C:\gopath\src\github.com\docker\pinata\win\src\Docker.Windows\Actions.cs:line 67
at Docker.Actions.<>c__DisplayClass14_0.b__0() in C:\gopath\src\github.com\docker\pinata\win\src\Docker.Windows\Actions.cs:line 51
at Docker.WPF.TaskQueue.<>c__DisplayClass19_0.<.ctor>b__1() in C:\gopath\src\github.com\docker\pinata\win\src\Docker.WPF\TaskQueue.cs:line 59

Information

• Diagnostic ID: 68F91BA5-9796-41B1-ACAC-2043ECCD642C/2018-05-01_12-09-05

Tried to reset Docker, removed and installed again, restarted Windows - same error.

Steps to reproduce the behavior

1. Start docker for Windows from Start menu

[jasonbivins]

@maximdim
Try running a CMD prompt window as admin - then run this command, it looks like there's a permissions issue keeping the Docker service from starting.

net start docker

[asampal]

I'm seeing this problem as well. Prior version of Docker was working for me with Windows 10 (1803), but now even if I revert to previous builds I get the Access Denied error. I believe it's related to some Docker-created registry entries that were created with some kind of permission level so that an uninstall leaves things behind.

I've tried uninstalling Docker, and then tried removing Hyper-V, in order to start from scratch. The problem is that due to some of the mentioned registry entries that are left behind after uninstalling Docker, Hyper-V will not uninstall. The Hyper-V uninstall seems to go OK until the end when it says that it can't be done, so the uninstall is cancelled.

A point of note is that with Docker uninstalled, the Hyper-V Manager still shows a DockerNAT switch (again due to the registry entries).

The following Docker related registry entries are left behind after the uninstall:

Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\vmsmp\parameters\SwitchList\64B51D27-B0D5-4669-9C32-FE4528253ABE
Computer\HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\vmsmp\parameters\SwitchList\64B51D27-B0D5-4669-9C32-FE4528253ABE
Computer\HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Class\{4d36e972-e325-11ce-bfc1-08002be10318}\0018\NetSetupProperties
Computer\HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Network\{4D36E972-E325-11CE-BFC1-08002BE10318}\{EBCA70B9-11E3-44A5-BE10-23553EF4672F}\Connection
Computer\HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\vmsmp\parameters\KlifTmp1BC98A92\NicList\39F6954E-F61F-4A2A-9AFA-57685E4C1A7B
Computer\HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\vmsmp\parameters\KlifTmp1BC98A92\SwitchList\607A9FE5-4A38-4C86-8D77-CBA199C5E6CB
Computer\HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\vmsmp\parameters\KlifTmp1BC98A92\SwitchList\607A9FE5-4A38-4C86-8D77-CBA199C5E6CB\A1C9C958-C1DA-4D66-9002-C6B852EE4A75
Computer\HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\vmsmp\parameters\NicList\39F6954E-F61F-4A2A-9AFA-57685E4C1A7B
Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4d36e972-e325-11ce-bfc1-08002be10318}\0018\NetSetupProperties
Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Network\{4D36E972-E325-11CE-BFC1-08002BE10318}\{EBCA70B9-11E3-44A5-BE10-23553EF4672F}\Connection
Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\vmsmp\parameters\KlifTmp1BC98A92\NicList\39F6954E-F61F-4A2A-9AFA-57685E4C1A7B
Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\vmsmp\parameters\KlifTmp1BC98A92\SwitchList\607A9FE5-4A38-4C86-8D77-CBA199C5E6CB
Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\vmsmp\parameters\KlifTmp1BC98A92\SwitchList\607A9FE5-4A38-4C86-8D77-CBA199C5E6CB\A1C9C958-C1DA-4D66-9002-C6B852EE4A75
Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\vmsmp\parameters\NicList\39F6954E-F61F-4A2A-9AFA-57685E4C1A7B

Really, there needs to be a tool to totally clean up after Docker is removed. At this point I'm SOL with a broken Docker.

[rn]

There was some discussion and subsequent changes based on:#1732 (comment)

Could you check the permission of the named pipe with:

[System.IO.Directory]::GetAccessControl(“\\.\pipe\docker_engine”) | Format-Table -wrap

and check if your user is in the docker-users local group with:

net localgroup docker-users

[asampal]

@rn , I checked and I am part of docker-users. When I check permissions I get:

PS C:\WINDOWS\system32> [System.IO.Directory]::GetAccessControl("\\.\pipe\docker_engine")
Exception calling "GetAccessControl" with "1" argument(s): "\\.\pipe\docker_engine"
At line:1 char:1
+ [System.IO.Directory]::GetAccessControl("\\.\pipe\docker_engine")
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : DirectoryNotFoundException

I tried some of the suggestions in #1732, specifically after uninstalling Docker, I removed the docker-users group which was left behind. I then re-installed, but am still getting the problem reported by the OP.

[asampal]

The only Docker related pipes I see are:

\\.\\pipe\\dockerLogs
\\.\\pipe\\dockerBackend
\\.\\pipe\\docker_d4w_systray
\\.\\pipe\\dockerBackendToGui
\\.\\pipe\\dockerMobyLinuxVM-com1

I'm not sure when \\.\pipe\docker_engine is supposed to be created, but it's not there in my case.

[rn]

Ah, so from the logs there is:

[ 50.717][  0.000] [22:30:58.612][PowerShell     ][Info   ] Run script with parameters: -Start True -IsoFile C:\Program Files\Docker\Docker\Resources\docker-for-win.iso -confIsoFile C:\ProgramData\Docker\tmp-d4w\config.iso...
[ 50.722][  0.005] [22:30:58.617][NamedPipeServer][Error  ] Unable to execute Start: Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))    at Docker.Backend.ContainerEngine.Linux.DoStart(Settings settings, String daemonOptions) in
                                                   C:\gopath\src\github.com\docker\pinata\win\src\Docker.Backend\ContainerEngine\Linux.cs:line 247
   at Docker.Backend.ContainerEngine.Linux.Start(Settings settings, String daemonOptions) in C:\gopath\src\github.com\docker\pinata\win\src\Docker.Backend\ContainerEngine\Linux.cs:line 112
[ 50.729][  0.007] [22:30:58.624][HyperV         ][Info   ] Script started at 22:30:58.624
[ 50.732][  0.003] [22:30:58.627][NamedPipeClient][Error  ] Unable to send Start: Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))
[ 50.733][  0.001] [22:30:58.628][Notifications  ][Error  ] Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))
[ 50.746][  0.013] [22:30:58.641][HyperV         ][Info   ] Module loaded at 22:30:58.641

weirdly it still tries to boot the VM...

I'll file an internal issue

[asampal]

@rn from this post, it seems that the docker_engine pipe only exists when the service is running and in this case it's not, so you can't check it's permissions.

[rn]

@asampal yes and no. We start a proxy to intercept docker CLI calls to forward them to the Linux VM (or the windows containers. Something, when creating them seem to fail on your system

[asampal]

@rn do you have any suggestion as to where I can look to try and resolve this?

[ebriney]

@asampal
Looking at the code and diags the problem seems to be that it failed to access to iso containing config (don't know if it is to delete it or attach it because it is in aggregated exception and so the call stack is not in the logs)
Can you try to quit then delete C:\ProgramData\Docker\tmp-d4w and restart?

[ebriney]

Oh no, just re-check and it seems to fail when it tries to open ports for proxy in firewall:

var proxyExe = Paths.DockerProxyExe;
_logger.Info($"Opening ports for {proxyExe}...");
var rule = CreateApplicationRule(NET_FW_PROFILE_TYPE2_.NET_FW_PROFILE2_PRIVATE | NET_FW_PROFILE_TYPE2_.NET_FW_PROFILE2_PUBLIC | NET_FW_PROFILE_TYPE2_.NET_FW_PROFILE2_DOMAIN, DockerProxy, NET_FW_ACTION_.NET_FW_ACTION_ALLOW, proxyExe, NET_FW_IP_PROTOCOL_.NET_FW_IP_PROTOCOL_ANY);
fw.Rules.Add(rule);

this last call got Access Denied.

[ebriney]

I tried to change my firewall settings on my 16299 but cannot reproduce maybe it is related to your insider build, will try on another machine

[asampal]

@ebriney for me the problem showed on the final 1803, not an insider build. In any case, I ended up going back to the previous version of Windows (prior to the 1803 update) and finally got the latest stable Docker to work. I'll try to wait this problem out a bit before I let my system try the update again.

[docker-robott]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale comment.
Stale issues will be closed after an additional 30d of inactivity.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows.
/lifecycle stale

[Kender2]

Crossposting from #1887 to maybe help anyone running into this issue.

For me (diagnostics ID DC0F15FC-416F-4314-9DE4-476C1AF742F7/20190213184211) this error occurs because Windows Firewall Control (from binisoft.org) prevents other programs from modifying windows firewall rules and settings.

   at Docker.Core.Pipe.NamedPipeClient.Send(String action, Object[] parameters) in C:\workspaces\stable-18.09.x\src\github.com\docker\pinata\win\src\Docker.Core\pipe\NamedPipeClient.cs:line 36
   at Docker.Actions.DoStart(SynchronizationContext syncCtx, Boolean showWelcomeWindow, Boolean executeAfterStartCleanup) in C:\workspaces\stable-18.09.x\src\github.com\docker\pinata\win\src\Docker.Windows\Actions.cs:line 92
   at Docker.Actions.<>c__DisplayClass19_0.<Start>b__0() in C:\workspaces\stable-18.09.x\src\github.com\docker\pinata\win\src\Docker.Windows\Actions.cs:line 74
   at Docker.WPF.TaskQueue.<>c__DisplayClass19_0.<.ctor>b__1() in C:\workspaces\stable-18.09.x\src\github.com\docker\pinata\win\src\Docker.WPF\TaskQueue.cs:line 59

Why does docker need to modify the firewall every time it starts? Can't we get a rule or set of rules included once? It kinda sucks to have to disable and re-enable firewall protection every time I want to start docker.

[maximdim]

Very interesting. I was also running WFC when I got that error. Still using it (and Docker) but don't see this issue again.

[docker-robott]

Closed issues are locked after 30 days of inactivity.
This helps our team focus on active issues.

If you have found a problem that seems similar to this, please open a new issue.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows.
/lifecycle locked