Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docker compose volume mounts not work on Windows #4303

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

docker compose volume mounts not work on Windows #4303

jleetutorial opened this issue Jan 7, 2017 · 34 comments

Comments

@jleetutorial
Copy link

@jleetutorial jleetutorial commented Jan 7, 2017

When running docker-compose up, we get this error:

ERROR: for dockerapp  Cannot create container for service dockerapp: Invalid bind mount spec "C:\\Users\\nidal\\dockerapp\\app:/app:rw": Invalid volume specification: 'C:\Users\nidal\dockerapp\app:/app:rw'
�[31mERROR�[0m: Encountered errors while bringing up the project.

The docker-compose file is attached below

version: '2'
services:
  dockerapp:
    build: .
    ports:
      - "5000:5000"
    volumes:
      - ./app:/app

  redis:
    image: redis:3.2.0

We get the error both on Docker for Windows and Docker toolbox running on Windows.

$ docker version
Client:
 Version:      1.12.5
 API version:  1.24
 Go version:   go1.6.4
 Git commit:   7392c3b
 Built:        Fri Dec 16 06:14:34 2016
 OS/Arch:      windows/amd64

Server:
 Version:      1.12.5
 API version:  1.24
 Go version:   go1.6.4
 Git commit:   7392c3b
 Built:        Fri Dec 16 06:14:34 2016
 OS/Arch:      linux/amd64
$ docker-compose version
docker-compose version 1.9.0, build 2585387
docker-py version: 1.10.6
CPython version: 2.7.12
OpenSSL version: OpenSSL 1.0.2h  3 May 2016
$docker-compose --verbose config
compose.config.config.find: Using configuration files: .\docker-compose.yml
networks: {}
services:
  dockerapp:
    build:
      context: C:\Users\nidal\dockerapp
    ports:
    - 5000:5000
    volumes:
    - C:\Users\nidal\dockerapp\app:/app:rw
  redis:
    image: redis:3.2.0
version: '2.0'
volumes: {}
@shin-

This comment has been minimized.

Copy link
Contributor

@shin- shin- commented Jan 7, 2017

Did you set COMPOSE_CONVERT_WINDOWS_PATHS ?

@jleetutorial

This comment has been minimized.

Copy link
Author

@jleetutorial jleetutorial commented Jan 25, 2017

We made a .env file in same directory as docker-compose.yml file

and added COMPOSE_CONVERT_WINDOWS_PATHS=1

we have also tried this to be true.

but still getting below error.

ABHISHEK@WindowsAbhi MINGW64 ~/Desktop/docker/dockerapp-releases/dockerapp-0.4/dockerapp-0.4
$ docker-compose up
dockerapp04_redis_1 is up-to-date
Creating dockerapp04_dockerapp_1

ERROR: for dockerapp Cannot create container for service dockerapp: Invalid bind mount spec "C:\Users\ABHISHEK\Desktop\docker\dockerapp-releases\dockerapp-0.4\do
ckerapp-0.4\app:/app:rw": Invalid volume specification: 'C:\Users\ABHISHEK\Desktop\docker\dockerapp-releases\dockerapp-0.4\dockerapp-0.4\app:/app:rw'
←[31mERROR←[0m: Encountered errors while bringing up the project.

@abhisheks2010

This comment has been minimized.

Copy link

@abhisheks2010 abhisheks2010 commented Jan 28, 2017

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

@igordata

This comment has been minimized.

Copy link

@igordata igordata commented Feb 2, 2017

Just type "export COMPOSE_CONVERT_WINDOWS_PATHS=1" and it will work until reboot.

@BlakeWills

This comment has been minimized.

Copy link

@BlakeWills 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-

This comment has been minimized.

Copy link
Contributor

@shin- 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

This comment has been minimized.

Copy link

@DavidAdamczyk 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

This comment has been minimized.

Copy link

@HWiese1980 HWiese1980 commented Jul 15, 2017

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

@rolandwolters

This comment has been minimized.

Copy link

@rolandwolters 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

This comment has been minimized.

Copy link

@HWiese1980 HWiese1980 commented Jul 17, 2017

Yes, you can. At least on Windows 10.

@riker09

This comment has been minimized.

Copy link

@riker09 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-

This comment has been minimized.

Copy link
Contributor

@shin- shin- commented Jul 25, 2017

If you're still having issues, please make sure your shared drives are configured properly: https://blogs.msdn.microsoft.com/stevelasker/2016/06/14/configuring-docker-for-windows-volumes/

@shin- shin- closed this Jul 25, 2017
@cre8

This comment has been minimized.

Copy link

@cre8 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

This comment has been minimized.

Copy link

@peteanusergiu 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

This comment has been minimized.

Copy link

@jaspervandaele 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

This comment has been minimized.

Copy link

@cvillerm 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

This comment has been minimized.

Copy link

@brianrichins brianrichins commented Dec 7, 2017

@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

This comment has been minimized.

Copy link

@aysark aysark commented Mar 14, 2018

@jaspervandaele thanks for that- solved it for me.

@gersondinis

This comment has been minimized.

Copy link

@gersondinis gersondinis commented Apr 8, 2018

  1. On Command Line: "set COMPOSE_CONVERT_WINDOWS_PATHS=1";
  2. Restart Docker for Windows;
  3. Go to Docker for Windows settings > Shared Drives > Reset credentials > select drive > Apply;
  4. Reopen Command Line;
  5. Kill the Containers;
  6. Rerun the Containers.
@wsmelton

This comment has been minimized.

Copy link

@wsmelton 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:

image

@gersondinis

This comment has been minimized.

Copy link

@gersondinis gersondinis commented Apr 24, 2018

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

This comment has been minimized.

Copy link

@tnovau tnovau commented Apr 30, 2018

@gersondinis Thanks!, that solved my problem!

@wsmelton

This comment has been minimized.

Copy link

@wsmelton wsmelton commented May 10, 2018

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

image

@roeehershko

This comment has been minimized.

Copy link

@roeehershko 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!

@ELI7VH

This comment has been minimized.

Copy link

@ELI7VH 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

This comment has been minimized.

Copy link

@Lobosque 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-

This comment has been minimized.

Copy link
Contributor

@shin- shin- commented Aug 13, 2018

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

@stavrogin

This comment has been minimized.

Copy link

@stavrogin 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.

  1. On Command Line: "set COMPOSE_CONVERT_WINDOWS_PATHS=1";
  2. Restart Docker for Windows;
  3. Go to Docker for Windows settings > Shared Drives > Reset credentials > select drive > Apply;
  4. Reopen Command Line;
  5. Kill the Containers;
  6. Rerun the Containers.

You're the man, it solved the problem, thank you

@philippelamny

This comment has been minimized.

Copy link

@philippelamny 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

This comment has been minimized.

Copy link

@tylim88 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:

image

you are not seeing it because you are using window container, you need to switch to linux container

@dbjpanda

This comment has been minimized.

Copy link

@dbjpanda 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

This comment has been minimized.

Copy link

@aalkz 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

@BenMatheja

This comment has been minimized.

Copy link

@BenMatheja BenMatheja commented Feb 3, 2019

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
@gischy

This comment has been minimized.

Copy link

@gischy 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"

Iristyle added a commit to Iristyle/pupperware that referenced this issue Mar 29, 2019
 - 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

 - Additional code will be added to perform cleanup from tests

 - 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)
Iristyle added a commit to Iristyle/pupperware that referenced this issue Mar 29, 2019
 - 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

 - Additional code will be added to perform cleanup from tests

 - 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)
Iristyle added a commit to Iristyle/pupperware that referenced this issue Mar 29, 2019
 - 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

 - Additional code will be added to perform cleanup from tests

 - 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)
Iristyle added a commit to Iristyle/pupperware that referenced this issue Mar 29, 2019
 - 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
Iristyle added a commit to Iristyle/pupperware that referenced this issue Mar 29, 2019
 - 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
Iristyle added a commit to Iristyle/pupperware that referenced this issue Apr 1, 2019
 - 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

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