Errror mkdir /host_mnt/c: file exists when restarting docker container with mount

eino-makitalo commented 6 years ago

Expected behavior

Container should start normally

Actual behavior

C:\Users\einom>docker start f96263b10996 Error response from daemon: error while creating mount source path '/host_mnt/c/Users/einom/Documents/projects/cap/src': mkdir /host_mnt/c: file exists Error: failed to start containers: f96263b10996

Information

Docker version: 17.12.0-ce-win47 (15139)

Windows 10 Pro Version: 1709 Build: 16299.192

Whole C drive is shared with docker VM

Steps to reproduce the behavior

start container with command similar than me in my home dir docker run -d --name sonarqube -p 9000:9000 -p 9092:9092 -v c:/Users/einom/Documents/projects/cap/src:/src:rw sonarqube
use container and enjoy that directory in container /src is mounted OK
docker stop this container
docker start container ... and you got error ... mkdir /host_mnt/c file exist.

Of cource it exists because if I understand correctly this /host_mnt/c should point to my whole C: drive ?

oldium commented 5 years ago

I switched to the Edge channel (uninstall stable, install edge) on my Windows 10 1809 computer and the problem has gone - I have not seen the mkdir error so far (cca 2 days, few restarts of the container). I am now using Docker Desktop 2.0.1.0 (30090) build c8b6ca6/edge, Engine 18.09.1, Compose 1.23.2.

Update: Nope, still there...

dlencer commented 5 years ago

I switched to edge as you recommended, but the same error showed up again.

herbinator commented 5 years ago

runnig docker run --rm -v c:/Users:/data alpine ls /data C:\Program Files\Docker\Docker\Resources\bin\docker.exe: Error response from daemon: error while creating mount source path '/host_mnt/c/Users': mkdir /host_mnt/c: file exists.

getting same error. It looks i get it when connected to vpn. when disconnecting vpn it's fine

VolkerH commented 5 years ago

I experienced this problem when connected to a VPN using the CISCO Anyconnect Secure Mobility Client. Once I quit the Cisco VPN I can mount the shares in the docker container as normal.

herbinator commented 5 years ago

what helps as workaround is changing the subnet adress in network settings and then it works fine again.

JackSlaterIV commented 5 years ago

Quote from https://github.com/docker/for-win/issues/1560#issuecomment-427566808

This issue happens to me when there's any public network on my machine. I can always get it fixed by setting network interfaces as private and restarting docker after that.

Works like a charm then:

It seems to me that Docker machine looses permissions over file system when networks go public. Even though this fixes the issue, it isn't permanent. All it takes is a restart to get Windows setting networks public again and the procedure has to be repeated.

Hope this helps anyone facing the same issue.

Thanks, did you find any way to make this a permanent workaround (survive to each Windows restart)?

luispfgarces commented 5 years ago

JackSlaterIV, I actually have been able to make this workaround permanent, all it takes is defining a PowerShell script where you get all network interfaces and loop them setting as private. With this script, you can define a startup task on Windows task scheduler.

Not the best workaround, I know, but it saves you the pain of doing this all the time.

Alternatively, if you have VMware software, you can just quit using Hyper-V as docker machine and use a VMware docker machine, I was able to get it working a few days ago. Actuality this is a issue because of issues on Hyper-V network connectivity.

JackSlaterIV commented 5 years ago

JackSlaterIV, I actually have been able to make this workaround permanent, all it takes is defining a PowerShell script where you get all network interfaces and loop them setting as private. With this script, you can define a startup task on Windows task scheduler.

Not the best workaround, I know, but it saves you the pain of doing this all the time.

Alternatively, if you have VMware software, you can just quit using Hyper-V as docker machine and use a VMware docker machine, I was able to get it working a few days ago. Actuality this is a issue because of issues on Hyper-V network connectivity.

Thanks man. I had followed your tip and that seemed to work, but I still get the issue. For me it happens again in a matter of minutes. I hope the team will find a proper way to solve this. At this point to fix this I need to uncheck and recheck the drive letter in settings->shared drives (no need to restart any container or authenticate again).

