Cannot access Host Docker Engine inside Container

Docker Desktop
1

Hi,

Short Version: How do I access the docker host from within a (windows server core) container on Windows?

Long Version: I’ve created an image based on microsoft/dotnet-framework-build:3.5 to install tools used during our CI/CD process.

During the build I install chocolatey and then, using choco, installer the docker CLI client. This is so I can push images, stored on the host, from within the container running (the build image), at least that was my hope.

The problem I have is that I cannot seem to bind the host \\.\pipe\docker_engine to the pipe in the container. So far I’ve tried the following command line options (these start an interactive prompt for testing but the proper build will be non-interactive)

docker run --interactive --tty -v \\.\pipe\docker_engine:\\.\pipe\docker_engine my-image

In this case the container starts but the binding doesn’t work because when I run docker ps I get the error:
error during connect: Get http://%2F%2F.%2Fpipe%2Fdocker_engine/v1.33/version: open //./pipe/docker_engine: message readmode pipes not supported In the default daemon configuration on Windows, the docker client must be run elevated to connect. This error may also indicate that the docker daemon is not running.

docker run --interactive --tty --mount type=bind,src=\\.\pipe\docker_engine,dst=\\.\pipe\docker_engine my-image

In this case the container won’t even start because I get the error:
Error response from daemon: invalid mount config for type "bind": source path must be a directory

How do I bind the \.\pipe\docker_engine so that the container can access the docker engine on the host?

The version info from my host install is:

Client:
 Version:       17.12.0-ce
 API version:   1.35
 Go version:    go1.9.2
 Git commit:    c97c6d6
 Built: Wed Dec 27 20:05:22 2017
 OS/Arch:       windows/amd64

Server:
 Engine:
  Version:      17.12.0-ce
  API version:  1.35 (minimum version 1.24)
  Go version:   go1.9.2
  Git commit:   c97c6d6
  Built:        Wed Dec 27 20:15:52 2017
  OS/Arch:      windows/amd64
  Experimental: true

The client, inside the container, version info is

Client:
 Version:      17.10.0-ce
 API version:  1.33
 Go version:   go1.8.3
 Git commit:   f4ffd25
 Built:        Tue Oct 17 19:00:02 2017
 OS/Arch:      windows/amd64
2

Have you tried running your shell (I’m guessing either cmd or PowerShell) as a user with Administrator access and running the same commands? (Right click on cmd or PowerShell and Run as... and select an admin or system user).

3

Didn’t make a difference, for me it seems to be a bug in the Docker for Windows version that I have because other threads suggest that this should be possible

4

Just to round this off…

The only way I could get this working was to add another host to daemon.json, the host is on the docker nat network. So tcp://nat_network_address:2375

I then set a firewall rule to allow the traffic and within the container set the DOCKER_HOST environment variable to the new endpoint.

After that I was able to connect to the host’s docker engine.

It’s not ideal but it works until a proper fix is available.

Kepboy

1 Like
5

kepboy,

I’m facing the same issue as you.
I’m trying to use the named pipe as mentioned in https://blog.docker.com/2017/09/docker-windows-server-1709/.
My Dockerfile is a windowsservercore with pipelist64.exe in it.
Runnng pipelist64.exe -accepteula inside the container, does not show the docker_engine named pipe.
I hope that this a bug and not a limitation of the Windows version that I’m running (Windows 10 V1709).
This feature will allow me to run watchtower to update my windows containers without intervention.
I’m running Docker version 18.03.0-ce-rc1, build c160c73

6

There is an open feature request for this. I believe it is already implemented, just needs to be released

7

Are you saying that you are able to mount the named pipe successfully if the user has the right permissions? I have been trying to get it to work for days now…
Thanks!

8

No I’m not aware of anyway to mount it in the container, I believe it is the docker daemon or the user within the container that does not have the required permission level. Either way the link I sent is a feature request to given access control to the named pipe via a local group in windows.

9

I created an issue at https://github.com/moby/moby/issues/36562https://github.com/moby/moby/issues/36562#issuecomment-372347544
According to the comments, it should just work.