Error while creating mount source path '...' no such file or directory

[Pomax]

I'm tearing my hair out (what's left of it) over docker-compose crashing out with a "Cannot start service web: error while creating mount source path" error, reporting that it can't run chown, a command that isn't used anywhere in our codebase.

I tried Windows 10 Pro x64 anniversary edition and creator edition, with stable and edge versions of Docker for Windows, and in all four cases things just plain old do not work. Things work on OSX, which isn't super useful when things only work on a too-small-to-seriously-dev-on macbook.

I'm trying to run start up the docker container we defined for https://github.com/mozilla/network-api, of which the relevant parts are the following.

Dockerfile content:

FROM python:3.6

WORKDIR /app
EXPOSE 5000
COPY ./requirements.txt .
RUN pip install -r requirements.txt ipdb==0.9.3 --no-cache-dir --disable-pip-version-check
COPY ./app .
COPY ./scripts/prepare_container.sh ../

./scripts/prepare_container.sh content:

#!/usr/bin/env bash
mkdir -p media/images/shared
cp networkapi/static/shared/images/default.png media/images/shared

docker-compose.yml content:

version: "3"

services:
  web:
    tty: true
    stdin_open: true
    build: .
    env_file: env.default
    ports:
      - "5000:5000"
    depends_on:
      - database
    volumes:
      - ./app:/app
    command: bash -c "../prepare_container.sh && python /app/manage.py collectstatic --noinput && python /app/manage.py runserver 0:5000"

  database:
    restart: always
    image: postgres:latest
    volumes:
      - data:/var/lib/postgresql
    ports:
      - "5432:5432"

  data:
    restart: always
    image: busybox
    volumes:
      - data:/var/lib/postgresql
    command: "true"

volumes:
  data:

docker-compose up --build result:

Removing networkapi_web_1
Building web
Step 1/7 : FROM python:3.6
 ---> 21289e3715bd
Step 2/7 : WORKDIR /app
 ---> Using cache
 ---> f7fd2bead2a6
Step 3/7 : EXPOSE 5000
 ---> Using cache
 ---> fb626f433b41
Step 4/7 : COPY ./requirements.txt .
 ---> Using cache
 ---> 5e196f1d9d78
Step 5/7 : RUN pip install -r requirements.txt ipdb==0.9.3 --no-cache-dir --disable-pip-version-check
 ---> Using cache
 ---> 47c1eae2a4fb
Step 6/7 : COPY ./app .
 ---> Using cache
 ---> 719aa538e2b2
Step 7/7 : COPY ./scripts/prepare_container.sh ../
 ---> Using cache
 ---> c3cfae5aaf91
Successfully built c3cfae5aaf91
Successfully tagged networkapi_web:latest
networkapi_data_1 is up-to-date
networkapi_database_1 is up-to-date
Recreating 524517c4e4e7_524517c4e4e7_524517c4e4e7_524517c4e4e7_524517c4e4e7_524517c4e4e7_524517c4e4e7_524517c4e4e7_524517c4e4e7_524517c4e4e7_524517c4e4e7_networkapi_web_1

ERROR: for web  Cannot start service web: error while creating mount source path '/c/Users/Pomax/Documents/git/collaborations/mozilla/network-api/app': chown /c/Users/Pomax/Documents/git/collaborations/mozilla/network-api/app: no such file or directory
ERROR: Encountered errors while bringing up the project.

And that's it, no other information, and really nothing in that error that lets me google for something that helps me solve this problem. There is literally one result if you Google for docker windows "Cannot start service" "error while creating mount source path" "no such file or directory", which is incredible =)

[Pomax]

Further testing reveals the actual problem: Docker has no idea how to work with Windows when symlinks/junctions are involved, and it would be great if its error reflected that, instead.

I have the following directory layout (with my C drive being a small but blazing fast SSD, and the J drive being half a terabyte of slower SSD):

"C:\Users\Pomax\Documents\git\" <=symlinkd=> "J:\Junctions\Git projects\"

Just to confirm it was the symlink, not the space in the symlink target, I switched this over to:

"C:\Users\Pomax\Documents\git\" <=symlinkd=> "J:\Junctions\Git\"

Which made no difference, while putting the files in a non-symlinked path on C works.

I initially thought this might also have been me having C shared, but J not shared, but keeping the symlink with both drives marked as shared still leads to the error shown above, to the solution here is two-fold:

