Docker For Windows 18.03 stable: access denied for mounting /var/run/sock

[Yivan]

Hello,

We just updated Docker for Windows to last 18.03 stable (stable channel and no experimental feature). All was working great on the previous version.

Starting a container making a bind mount with /var/run/docker.sock (like portainer, nginx-proxy, ...) bring the following error:

ERROR: for portainer 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' ERROR: Encountered errors while bringing up the project.

I don't know if portainer/nginx-proxy/etc. need to be updated or this is docker wich need to be fixed.
For reference issue has been opened on portainer too: portainer/portainer#1775
Stackoverflow here: https://stackoverflow.com/questions/49507912/docker-jwilder-nginx-proxy-container-create-issue

Steps to reproduce the issue:

A simple compose file like:

version: "3.5"

services:
    portainer:
        image: portainer/portainer:latest
        volumes:
            - "portainer:/data"
            - "/var/run/docker.sock:/var/run/docker.sock"

Technical details:
Target Docker version (the host/cluster you manage): Docker for Windows to last 18.03 stable (stable channel and no experimental feature)
Platform (windows/linux): Windows 10 Profesionnal up-to-date
Target Swarm version (if applicable): not a swarm node
Try with several cli, same problem.

Thanks

[sv1slim]

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

[oxrc]

the trick proposed by @sv1slim did the job for me - started my project via docker-compose up. Thanks a lot!

[Yivan]

@sv1slim Thanks for your answer. Actually i reverted to the previous version to be able to work ; )
I will try it has soon as i can and report here.

Do you know why it change with the last Docker Version For Windows ? (as all was working great just before the update)
It should be documented in the update note of docker for sure.

I should add that for my setup i run commands from bash script (via Git shell or Bash Cmder) so our starting scripts work on windows/linux/mac for all developpers. In those scripts i set export MSYS_NO_PATHCONV=1, maybe it has to do with COMPOSE_CONVERT_WINDOWS_PATHS ?

Exemple: file up.sh

#!/bin/bash
set -euo pipefail

source ./init-env.sh
export MSYS_NO_PATHCONV=1

echo "Create networks"
! (docker network list | grep global_proxy &>/dev/null) && docker network create global_proxy
! (docker network list | grep global_secured &>/dev/null) && docker network create global_secured
echo "Start tools..."
docker-compose -f ./"$COMPOSE_FILE" -p "$COMPOSE_PROJECT_NAME" build
docker-compose -f ./"$COMPOSE_FILE" -p "$COMPOSE_PROJECT_NAME" up -d

But before reporting this issue, for sure i tested directly docker-compose from a classic windows cmd shell and got the denied access error too, so it doesn't seems related to use bash shell on Windows or MSYS_NO_PATHCONV=1, but if someone got some information i will be happy to know.

Thanks.

[sv1slim]

@Yivan I don't think this is supposed to be in the Docker Documentation as this is your environment configuration, For Linux environment add export COMPOSE_CONVERT_WINDOWS_PATHS=1

[lidio601]

Take a look at those:

• docker-compose bind mount docker.sock not a valid Windows path #1829
• Docker for Windows volume mounts and docker.sock nginx-proxy/nginx-proxy#1110

[Yivan]

@sv1slim @lidio601 Thanks for you return, i just try with export COMPOSE_CONVERT_WINDOWS_PATHS=1 and it works great now.

It is documented in fact:
https://github.com/docker/compose/blob/master/CHANGELOG.md#190-2016-11-16

But as i was only looking in the docker for windows release notes (https://docs.docker.com/docker-for-windows/release-notes/) it isn't documented.

To the docker for win staff: i think when there is breaking changes coming from docker/compose/machine it should be mentionned in the stable release note of docker for win too.

Thanks.

[rorgonas]

Quick ref: https://docs.docker.com/compose/reference/envvars/#compose_convert_windows_paths

[rn]

This issue seems to be fixed. Closing. @sv1slim thanks for the help

[davclark]

How is this fixed? I am confused because an up-to-date stable-channel docker still has this problem. In some edge cases (e.g., PyCharm remote containers using docker compose), it is entirely unclear how to fix this.

[BaileyMillerSSI]

I am still getting mount errors after running this update on the environment variable.

[fabiante]

Using the ENV variable will not work in the Git Bash. You have to use the windows CMD or Powershell for the ENV to actually work.

[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