svetkomir commented 5 years ago

For me this is strictly related to VPN.

When I'm not connected to VPN it works fine. Then I connect and I start getting the error immediately.

What I did is I restarted Docker after connecting to VPN.

deanmcginndm commented 5 years ago

I had the same issue. I was able to resolve it by running: docker volume rm -f [name of docker volume with error] Then restarting docker, and running: docker-compose up -d --build

I tried these same steps without restarting my docker, but restarting my computer and that didn't resolve the issue. What resolved the issue for me was removing the volume with the error, restarting my docker, then doing a build again.

Unsure if you did, but please can you kindly explain the meaning of the "-d" and "--build" in "docker-compose up -d --build" please?

I don't mean "this is what the man-page says", rather I mean what is the human explanation of the flags?

Also, this worked perfectly for me, I had to restart the host machine aswell.

JackSlaterIV commented 5 years ago

The only solution that works for me is this guide https://web.archive.org/web/20180719031325/http://peterjohnlightfoot.com/docker-for-windows-on-hyper-v-fix-the-host-volume-sharing-issue/ It has been reported in other replies, and I would give it a try. Basically you need to create a new user under Windows 10 and then use it in Docker: something like 10.0.75.1\DockerUser with a password that does not contain special characters (which are the cause of the issue).

svetkomir commented 5 years ago

Adding this route after connecting to the VPN fixed it consistently for me. This is the default network configuration for Docker for Windows.

route ADD 10.0.75.0 MASK 255.255.255.0 10.0.75.1

abarke commented 5 years ago

GlobalProtect VPN Client and the Cisco Anyconnect VPN Client are the problems on our end. These interfere with mounting shared folders.

Is there a solution for the VPN use case?

Potential solution but unexplored: https://forums.docker.com/t/docker-problem-on-windows-with-globalprotect-vpn/54259

rakekris commented 5 years ago

On Windows this may be due to a user password change. Uncheck the box to stop sharing the drive and then allow Docker to detect that you are trying to mount the drive and share it.

this worked for me. thank you

nea commented 5 years ago

Hi everyone

Does anybody has a different suggestion on how to solve this?

I restarted Docker, reset my credentials, created a special 'docker' user as admin on Windows, removed volumes, rebuild... but absolutely nothing is working.

I just have two simple bindings but it just will not work, no matter how many times I restart, reset or whatever.

volumes:
      - ./:/app
      - ./.docker/site.conf:/etc/nginx/conf.d/default.conf

If there would at least be some hint where to look, unfortunately it becomes frustrating...

Any help is highly appreciated.

Thanks a lot

oldium commented 5 years ago

If you do not insist on using stable software (if you are not in production environment), there is an experimental WSL2 way of running Docker directly on Windows (see example) in virtualized container (plus some manual port forwarding is needed to access containers from other computers) - in July the Docker folks plan to release experimental Docker with WSL2 support. Another way is to use experimental LCOW (with latest builds and LCOW image), but latest LCOW kernel image does not boot (you can use former one) and my personal experience is that containers are not able to stop properly, after reboot they are not able to start - I have to rebuild them on every reboot (which does not happen often), but data are fine. Otherwise LCOW is stable for me (I keep it running until Windows update reboots), I have not seen mkdir error for ages. I look forward to test WSL2 way as soon as experimental Docker with WSL2 support is out.

nea commented 5 years ago

Hi @oldium

I am also looking forward to a finalized WSL2 integration. The collaboration between Microsoft and Docker seems promising for quite some time now and will (hopefully) align development needs throughout operatings systems in the future.

For now: I just tried Docker Edge Channel because what did I have to loose ^^' And it works! Docker Edge 2.0.5.0 works. Docker 2.0.0.4 (I think) did not work. Same docker-compose.yml file.

Thanks

HakaiNoKami commented 5 years ago