1. an update to current docker to make sure it checks for symlinks before it executes a run, so that it can properly report "ERROR: docker-compose cannot properly run with symlinked paths on Windows", and
2. a real update to how docker works with the Windows file system, in a way such that it doesn't need to know anything about symlinks, junctions, etc, and file paths "just work(tm)" regardless of what they are according to the low level file system manager

[friism]

@simonferquel what do you think? Can we error in case the host mount target is a symlink?

[Close0]

I also ran into issues mounting a symlinked folder to a networked drive. Would be great if you could support a symlinked folder. :)

I think that at least stating that symlinked folders would be much more descriptive in what is actually going on if there is no plans (or in the near future) to support them.

[attrib]

I can confirm this issue for docker compose on Mac.

Docker: 17.06.2-ce-mac27 (19124)

Just a simple ln -s /var/www/files $HOME/file. Could be an issue that /var/www is not inside list of directories which are allowed to bind. BUT on mac /var/www is a symlink to /private/var/www and /private is inside the allowed directories. Using the full path as volume in docker-compose it works.

[docker-robott]

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale comment. Stale issues will be closed after an additional 30d of inactivity.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows. /lifecycle stale

[sshishov]

/remove-lifecycle stale

[NSikimic]

/remove-lifecycle stale

[Pomax]

bump - having a bot flag this issue as stale is a pretty strong signal that someone at docker needs to decide whether to prioritise it (it is still an issue, loads of people use symlinks, informing your users of what went wrong is not too big an ask), or to close it (no one benefits from no one at docker even looking at this issue. Close it if you have no intention to address it)

[docker-robott]

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale comment. Stale issues will be closed after an additional 30d of inactivity.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows. /lifecycle stale

[Pomax]

/remove-lifecycle stale

It would be a nice thing to actually look into this, given the huge number of Windows users on this planet.

[rynnova]

I ran into the same issue, but after I had to restart Docker on my Windows workstation due to memory issues. Never encountered this before. I have 8GiB of memory and though I have minimal applications open, I have 60-70% utilisation.

Not sure if this helps to reproduce the issue, but I thought I'd throw it out there anyway.

EDIT: This issue occurs for me with Docker for Windows using Linux containers, docker-compose and a simple nginx:alpine service with a volume mounted to /usr/share/nginx/html.

I just wanna learn D3.js, goshdarnit

EDIT 2: Through pruning volumes and networks, I got past this error. Maybe that helps.

[docker-robott]

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale comment. Stale issues will be closed after an additional 30d of inactivity.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows. /lifecycle stale

[Pomax]

/remove-lifecycle stale

And again: if someone from Docker can comment on whether this is still the case, and if it is, can we finally fix it?

[docker-robott]

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale comment. Stale issues will be closed after an additional 30d of inactivity.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows. /lifecycle stale

[Pomax]

/remove-lifecycle stale

And still: it'd be lovely if there was some kind of triaging so that every issue got at least seen by a docker dev. It's only been... oh, over 2 years.

[docker-robott]

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale comment. Stale issues will be closed after an additional 30d of inactivity.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows. /lifecycle stale

[Pomax]

I was hoping someone looked at this in the over-two-years of this issue existing, but I guess triage is just not something that happens on this repo.

[goodevilgenius]

I'm having this problem on a Linux host, but in my case, the mounted folder isn't a symlink, but a unionfs mountpoint.

I tried the following:

unionfs folder1:folder2 union-folder
cd union-folder
# A docker-compose.yml is in the folder
docker-compose up

My docker-compose.yml contains:

version: '3'
services:
  web:
    image: yiisoftware/yii2-php:7.2-apache
    volumes:
      - .:/app
    ports:
      - 80:80
    environment:
      YII_ENV: debug
      PHP_USER_ID: 1000

I get this error:

ERROR: for union-folder_web_1  Cannot start service web: error while creating mount source path '/path/to/union-folder': mkdir /path/to/union-folder: file exists

[Pomax]

For my purposes, this was finally fixed a few weeks ago in the edge channel, and got fixed for everyone in 2.2 - I forgot this issue existed, and will close it now that this is no longer a problem.

You probably want to file a new issue for your problem over on the main docker repo, since this is the "docker for windows" repo. Issues for Docker on a linux host are 100% guaranteed to be off-topic =)

[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