Docker Desktop v4.14/v4.15/v4.16 breaks Windows Containers?

The other day my copy of Docker Desktop on two different work laptops prompted me to update. And neither would work properly after the update completed. In case this issue is affecting others, here's the saga of what I saw and two ways it can be fixed:

See the end of this post for info the version of Docker Desktop which fixes this issue.

The issue

After applying the v4.14 update I tried to run a PowerShell script to start some Sitecore (but I don't believe that's relevant) containers and got a big error message:

For Google's benefit, that error message is:

Traceback (most recent call last):
  File "docker\api\client.py", line 268, in _raise_for_status
  File "requests\models.py", line 941, in raise_for_status requests.exceptions.HTTPError: 500 Server Error: Internal Server Error for url: http+docker://localnpipe.version

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "docker\api\client.py", line 214, in _retrieve_server_version
  File "docker\api\daemon.py", line 181, in version
  File "docker\api\client.py", line 274, in _result
  File "docker\api\client.py", line 270, in _raise_for_status
  File "docker\errors.py", line 31, in create_api_error_from_http_exception docker.errors.APIError: 500 Server Error for http+docker://localnpipe/version: Internal Server Error ("b‘open \\\\.\\pipe\\docker_engine_windows: The system cannot find the file specified. '")

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "docker-compose", line 3, in <module>
  File "compose\cli\main.py", line 81, in main
  File "compose\cli\main.py", line 200, in perform_command
  File "compose\cli\command.py", line 60, in project_from_options
  File "compose\cli\command.py", line 152, in get_project
  File "compose\cli\docker_client.py", line 41, in get_client
  File "compose\cli\docker_client.py", line 170, in docker_client
  File "docker\api\client.py", line 197, in __init__
  File "docker\api\client.py", line 221, in _retrieve_server_version docker.errors.DockerException: Error while fetching server API version: 500 Server Error for http+docker://localnpipe/version: Internal Server Error ("b'open \\\\.\\pipe\\docker_engine_windows: The system cannot find the file specified.")

[17672] Failed to execute script docker-compose


					

The key bit of that seemed to be: Error response from daemon: open \.\pipe\docker_engine_windows: The system cannot find the file specified - which is saying that the command-line tool has tried to open a Named Pipes connection to some part of the Docker engine and has failed with a "not found" error.

Scratching my head a bit, I tried a bit of PowerShell to see what named pipes with "docker_" in their name existed on my machine:

get-childitem \\.\pipe\ | where { $_.Name -match "docker_" }

					

And that was telling:

The docker_engine_windows pipe did not exist - so the error message seemed accurate.

And trying some other Docker commands like docker image ls would give me similar (if briefer) errors about that pipe not being found.

After seeing this issue, the v4.15 update appeared, and I tried applying that to these machines. But that didn't resolve my problems.

Solution One

I did a pile of googling at this point, and came across this bug ticket on GitHub. That's talking about a similar error, though it wanders off into some suggested solutions about missing Windows Features for Containers. That was definitely not my problem. However one person suggested reverting to the v4.13 release of Docker.

I tried that process - and it did resolve the issue for me.

However that comes with the annoying side-effect that you have to remove the "broken" docker version before installing its older "working" version. And that uninstall will clear out all your downloaded images. While not a deal-breaker, that can be a pain as the downloads can take a while.

Solution Two

Alongside the googling I tried asking about this on Sitecore Slack's Docker channel. And Jeff L'Heureux from Sitecore suggested that they'd had dealings with Docker Support over a related issue, and had been given a potential fix. And this one didn't involve any uninstalling. The steps he relayed are:

• Fire up a console as Administrator
• Run cd 'C:\Program Files\Docker\Docker\resources\'
• Run .\dockerd.exe -G docker-users --config-file c:\programdata\docker\config\daemon.json --register-service
• Run start-service docker

Now this did not work for me - trying to register the docker service raised an error that the service already existed. However I was able to work out a slight alternative to this which did seem to work for me:

• Fire up a console as Administrator
• Run stop-service docker
• Run cd 'C:\Program Files\Docker\Docker\resources\'
• Run .\dockerd.exe --unregister-service
• Reboot the computer
• Run .\dockerd.exe -G docker-users --config-file c:\programdata\docker\config\daemon.json --register-service
• Reboot the computer
• Restart Docker Desktop
• Put Docker Desktop back into Windows Containers mode

Having done this, I was able to start my containers again, and I could see that the "missing" named pipe had now appeared.

Docker do suggest you might need to change the Docker Engine config in c:\programdata\docker\config\daemon.json to

{
  "experimental": false,
  "hosts": [
    "npipe:////./pipe/docker_engine_windows"
  ]
}

					

But I didn't find this necessary for my machines - which perhaps makes sense because the software was clearly looking for that pipe originally, so it shouldn't need to be told to?

In conclusion

I've done this Docker Desktop update on three laptops now. Two "work" ones both suffered this issue, but my personal machine did not. All three are running Windows 10 with all the latest patches applied.

My suspicion is that there's a permissions problem hiding under this somewhere, as the machines which suffered the problem are both domain-joined and subject to some corporate IT policies. (One strict, one less so) My personal laptop isn't on a domain, and doesn't have any other security config applied, and didn't show the issue. But that is just a guess. I'll keep an eye on that GitHub issue thread, and see if that gives any clues in the future...

But for the moment, hopefully this helps anyone else seeing the issue to resolve it.

And I'm very grateful to Jeff for his help here.

Update: This issue should be resolved with Docker Desktop v4.17.0 (99724) and above. If you're using an older release and see the issue, you should update to resolve it.

But for historical interest, and in case there are any people who cannot upgrade for technical reasons, the workaround to resolve this issue that was recommended by the Docker team is:

Create this folder hierarchy in your registry: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Policies\Microsoft\FVE and then create a DWORD registry key 'FDVDenyWriteAccess' with value set to 0 in that folder.

↑ Back to top