A solução de @rfulwell funcionou para mim. Obrigado!

Laubeee commented 5 years ago

docker-compose up -V worked for me.

from docker-compose up --help:

-V, --renew-anon-volumes   Recreate anonymous volumes instead of retrieving data from the previous containers.

mapruyas commented 5 years ago

For those who got here, try above solutions and didnt work... I was mounting volumens that were symbolic links, some of them worked, others where erroring with file exists.

The problem was the way I created the links, creating the links this way solved the issue for me.

mklink /J "C:\path_to_target\" "C:\path_to_link"

then it worked

TheJoeSchr commented 5 years ago

docker-compose up -V worked for me.

from docker-compose up --help:
-V, --renew-anon-volumes   Recreate anonymous volumes instead of retrieving data from the previous containers.

That worked for me. quick and easy! Thx

joshlsullivan commented 5 years ago

I just ran docker-compose down and then docker-compose up. Worked for me.

glorynguyen commented 5 years ago

I have tried with docker container prune then press y to remove all stopped containers. This issue has gone.

EliCDavis commented 5 years ago

Running docker-compose down did not solve the issue. I didn't have to reset drive credentials. I just reset the docker desktop and it started working.

It's super annoying trying to get people to adopt docker where I'm at, as we're routinely running into issues on our dev machines, and almost always the fix is "just restart docker". It fixes issues like this one and others. It's almost every day, on every computer.

psyclr commented 5 years ago

As mentioned, it should be checked. But even if it already checked - uncheck and check again, donno why, but works

joguarino commented 5 years ago

I don't know if it has been already told, but I solved this problem simply setting more privileges to the execution of Docker Desktop (I'm on Windows 10).

First of all, quit Docker Desktop if running. Then go to the installation folder (C:\Program Files\Docker\Docker), and right-click "Docker Desktop.exe" to open the contextual menu, where you have to click "Program Compatibility Troubleshooter". In the opened window click on "Troubleshoot program", then check "The program requires additional permissions": this will give administrator permission to the program. In the next window just click on "Test the program" and wait for Docker Desktop to start: check the mount problem is solved and, if it is so, go to the next window and click on "Yes, save these settings for this program".

It should work.

centur commented 5 years ago

another option that helped me - reset docker to factory defaults.

wussup commented 5 years ago

In my case, the problem was with Windows user credentials - my password was expired. Relogin helped.

xer10m commented 5 years ago

I have the following problem: We use Docker for our CI / CD to perform integration tests. Our build server has 10 agents. Each of these agents runs Docker Desktop (Windows machines). About once a day we get an "ERROR: for compose_db_1 Can not start service db: error while creating mount source path: mkdir / host_mnt / c: file exists" or an „ERROR: for compose_db_1 Cannot create container for service db: b'Drive sharing failed for an unknown reason'“ error. But it is completely random when and on which agent the error occurs. Once an agent throws an error, we need to restart the build and it will run again. It does not matter whether the build is triggered on the same machine. Does anyone have an idea what we can do?

EliCDavis commented 5 years ago

@xer10m this is a shot in the dark, but maybe you could try doing a docker desktop reset every time before you try running your tests. I have no idea whether or not that'll work though

pavan2106 commented 5 years ago

@rfulwell's solution works! But it's easier to use the Reset Credentials... button.

Your suggestion helped me for the day... Thank you very much..

abarke commented 5 years ago

Be aware, every time your windows password changes. You will need to click "Reset credentials..."

oldium commented 5 years ago

Sometimes this helps even without changing the password...

CodeGTDLearn commented 5 years ago

Step 01: https://tomssl.com/2018/01/11/sharing-your-c-drive-with-docker-for-windows-when-using-azure-active-directory-azuread-aad/

Step 02: @alexkoepke Solution. https://github.com/docker/for-win/issues/3385

UnnitMetaliya commented 5 years ago

Just restart your system and it will ask for your system password. Give your password to Docker as it needs to access your file system.

Every once in a while, you need to make sure your Docker Desktop is running.

