# docker compose volume mounts not work on Windows #4303

Closed
opened this issue Jan 7, 2017 · 34 comments
Closed

# docker compose volume mounts not work on Windows#4303

opened this issue Jan 7, 2017 · 34 comments
Labels

### abhisheks2010 commented Jan 28, 2017

 Is there a better way to do COMPOSE_CONVERT_WINDOWS_PATHS or any other workaround.

### igordata commented Feb 2, 2017

 Just type "export COMPOSE_CONVERT_WINDOWS_PATHS=1" and it will work until reboot.
mentioned this issue Feb 13, 2017

### BlakeWills commented Jun 2, 2017

 Any reason this was closed? I've created a system environment variable and tried the .env file but still no avail.

### shin- commented Jun 2, 2017

 It's not closed, but that particular issue should be resolved. Make sure your Compose version is up to date and your docker-compose.yml is correct.

### DavidAdamczyk commented Jun 10, 2017

 I have the same issue on Windows 10. I use docker-compose version 1.11.2, build f963d76 and Docker version 17.03.1-ce, build c6d412e and this repo https://github.com/b00giZm/docker-compose-nodejs-examples/tree/master/00-basic-express-generator with correct Dockerfile and docker-compose.yml when i run docker-inspect i get this info: https://www.pastiebin.com/593bc096af354 but when i go inside to container and run ls /src i get this: root@930bfd8a7df0:/src# ls node_modules package.json  i can't find app directory inside container. But when i run: PS D:\00-basic-express-generator> docker run --rm -v c:/Users:/data alpine ls /data Administrator All Users Default Default User  volumes is working great Is there any solution how to fix this bug in docker-compose?

### HWiese1980 commented Jul 15, 2017

 One and a half months... is there a solution yet?

### rolandwolters commented Jul 17, 2017

 Running Docker 17.06.0-ce-win19 (12801) on Windows 10 using Visual Studio 2017 I ran into this thing. I saw the "create e .env file" tip but on Window you cannot have a file with no name?

### HWiese1980 commented Jul 17, 2017

 Yes, you can. At least on Windows 10.

### riker09 commented Jul 25, 2017

 @rolandwolters You cannot have a file without a filename in Explorer. But you can open a Powershell, navigate to your project directory and type: mv e.env .env

### shin- commented Jul 25, 2017

closed this Jul 25, 2017

### cre8 commented Aug 15, 2017

 It worked for me with COMPOSE_CONVERT_WINDOWS_PATHS=1, but I had to shut down all containers docker-compose stop, not just the one who uses it.

### peteanusergiu commented Sep 10, 2017

 I've used , in a CMD window, SET COMPOSE_CONVERT_WINDOWS_PATHS=1 and it suddenly starting working. Remember to open a new CMD window.

### jaspervandaele commented Nov 14, 2017

 I just discovered the "Reset Credentials..." button in the Shared Drive settings, which solved the issue for me. In my case the volume suddenly stopped working after disabling+enabling Hyper-V. Resetting the credentials for the shared drives fixed it again

### cvillerm commented Nov 15, 2017

 @jaspervandaele, thanks a lot, this fixed my issue too. The error message Are you trying to mount a directory onto a file (or vice-versa)? Check if the specified host path exists and is the expected type I was facing was so generic that I was wondering what was wrong. As I changed my Windows credentials recently, this is what caused this error. I wished there was something more explicit in case the mounted volume cannot be accessed at all

### brianrichins commented Dec 7, 2017 • edited

 @rolandwolters You can bypass the Windows Explorer naming restriction by adding an extra . at the end. So renaming a file and typing ".env." results in .env, ".gitignore." becomes .gitignore, etc.

### aysark commented Mar 14, 2018

 @jaspervandaele thanks for that- solved it for me.

### gersondinis commented Apr 8, 2018

 On Command Line: "set COMPOSE_CONVERT_WINDOWS_PATHS=1"; Restart Docker for Windows; Go to Docker for Windows settings > Shared Drives > Reset credentials > select drive > Apply; Reopen Command Line; Kill the Containers; Rerun the Containers.
mentioned this issue Apr 11, 2018

### wsmelton commented Apr 24, 2018

 @gersondinis there is no option in settings for Shared Drives when Docker CE is running in Windows mode...unless I'm missing something using edge release:

