Docker for Windows volume mounts and docker.sock

[johnrom]

Mounting /var/run/docker.sock is no longer working in stable Docker for Windows with the latest update. There is an issue here: docker/for-win#1829

I'm not sure whether the issue is that docker.sock file is no longer a reliable source for DFW, and if that is the case then the issue will have to be resolved here. However, if it's a bug and it should still be able to mount docker.sock on the Docker for Windows side of things, this bug should resolve itself in a future update.

An example error is here:

ERROR: for front  Cannot create container for service front: b'Mount denied:\nThe source path "\\\\var\\\\run\\\\docker.sock:/tmp/docker.sock"\nis not a valid Windows path'

Example docker-compose.yml:

front:
  restart: always
  image: jwilder/nginx-proxy
  volumes:
    - /var/run/docker.sock:/tmp/docker.sock
  ports:
    - "80:80"
    - "443:443"

Docker Version:
18.03.0-ce-win59

[a727891]

There was a workaround found in docker/for-win#1829

Add an this environment variable: COMPOSE_CONVERT_WINDOWS_PATHS = 1

Or from Powershell run $Env:COMPOSE_CONVERT_WINDOWS_PATHS=1

[BaileyMillerSSI]

I am still getting my mount error even after changing that value to 1.

[BaileyMillerSSI]

Error:

ERROR: for reverseproxy_nginx-proxy_1  Cannot create container for service nginx-proxy: b'Mount denied:\nThe source path "\\\\var\\\\run\\\\docker.sock:/tmp/docker.sock"\nis not a valid Windows path'

ERROR: for nginx-proxy  Cannot create container for service nginx-proxy: b'Mount denied:\nThe source path "\\\\var\\\\run\\\\docker.sock:/tmp/docker.sock"\nis not a
valid Windows path'
ERROR: Encountered errors while bringing up the project.

docker-compose.yml:

version: '2'

services:
  nginx-proxy:
    image: jwilder/nginx-proxy
    ports:
      - "80:80"
    volumes:
      - /var/run/docker.sock:/tmp/docker.sock

  whoami:
    image: jwilder/whoami
    environment:
      - VIRTUAL_HOST=www.whoamitest.com

[johnrom]

@BaileyMillerSSI , it's likely that the variable isn't being set during execution of the script. you can test this on Bash by doing something like:

COMPOSE_CONVERT_WINDOWS_PATHS=1 docker-compose up. Running the commands separately will not persist the value unless you use export COMPOSE_CONVERT_WINDOWS_PATHS=1.

My comment here is more thorough.

[padhie]

I lean out of the window and say that everyone forgot an important point:
/var/run/docker.sock does not exist on a windows system. You can't mount anything that does not exist.
Even under Windows 10 with the Ubuntu Bash this file does not exist.
The path would have to be adjusted but I'm not sure if windows ever created the docker.sock file or used.

[johnrom]

@padhie Linux Containers in Docker for Windows run within a vm under hyper-V. This VM is mapping its docker.sock to the nginx-proxy container.

This image runs in a Linux Container.

[padhie]

@johnrom but you try an windows directory map and this isn't exists

[johnrom]

@padhie I think the misunderstanding is that setting this variable just happens to fix the problem by changing the way paths are parsed. It's not mapping this path to Windows in any way. This directory doesn't exist in Windows, it exists in the Hyper-V VM (Linux). Hopefully, this will help you understand. When you open Docker for Windows "Settings" and go to "Shared Drives", it helps you demonstrate the shared drive is working by entering this command:

docker run --rm -v c:/Users:/data alpine ls /data

What it then does, is automatically changes C:/Users to /c/Users in the background to demonstrate that C:\Users is correctly mounted within the Linux VM, and passed on to the container you create. What it doesn't tell you, is there is a way to prevent that from happening, and by doing that you can prove that you're actually mounting the drive from Linux to the Container. Using two slashes allows you to circumvent this conversion.

docker run --rm -v //:/data alpine ls //data

Now you'll see a Linux root directory, with folders like var, opt, etc.

docker run --rm -v //var/run:/data alpine ls //data

Now you'll see that there is a docker.sock

[johnrom]

I can confirm the workaround posted by @a727891 works, so I'm going to close this. Any further resolution wouldn't appear to be related to this repo.