nidhimundra commented 5 years ago

I ran docker volume prune, and restarted my docker and it worked.

rm-bergmann commented 4 years ago

I am getting this problem now. Windows 10 upgraded to Build 19013.vb_release.191025-1609 (Insiders build) and now I can't start my docker container (I have tried everything listed above.)

ERROR: for [container-name] Cannot start service [container-name]: error while creating mount source path '/host_mnt/c/www/docker-projects/cdn': mkdir /host_mnt/c: file exists

1 thing that looks different is host_mnt, in WSL1 if I ls the root directory, it's just mnt so not sure if something has changed or if it was like that before.

I can't seem to roll back the update, so I will try to use WSL2.

ghost commented 4 years ago

@rfulwell worked for me too

oldium commented 4 years ago

Just tested latest WSL2 Backend (no need to have Ubuntu inside WSL2 any more) with Windows build from Insider's Slow Ring (build 19013.1122) with Bitwarden Docker image and it works very well - fast startup (after first setup, of course), no errors shown during containers setup, running smoothly. Well done! This milestone should mark the end of this issue to everyone (I hope, fingers crossed).

rm-bergmann commented 4 years ago

Installing WSL 2 solves my problem, and is a huge improvement over all.

oldium commented 4 years ago

Just info for others planning to try WSL2 - latest Docker Desktop Edge 2.1.6.0 now requires build 19018, which is in Fast Ring. ~~Slow Ring is not sufficient anymore.~~

Edit: Slow Ring catches up, so not any more an issue.

nebuk89 commented 4 years ago

Outside of WSL2 we have also now moved over from using Samba to using GRPCFuse in 2.1.6.0, it would be great if people with this issue could let me know if they still experience it on 2.1.6 outside of WSL.

lrpinto commented 4 years ago

I am not sure what worked for me, but resetting credentials seems to have led me into the right direction, as after this my error changed to a firewall issue.

I followed instructions here https://docs.docker.com/docker-for-windows/#firewall-rules-for-shared-drives. And before rebuilding I have also pruned containers, images and volumes.

In short, I am running Windows 10 host, Ubuntu 18.04 guest via WSL, and Docker Desktop with daemon exposed.

developer@DESKTOP-6V1G8RH:~$ docker info
Client:
 Debug Mode: false

Server:
 Containers: 2
  Running: 2
  Paused: 0
  Stopped: 0
 Images: 22
 Server Version: 19.03.5
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: true
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: b34a5c8af56e510852c35414db4c1f4fa6172339
 runc version: 3e425f80a8c931f88e6d94a8c831b9d5aa481657
 init version: fec3683
 Security Options:
  seccomp
   Profile: default
 Kernel Version: 4.9.184-linuxkit
 Operating System: Docker Desktop
 OSType: linux
 Architecture: x86_64
 CPUs: 2
 Total Memory: 1.952GiB
 Name: docker-desktop
 ID: 7CSG:TINY:2KD3:KG7U:Z6HR:4J7K:GAUB:FLP7:HSVT:YFJG:PNWB:MA3P
 Docker Root Dir: /var/lib/docker
 Debug Mode: true
  File Descriptors: 50
  Goroutines: 74
  System Time: 2019-11-25T10:33:07.613213Z
  EventsListeners: 2
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false
 Product License: Community Engine

flatline-studios commented 4 years ago

I'd just like to bring it to people's attention, that there are issues surrounding Windows Juntions (and possibly symbolic links [symlinks]), with WSL 2.

volumes:
  - "C:\\Development\\Docker\\Privacy\\socks-my-vpn\\conf:/vpn:ro"

Works just fine on Docker Desktop originally. Then yesterday I made the switch to WSL 2... And my compose file was failing with a rather cryptic error:

docker container run -it -v "C:\\Development\\Docker\\Privacy\\socks-my-vpn\\conf:/vpn" ohpe/socks-my-vpn /bin/sh
docker: Error response from daemon: error while creating mount source path '/run/desktop/mnt/host/c/Development/Docker/Privacy/socks-my-vpn/conf': mkdir /run/desktop/mnt/host/c/Development: file exists.