### gersondinis commented Apr 24, 2018 • edited

 Try to change from edge version to stable version on Daemon tab. You should see something like this: https://cdn-enterprise.discourse.org/docker/uploads/default/optimized/2X/d/df575b41215fb89a1f79f6bf8f0864b7366e9955_1_690x312.png If it doesn't, try to upgrade/update your Docker for Windows.

### tnovau commented Apr 30, 2018

 @gersondinis Thanks!, that solved my problem!

### wsmelton commented May 10, 2018

 @gersondinis latest version of CE and stable version...this is all I get:

### roeehershko commented May 23, 2018

 @gersondinis Sir your a life saver! for me it wasnt the environment variable, it was due to changing windows password, thanks you sir!
mentioned this issue May 31, 2018
mentioned this issue Jun 12, 2018
mentioned this issue Jun 15, 2018
mentioned this issue Jul 5, 2018

### ELI7VH commented Aug 10, 2018

 This did not solve the problem for me. I still run into issues trying to mount files to my docker-compose

### Lobosque commented Aug 13, 2018

 I'm also having problems mounting volumes on Windows containers (it works fine in Linux containers). I tried everything in this thread. I also tried relative and absolute paths. Whenever I try to mount volumes on Windows Containers I get: ERROR: Cannot create container for service builder: invalid volume specification: 'D:\project\docker-env\dist:/dist:rw' 

### shin- commented Aug 13, 2018

 I don't think /dist is a valid Windows path.

### stavrogin commented Sep 12, 2018

 On Command Line: "set COMPOSE_CONVERT_WINDOWS_PATHS=1"; Restart Docker for Windows; Go to Docker for Windows settings > Shared Drives > Reset credentials > select drive > Apply; Reopen Command Line; Kill the Containers; Rerun the Containers. On Command Line: "set COMPOSE_CONVERT_WINDOWS_PATHS=1"; Restart Docker for Windows; Go to Docker for Windows settings > Shared Drives > Reset credentials > select drive > Apply; Reopen Command Line; Kill the Containers; Rerun the Containers. You're the man, it solved the problem, thank you

### philippelamny commented Sep 18, 2018

 This settings in the docker-compose file work well:  volumes: - type: bind source: ./source_local_directory target: c:\target_directory bind: propagation: cached 

### tylim88 commented Oct 25, 2018

 @gersondinis there is no option in settings for Shared Drives when Docker CE is running in Windows mode...unless I'm missing something using edge release: you are not seeing it because you are using window container, you need to switch to linux container
mentioned this issue Nov 12, 2018
mentioned this issue Nov 21, 2018

### dbjpanda commented Nov 27, 2018

 Will $PWD also work with COMPOSE_CONVERT_WINDOWS_PATHS=1 ? e.g drupal: driver: local driver_opts: type: none device:$PWD/code/drupal o: bind 

