docker-compose bind mount docker.sock not a valid Windows path

[ameier38]

Expected behavior

Should be able to bind mount the docker socket as explained
in http://jpetazzo.github.io/2015/09/03/do-not-use-docker-in-docker-for-ci/ using docker-compose

Actual behavior

I can successfully run the command

docker run -v /var/run/docker.sock:/var/run/docker.sock -it docker

But when I try to use within a docker-compose.yml file I get the following error

Creating docker_docker_1 ... error

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

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

Information

Docker Community Edition

Version 18.03.0-ce-rc3-win56 (16433)
Channel: edge
b6990be

Note: Just updated Docker and I did not receive this error in previous version.

docker-compose.yml

version: '3'
services:
    docker:
        image: docker
        stdin_open: true
        tty: true
        volumes:
            - /var/run/docker.sock:/var/run/docker.sock

Running docker-compose up gives the following error

λ  docker-compose up
Creating docker_docker_1 ... error

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

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

Steps to reproduce the behavior

1. Run docker-compose up using above docker-compose.yml

[ameier38]

Reverting to

Version 17.12.0-ce-win47 (15139)
Channel: stable
9c692cd

works without an error.

[ChristianSauer]

THis is critical for us, too!

[ChristianSauer]

@ameier38 Where can I find this older verison of docker?

[ameier38]

@ChristianSauer Go to install page and then download the stable channel.

[markrendle]

It would be really helpful for us Edge users if you could keep the previous Edge versions available for download so when something fundamental like this breaks we can just roll back one Edge release, instead of having to revert all the way back to Stable.

[creativearmenia]

You can download previous versions from this page https://docs.docker.com/docker-for-windows/release-notes/

[markrendle]

@creativearmenia So you can, I missed that. Thank you!

[wailua]

It's still an issue in 18.03.0-ce-rc4

[stalb]

The windows version of docker doesn't use unix socket (/var/run/docker.sock) but npipe (npipe:////./pipe/docker_engine).
So you have either

• to switch to linux container which runs docker in a full virtualized linux with unix socket
• to pass the npipe instead of the unix socket to the container (windows container only)
• to use a network socket (should work with linux and windows container)

The doc is here : https://docs.docker.com/docker-for-windows/faqs/#how-do-i-connect-to-the-remote-docker-engine-api

[markrendle]

@stalb This is not about connecting to the API, it's about mounting the /var/run/docker.sock unix socket (from the Hyper-V host Linux VM) into a running container.

[johnrom]

Looks like this issue is in stable now, and just wiped out an environment that uses an nginx proxy, listening to docker.sock to auto-proxy sites.

https://github.com/jwilder/nginx-proxy

Docker Version:
18.03.0-ce-win59

[jagraj]

We are getting into same issues on stable driver, when can we get fix for this.? Do we need to switch back to previous stable release.? Is there a workaround for this until we get fix in next stable driver.?

[johnrom]

@jagraj I reverted to the last version, 17.12.0-ce-win47, for now. I wasn't able to identify any workarounds or locate a docker.sock that was accessible from the host file system.

[jagraj]

I am wondering how this blocking issue ended up in stable release where customers already reported in edge drivers.

[rfay]

Docker-for-Windows team: Please let us know that you've registered this critical regression! It's on track to break our product for Windows users.

[pirog]

We've also had this reported for some of our Windows lando users.

[a727891]

Docker For Windows updated to 18.03.0-ce-win59 (16762) on the stable channel today and I ran into this issue as well. Docker-compose is unable to bind to /var/run/docker.sock

[jimgolfgti]

I've managed to work around this issue by setting environment variable COMPOSE_CONVERT_WINDOWS_PATHS to something truthy (1, 'true', 'on') as per docker/compose#4240. Release notes at the time suggest Docker for Windows did not need to set this but clearly this has now been broken, see https://github.com/docker/compose/blob/master/CHANGELOG.md#190-2016-11-16.

Issue seems to have been introduced by this commit docker/compose@2fbec60, most likely docker/compose@2fbec60#diff-e2ff86ffa7e639ddeff3723cabf428eeR150.
Original PR - docker/compose#5560

So this doesn't seem to be a Docker for Windows issue directly and probably should be fixed in compose?

[rfay]

@jimgolfgti 's marvelous workaround in #1829 (comment) is the ticket for us. Thanks so much for sharing that.

[shpros]

The workaround from @jimgolfgti didn't work for me in Git for Windows 2.16.2.1 bash shell. Same error with and without the environment variable. Uninstalled d4w 18.x and installed 17.12.0-ce-win47 (15139), and now everything works as before.