I spent about an hour trying various things (this is the first container I was trying to get running on WSL 2). I couldn't work out for the life of me why it was attempting to create the C:\Development folder... Then it dawned on me, C:\Development is a junction that points to S:\Development.

I'm not quite sure what's going on behind the scenes, as Docker knows that C:\Development exists (as the rather cryptic error suggests), but is unable to actually access it..?

Anyway, changing the drive letter in the volume bind mount to be:

volumes:
  - "S:\\Development\\Docker\\Privacy\\socks-my-vpn\\conf:/vpn:ro"

Solved the issue, and allowed the container to run correctly.

I'm mentioning this here to save someone else some time (I realise this is pretty niche), though, I'm still not sure why that happened in the first place?

Could the error message be made a little more explicit if it encounters a junction/symlink?

artemmolotov commented 4 years ago

@nebuk89

Outside of WSL2 we have also now moved over from using Samba to using GRPCFuse in 2.1.6.0, it would be great if people with this issue could let me know if they still experience it on 2.1.6 outside of WSL.

After upgrading to 2.1.7 and several small manual tests, I did not notice this problem (no longer appeared).

But in version 2.1.7, I have a problem with changing mounted files (as if they are in read-only mode). After changing a file on the host, the file does not change in the container...

djs55 commented 4 years ago

@artemmolotov thanks for the report! Regarding the problem

After changing a file on the host, the file does not change in the container...

I've fixed a number of bugs related to this, would you like to try an experimental build to see if it helps?

The build is https://download-stage.docker.com/win/edge/41944/Docker%20Desktop%20Installer.exe

If it still reproduces could you

reproduce the problem i.e. change a file on the host, wait a second or two, read the file in the container (with the old contents) and then upload a diagnostic report and quote the ID? The logs will contain useful diagnostic traces
could you share reproduction instructions? Ideally an example docker run -v or a docker-compose.yml so that I could try to reproduce the problem myself.

There's also a diagnostic tool which you can play with. The command

docker run -v /run:/run -it djs55/grpcfuse-control:2.2.0 statistics calls --follow

should show a live trace of FUSE filesystem events: both cache invalidations and reads/writes.

The command

docker run -v /run:/run -it djs55/grpcfuse-control:2.2.0 invalidate all

should invalidate all cache entries -- this ought to temporarily "fix" the problem (at least it would be good to verify that it actually does)

artemmolotov commented 4 years ago

@djs55 Yes, I found the #5449 and tried the build (41944) 3 days ago. I checked the version of the build before the tests. The error was present.

Now I don't see the error, although the code and configuration haven't been modified. I think this could be resolved due to a reboot of the OS, Docker Desktop, the cache invalidation or something like that.

If I reproduce the error in the future, I'll write in #5449 or a new issue.

Thank you. :)

FritsvanCampen commented 4 years ago

Like @flatline-studios mentioned I can confirm that Docker build 19.03.5, build 633a0ea no longer works with junctions. It worked fine before; previous build was maybe 2 months old?

Changing the volume mount to the non-junctioned path solved the issue for me. Would be nice if the old behavior could be restored and/or the error message be made less cryptic.

peekepic commented 4 years ago

Hi all, i reproduce same issue and i success to understand my problem. Windows 10 Pro.

Inside the windows folder that i tried to share, i had a virtual windows link to another directory make with the "MKLINK" previously. If i remove this virtual link, the issue disappear.

Hope this trick helps you.

oomkarpanditstudent commented 4 years ago

Updated to latest docker desktop 2.2.0 on 21st Jan 2020. Had issues "Errror mkdir /host_mnt/c: file exists when restarting docker container with mount"

I tried above all without luck then moved the folder I was mounting under C:\users and it worked.

Lost whole day, hope others can try this fix and save time.

docker / for-win