### aalkz commented Dec 13, 2018

 I was having this issue (at least I think it's the same issue), but since I wanted to keep Hyper-V off in order to use accelerated emulation for Intel + Android, I couldn't use the Docker for Windows GUI app and look for those Shared Drives settings that @shin- mentioned, because I was using docker-machine.exe + VirtualBox. So what I had to do in this particular case instead was this: https://forums.docker.com/t/how-to-share-volumes-and-or-drives-using-docker-machine-on-windows-not-beta/20170/2 & "C:\Program Files\Oracle\VirtualBox\VBoxManage.exe" sharedfolder add default --name "shared" --hostpath "C:/your/shared/folder/" --automount And then in docker-compose.yml: volumes: - /shared:/some/dir/in/the/container  I think this is more like a workaround and not a full solution, but I hope somebody finds it helpful. TL;DR: If you're using VirtualBox and not Docker for Windows, try mounting the drives in VirtualBox with VBoxManage.exe
mentioned this issue Jan 23, 2019

### BenMatheja commented Feb 3, 2019 • edited

 I'm using windows subsystem for linux, running the docker-host on the windows machine exposed via non-TLS port 2375. I tried what @stavrogin mentioned, but it did not work. My docker-compose.yml mounts a file into the container like this: version: '2' services: nginx: image: nginx:latest volumes: - ./nginx.conf:/etc/nginx/nginx.conf ports: - 80:80 - 443:443  After running docker-compose up i get " Are you trying to mount a directory onto a file (or vice-versa)" Starting ea_nginx_1 ... Starting ea_grafana_1 ... Starting ea_influxdb_1 ... Starting ea_collectd_1 ... error ERROR: for ea_collectd_1 Cannot start service collectd: b'OCI runtime create failed: container_linux.go:344: starting container process caused "process_linux.go:424: containeStarting ea_nginx_1 ... error947aaf139ee40bd985d078112919c30/merged\\\\\\" at \\\\\\"/var/lib/docker/overlay2/7a737fdd9749373317586ea8c17258c8b947aaf139ee40bd985d078112919c30/merged/etc/collectd/collectd.conf\\\\\\" caused \\\\\\"not a directory\\\\\\"\\"": unknown: Are you trying to mount a directory onto a file (or vice-versa)? Check if the specified host path exists and is the expected type' ERROR: for ea_nginx_1 Cannot start service nginx: b'OCI runtime create failed: container_linux.go:344: starting container process caused "process_linux.go:424: container init caused \\"rootfs_linux.go:58: mounting \\\\\\"/mnt/d/Daten/workspace/ea/nginx.conf\\\\\\" to rootfs \\\\\\"/var/lib/docker/overlay2/db2c014e375524c7b6bf97cc874915d023c25b8e8f  I tried placing an .env file within the directory  ben@ben-desktop  /d/Daten/workspace/ea   master ●  ls -al total 60 drwxrwxrwx 1 ben ben 4096 Feb 3 09:47 . drwxrwxrwx 1 ben ben 4096 Feb 3 08:44 .. -rwxrwxrwx 1 ben ben 34197 Feb 3 08:37 collectd.conf -rwxrwxrwx 1 ben ben 765 Feb 3 09:32 docker-compose.yml -rwxrwxrwx 1 ben ben 31 Feb 3 09:52 .env drwxrwxrwx 1 ben ben 4096 Feb 3 10:03 .git -rwxrwxrwx 1 ben ben 2641 Feb 3 08:37 influxdb.conf -rwxrwxrwx 1 ben ben 1086 Feb 3 08:37 LICENSE -rwxrwxrwx 1 ben ben 169 Feb 3 09:26 nginx.conf -rwxrwxrwx 1 ben ben 629 Feb 3 08:37 README.md -rwxrwxrwx 1 ben ben 8577 Feb 3 08:37 types.db ben@ben-desktop  /d/Daten/workspace/ea   master ●   But still cannot start the containers from my Windows machine. Running the exact same configuration on a linode works as is. What am I missing out here? Edit: Moving the repository within the subsystem /home/ben/ea did also not resolve it Edit: I fixed it with changing the Volumes from  nginx: image: nginx:latest volumes: - ./nginx.conf:/etc/nginx/nginx.conf ports: - 80:80 - 443:443  to  nginx: image: nginx:latest volumes: - \${PWD}/nginx.conf:/etc/nginx/nginx.conf ports: - 80:80 - 443:443 
mentioned this issue Feb 4, 2019

### gischy commented Feb 18, 2019

 using docker toolbox on windows this way i could solve my the issue https://medium.com/@Charles_Stover/fixing-volumes-in-docker-toolbox-4ad5ace0e572 docker-compose.yml: version: '3' services: web: build: . ports: - "5000:5000" volumes: - //c/var/docker-compose-test:/code redis: image: "redis:alpine"
added a commit to Iristyle/pupperware that referenced this issue Mar 29, 2019
 (maint) Allow configurable volumes root 
 d1d4c20 
 - With long-running hosts, rooting the volumes inside of the git
cloned source directory is problematic.

When tests are cancelled and containers remain running, files can
be locked, preventing subsequent runs from proceeding correctly.

Instead, generate a temporary directory in Azure to root the files
so that source can be cloned properly.

- This removes the need for cleaning up existing hardcoded dirs in
Azure from prior test runs

- For now this will continue to default to . in Travis, given hosts
are ephemeral

- The Azure specific PowerShell code converts a Windows path like:

c:\foo\bar\tmp.foo

To something compose understands like:

//c/foo/bar/tmp.foo

See docker/compose#4303 (comment)
added a commit to Iristyle/pupperware that referenced this issue Mar 29, 2019
 (maint) Allow configurable volumes root 
 130de1a 
 - With long-running hosts, rooting the volumes inside of the git
cloned source directory is problematic.

When tests are cancelled and containers remain running, files can
be locked, preventing subsequent runs from proceeding correctly.

Instead, generate a temporary directory in Azure to root the files
so that source can be cloned properly.

- This removes the need for cleaning up existing hardcoded dirs in
Azure from prior test runs

- For now this will continue to default to . in Travis, given hosts
are ephemeral

- The Azure specific PowerShell code converts a Windows path like:

c:\foo\bar\tmp.foo

To something compose understands like:

//c/foo/bar/tmp.foo

See docker/compose#4303 (comment)
added a commit to Iristyle/pupperware that referenced this issue Mar 29, 2019
 (maint) Allow configurable volumes root 
 ed8ac35 
 - With long-running hosts, rooting the volumes inside of the git
cloned source directory is problematic.

When tests are cancelled and containers remain running, files can
be locked, preventing subsequent runs from proceeding correctly.

Instead, generate a temporary directory in Azure to root the files
so that source can be cloned properly.

- This removes the need for cleaning up existing hardcoded dirs in
Azure from prior test runs

- For now this will continue to default to . in Travis, given hosts
are ephemeral

- The Azure specific PowerShell code converts a Windows path like:

c:\foo\bar\tmp.foo

To something compose understands like:

//c/foo/bar/tmp.foo

See docker/compose#4303 (comment)
added a commit to Iristyle/pupperware that referenced this issue Mar 29, 2019
 (maint) Allow configurable volumes root 
 6273b9b 
 - With long-running hosts, rooting the volumes inside of the git
cloned source directory is problematic.

When tests are cancelled and containers remain running, files can
be locked, preventing subsequent runs from proceeding correctly.

Instead, generate a temporary directory (on Windows) to root the
files so that source can be cloned properly.

- This removes the need for cleaning up existing hardcoded dirs from
prior test runs, but we still make a best effort in the Azure job
to do cleanup

- For now this will continue to default to . in Travis, given hosts
are ephemeral.

On Windows hosts, this will be in the temp dir for the given user.

docker-compose understands Windows paths on the left hand side of
the volume mapping, so no conversions are necessary.

This was not always the case per:
docker/compose#4303 (comment)

- Stuff the temp dir in an Azure variable so it can be used in a later
cleanup stage

- Set the temp dir to give Users group full control to prevent the
containers from running into permissions issues

- Additional code will be added to perform cleanup from tests
added a commit to Iristyle/pupperware that referenced this issue Mar 29, 2019
 (maint) Allow configurable volumes root 
 ad3baaa 
 - With long-running hosts, rooting the volumes inside of the git
cloned source directory is problematic.

When tests are cancelled and containers remain running, files can
be locked, preventing subsequent runs from proceeding correctly.

Instead, generate a temporary directory (on Windows) to root the
files so that source can be cloned properly.

- This removes the need for cleaning up existing hardcoded dirs from
prior test runs, but we still make a best effort in the Azure job
to do cleanup

- For now this will continue to default to . in Travis, given hosts
are ephemeral.

On Windows hosts, this will be in the temp dir for the given user.

docker-compose understands Windows paths on the left hand side of
the volume mapping, so no conversions are necessary.

This was not always the case per:
docker/compose#4303 (comment)

- Stuff the temp dir in an Azure variable so it can be used in a later
cleanup stage

- Set the temp dir to give Users group full control to prevent the
containers from running into permissions issues

- Additional code will be added to perform cleanup from tests
added a commit to Iristyle/pupperware that referenced this issue Apr 1, 2019
 (maint) Allow configurable volumes root 
 ced39d7 
 - With long-running hosts, rooting the volumes inside of the git
cloned source directory is problematic.

When tests are cancelled and containers remain running, files can
be locked, preventing subsequent runs from proceeding correctly.

Instead, generate a temporary directory (on Windows) to root the
files so that source can be cloned properly.

- This removes the need for cleaning up existing hardcoded dirs from
prior test runs, but we still make a best effort in the Azure job
to do cleanup

- For now this will continue to default to . in Travis, given hosts
are ephemeral.

On Windows hosts, this will be in the temp dir for the given user.

docker-compose understands Windows paths on the left hand side of
the volume mapping, so no conversions are necessary.

This was not always the case per:
docker/compose#4303 (comment)

- Stuff the temp dir in an Azure variable so it can be used in a later
cleanup stage

- Set the temp dir to give Users group full control to prevent the
containers from running into permissions issues

- Additional code will be added to perform cleanup from tests
mentioned this issue Jun 12, 2019
mentioned this issue Oct 9, 2019
mentioned this issue Nov 10, 2019
mentioned this issue Dec 22, 2019
Projects
None yet

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.