[Xerios]

Came here to say the same, update broke things with docker-compose and the ability to bind "/var/run/docker.sock".

[sv1slim]

run $Env:COMPOSE_CONVERT_WINDOWS_PATHS=1 in PowerShell and see if it does the deference

[unickq]

@sv1slim
Worked like a charm

[johnrom]

I can confirm that it is working on my Git Bash. @shpros the quickest way to test it works is by doing something like:

export COMPOSE_CONVERT_WINDOWS_PATHS=1
docker-compose down && docker-compose up -d

If you do not export, the environment variable may not make it all the way through the processes spawned -- especially if you are using other services that run docker-compose. Once confirmed working through this route, you can add it to your environment through more permanent means, through editing .bashrc in your home directory or otherwise. You can check that the environment variable is successfully set via echo $COMPOSE_CONVERT_WINDOWS_PATHS.

[subrato30]

@thiagosoeiro try it in git bash instead. Windows Powershell option didnt work for me either

[tssa88]

@subrato30 none of the options is working for me. :(
dunno what to do

[shpros]

@thiagosoeiro as mentioned in my previous comment, try uninstalling d4w 18.x and backing off to the latest 17.x version. You'll have to tell it not to update itself, or you'll be back where you started.

[revitteth]

Is there any update on this? Having serious issues with many workloads on Windows.

Docker 18.06.1-ce-win73 (19507) running on Windows 10 giving error:

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

[zeroactive]

Trying to get Traefik to work, I was able to set "COMPOSE_CONVERT_WINDOWS_PATHS=1" in a ".env" file (same directory location as docker-compose.yml) and "/var/run/docker.sock:/var/run/docker.sock" as a volume in the docker-compose.yml file.

Loading the volume was failing until I added the .env file with the property as mentioned above.

Win10

Docker for Windows:
Version 18.06.0-ce-win72 (19098)
Channel: stable
5513f91

Docker Compose:
docker-compose version 1.22.0, build f46880fe

[ZaxLofful]

So is this bug just marked as, "we don't care".....I'm on Stable Docker [18.06.1-ce-win73 (19507)] and still having this issue, why do I have to set this variable on Windows? If its just a stupid workaround only for windows, why is it not default?

I have been trying to get Traefik to work for days now and finally discovered this stupid ENV variable.... Please change and add automated regression testing to ensure it does not come back.

[shin-]

The fix is already available on the edge channel, and will be on the stable channel once the next version of Docker (18.09.0) reaches GA. If you want to stay on the stable channel but still want the fix, you can also download the latest Compose RC.

[jaheau]

Using this metioned solutions in last docker version in windows 10:
$Env:COMPOSE_CONVERT_WINDOWS_PATHS=1
docker-compose down && docker-compose up -d
the deployment works fine.

[mataralhawiti]

Hey folks,

Compose maintainer here - can someone try the following versions [1] of Compose: 1.18.0, 1.19.0, 1.20.1 against Docker For Windows 18.03.0-ce and report if they all exhibit the problem? That'd help a lot with pinpointing the issue.

Thanks!

[1] you can download the .exe files from https://github.com/docker/compose/releases

@shin-

Hey Shin,

I've tried it and I'm still getting the same error.
Docker version 18.06.1-ce, build e68fc7a
docker-compose version 1.23.1, build b02f1306

** Windows 10 Pro

[mithuns]

I tried using --privileged flag as well as the pipe for socket. But does not seem to be working for me , my test dsl is just

pipeline {
    agent {
        docker { image 'node:7-alpine' }
    }
    stages {
        stage('Test') {
            steps {
                sh 'node --version'
            }
        }
    }
}

But I get this

Started by user admin
Running in Durability level: MAX_SURVIVABILITY
[Pipeline] node
Running on Jenkins in /var/jenkins_home/workspace/test-pipeline
[Pipeline] {
[Pipeline] sh
+ docker inspect -f . node:7-alpine
/var/jenkins_home/workspace/test-pipeline@tmp/durable-8d0344e5/script.sh: 2: /var/jenkins_home/workspace/test-pipeline@tmp/durable-8d0344e5/script.sh: docker: not found
[Pipeline] sh
+ docker pull node:7-alpine
/var/jenkins_home/workspace/test-pipeline@tmp/durable-dbf75ea1/script.sh: 2: /var/jenkins_home/workspace/test-pipeline@tmp/durable-dbf75ea1/script.sh: docker: not found
[Pipeline] }
[Pipeline] // node
[Pipeline] End of Pipeline
ERROR: script returned exit code 127
Finished: FAILURE

This is how I am running jenkins
docker run --privileged -it -e -d -p 8080:8080 -v //./pipe/docker_engine://./pipe/docker_engine -v C:\Users\mithuns\jenkins_config:/var/jenkins jenkins/jenkins:lts

PS C:\WINDOWS\system32> docker version
Client:
 Version:           18.06.1-ce
 API version:       1.38
 Go version:        go1.10.3
 Git commit:        e68fc7a
 Built:             Tue Aug 21 17:21:34 2018
 OS/Arch:           windows/amd64
 Experimental:      false

Server:
 Engine:
  Version:          18.06.1-ce
  API version:      1.38 (minimum version 1.12)
  Go version:       go1.10.3
  Git commit:       e68fc7a
  Built:            Tue Aug 21 17:29:02 2018
  OS/Arch:          linux/amd64
  Experimental:     true

And docker-compose

PS C:\WINDOWS\system32> docker-compose version
docker-compose version 1.22.0, build f46880fe
docker-py version: 3.4.1
CPython version: 3.6.6
OpenSSL version: OpenSSL 1.0.2o  27 Mar 2018

[LiborVilimekMassive]

Hi,
I am on windows machine and running the Git Bash that executes linux script which spawns docker (and in there there is another docker).

In order to make this work I need to setup export COMPOSE_CONVERT_WINDOWS_PATHS=1
and then the path must look like this: (the two brackets in beginning cost me a lot of hours)
-v //var/run/docker.sock:/var/run/docker.sock

To work on both - windows-git-bash and linux I used this workaround

docker_socket=/var/run/docker.sock:/var/run/docker.sock
cat /etc/os-release || docker_socket=//var/run/docker.sock:/var/run/docker.sock
cat /etc/os-release || export COMPOSE_CONVERT_WINDOWS_PATHS=1
docker run -v $docker_socket myservice

[eine]

@LiborVilimekMassive, //var/run/docker.sock://var/run/docker.sock will work on most GNU/Linux OSs too. Hence, you don't need to define it twice (with and without the leading slashes).

[Xav-Pe]

Still having the error here, on Windows Server 2019 (10.0.17763 N/A Build 17763)

PS C:\Users\Administrator\docker\traefil> docker-compose version
docker-compose version 1.24.1, build 4667896b
docker-py version: 3.7.3
CPython version: 3.6.8
OpenSSL version: OpenSSL 1.0.2q  20 Nov 2018

PS C:\Users\Administrator\docker\traefil> docker version
Client: Docker Engine - Enterprise
 Version:           19.03.1
 API version:       1.40
 Go version:        go1.12.5
 Git commit:        f660560464
 Built:             07/25/2019 20:59:52
 OS/Arch:           windows/amd64
 Experimental:      false

Server: Docker Engine - Enterprise
 Engine:
  Version:          19.03.1
  API version:      1.40 (minimum version 1.24)
  Go version:       go1.12.5
  Git commit:       f660560464
  Built:            07/25/2019 20:57:41
  OS/Arch:          windows/amd64
  Experimental:     true

None of the COMPOSE_CONVERT_WINDOWS_PATHS (with cmd, powershell, in an .env) tricks works.

Still getting

PS C:\Users\Administrator\docker\traefil> docker-compose up -d reverse-proxy
Creating traefil_reverse-proxy_1 ... error

ERROR: for traefil_reverse-proxy_1  Cannot create container for service reverse-proxy: invalid volume specification: '/var/run/docker.sock:/var/run/docker.sock:rw'

With this docker-compose.yml:

version: '3.4'

services:
  reverse-proxy:
    image: traefik # The official Traefik docker image
    command: --api --docker # Enables the web UI and tells Traefik to listen to docker
    ports:
      - "80:80"     # The HTTP port
      - "8080:8080" # The Web UI (enabled by --api)
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:rw

And this .env :

COMPOSE_CONVERT_WINDOWS_PATHS=1

[naamancampbell]

Replacing --privileged with --user root works with /var/run/docker.sock:

docker run --user root -it -e -d -p 8080:8080 -v /var/run/docker.sock:/var/run/docker.sock -v C:\Users\mithuns\jenkins_config:/var/jenkins jenkins/jenkins:lts

[Sumayya55]

$Env:COMPOSE_CONVERT_WINDOWS_PATHS=1 not working for me.
Windows 10 and Docker 18.06.0-ce-win72 (19098)

Did you solve it?

[sudosandwich3]

@tehffs Were you able to find a workaround? I am trying to do the same thing on Windows Server 2019 with Traefik

[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