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

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

Open
eino-makitalo opened this issue Jan 15, 2018 · 63 comments

Comments

Projects
None yet
@eino-makitalo
Copy link

commented Jan 15, 2018

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

  1. 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
  2. use container and enjoy that directory in container /src is mounted OK
  3. docker stop this container
  4. 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 ?

@eino-makitalo

This comment has been minimized.

Copy link
Author

commented Jan 15, 2018

image

@ibi8588

This comment has been minimized.

Copy link

commented Jan 16, 2018

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.

@aalteirac

This comment has been minimized.

Copy link

commented Jan 23, 2018

I have the same issue, not even sure it's only after a container restart, seems like a "time-out" :-/

@ohernandez-getinsoft

This comment has been minimized.

Copy link

commented Feb 8, 2018

Got same error when trying to do docker-compose run

Here are my specs:

Docker

Client:
Version: 17.12.0-ce
API version: 1.35
Go version: go1.9.2
Git commit: c97c6d6
Built: Wed Dec 27 20:05:22 2017
OS/Arch: windows/amd64

Server:
Engine:
Version: 17.12.0-ce
API version: 1.35 (minimum version 1.12)
Go version: go1.9.2
Git commit: c97c6d6
Built: Wed Dec 27 20:12:29 2017
OS/Arch: linux/amd64
Experimental: true

Docker-compose

docker-compose version 1.18.0, build 8dd22a96
docker-py version: 2.6.1
CPython version: 2.7.14
OpenSSL version: OpenSSL 1.0.2k 26 Jan 2017

OS

Windows 10 Pro

I was just working on a dev-custom image with some volumes when suddenly i got a weird behaviour so i restarted the container and when tried to run that container the error happened

$ docker-compose run --rm --service-ports web
Starting erpassetel_db_1 ... done
Error response from daemon: error while creating mount source path '/host_mnt/c/Users/randomUser/Documents/folder1/subFolder2/Addons': mkdir /host_mnt/c: file exists

After 5 minutes i just tried to run the containers again and it all worked well again

@marcel-dempers

This comment has been minimized.

Copy link

commented Feb 10, 2018

Got the same on windows:

 docker run -it -v "C:\git\somerepo\somefolder":/usr/lib/src alpine:3.7
docker: Error response from daemon: error while creating mount source path '/host_mnt/c/git/somerepo/somefolder': mkdir /host_mnt/c: file exists.
@rfulwell

This comment has been minimized.

Copy link

commented Feb 27, 2018

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.
image

@0xTanvir

This comment has been minimized.

Copy link

commented Mar 11, 2018

I was able to resolve it by running at Windows PowerShell (Admin).

@Luto73

This comment has been minimized.

Copy link

commented Mar 12, 2018

I do have a similar problem. Yesterday I created a container at D:\Users\myname\docker\test (Windows 10 Pro). When I try to restart the container using

docker run -d -p 8008:80 -v D:/Users/myname/docker/test:/var/www/html php:apache

I get:

cd72fdb49e2d5067c0f5d4ff6ab0ae87c038db8b22492e280c9e80fe550e3499 docker: Error response from daemon: error while creating mount source path '/host_mnt/d/Users/myname/docker/test': mkdir /host_mnt/d: file exists.

I tried to start the container with the normal command shell and with Windows Power Shell, neither works. Any ideas?

docker version:

Client:
Version: 17.12.0-ce
API version: 1.35
Go version: go1.9.2
Git commit: c97c6d6
Built: Wed Dec 27 20:05:22 2017
OS/Arch: windows/amd64

Server:
Engine:
Version: 17.12.0-ce
API version: 1.35 (minimum version 1.12)
Go version: go1.9.2
Git commit: c97c6d6
Built: Wed Dec 27 20:12:29 2017
OS/Arch: linux/amd64
Experimental: false

docker info:

Containers: 9
Running: 0
Paused: 0
Stopped: 9
Images: 4
Server Version: 17.12.0-ce
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 macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 89623f28b87a6004d4b785663257362d1658a729
runc version: b2567b37d7b75eb4cf325b77297b140ea686ce8f
init version: 949e6fa
Security Options:
seccomp
Profile: default
Kernel Version: 4.9.60-linuxkit-aufs
Operating System: Docker for Windows
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 2.916GiB
Name: linuxkit-00155d2be407
ID: IDQV:LURY:R3IV:WDL5:VTEI:PQSH:UH4Y:AS3F:4ZHK:3SNZ:F65U:P2P4
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): true
File Descriptors: 24
Goroutines: 56
System Time: 2018-03-12T20:52:17.1549674Z
EventsListeners: 1
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false

@chavolla

This comment has been minimized.

@jefflill

This comment has been minimized.

Copy link

commented Mar 22, 2018

We see this a few times a week on 17.12.0-ce-win47 (15139).

Sometimes this is transient and the problem goes away after retrying running the container a few times. Other times, restarting Docker helps. Every week or two, we need to reset Docker back to factory defaults to get this working again.

This doesn't appear to be a drive sharing security issue. The problem appears to be that the mount point already exists and Docker is trying to mount it again, and that's what's failing.

@NdubisiOnuora

This comment has been minimized.

Copy link

commented Mar 22, 2018

@rfulwell's solution worked for me. Thanks!

@Szauka

This comment has been minimized.

Copy link

commented Apr 11, 2018

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

image

@andzejsw

This comment has been minimized.

Copy link

commented Apr 27, 2018

I just rebuilt all images and it worked.

@glaux

This comment has been minimized.

Copy link

commented May 22, 2018

Resetting the credentials like @rfulwell and @Szauka worked even in a case where the credentials hadn't changed - docker had simply stopped working after a wakeup.

@chromygabor

This comment has been minimized.

Copy link

commented May 31, 2018

Same happens to me. It occurs only after a while, or maybe after returning from sleep. But Reseting credentials solves this problem. For a while...

@borgdrone7

This comment has been minimized.

Copy link

commented Jun 1, 2018

This is obviously a bug which should be resolved. We are forced to reset docker (or credentials) all the time, it is not acceptable solution. This is introduced with the latest version as I was using previous versions for months and this was never happening before.

@darinrandal

This comment has been minimized.

Copy link

commented Jun 1, 2018

None of the above solutions worked for me. The issue I had in this case was I had a separate user setup since I used a Microsoft account. That all worked fine and dandy but then Microsoft released an update which reset all those permissions on the folders leading up to my working/mount directory and I ended up with this issue.

@LiamKarlMitchell

This comment has been minimized.

Copy link

commented Jun 2, 2018

Why does it need C drive? store the .composer in the directory im running docker-compose up -d from...

Ah maybe ~/.composer to ./.composer in the composer.yml.

I actually just created a blank file and it seems like it worked.

@yccheok

This comment has been minimized.

Copy link

commented Jul 25, 2018

I solve it by simply run this safe command

docker volume prune
@AlanCarlyle

This comment has been minimized.

Copy link

commented Jul 25, 2018

@rfulwell's solution and @Szauka's simplification seemed to work for me on my Windows 10 Pro.
Thanks everyone for helping with this... and best of luck finding a code fix

@nhudson76

This comment has been minimized.

Copy link

commented Jul 27, 2018

FWIW - PHP Storm's Docker integration can contribute to this.
It's fairly anecdotal, but I can reproduce it.
I was working in a container, stopped that & started another;
connected PHPS to daemon, pruned when done, 1st container no longer builds.

Steps to reproduce:

  • Version 18.06.0-ce-win72 (19098)
  • PHPS 2018.1.1
  • [AzureAD account drive share / user workaround in place]
  1. ~/projectA$ docker-compose up -d
  2. ?? (do whatever. collect underpants.)
  3. ~/projectA$ docker stop $(docker ps -a -q)
  4. ~/projectB$ docker-compose up -d
  5. PHPStorm > View > Tool Windows > Docker > [Connect] > projectB_xxx_1 > ENV Vars
  6. ~/projectB$ docker-compose down (confirmed all containers removed)
  7. ~/projectA$ docker-compose up -d
  8. error while creating mount ... mkdir /host_mnt/c: file exists
  9. PHPStorm > Docker > Disconnect
  10. ~/projectA$ docker-compose up -d
    Builds OK

Note I did not use any start/stop functionality in PHPS, I simply clicked 1 container to inspect the ENV & I probably left it 'focused' while stopping/starting. UDP connection probably remained intact, I did not look for this in logs.

Log reports "SMB signature verification returned error = -13"
and flip-flops between
"proxy >> GET /v1.24/containers/json?all=true\n"
and
"proxy >> GET /v1.25/containers/json?all=true\n"
so maybe some discrepancy there? idk

@niktekusho

This comment has been minimized.

Copy link

commented Aug 6, 2018

I just encountered this.

$ docker version
Client:
 Version:           18.06.0-ce
 API version:       1.38
 Go version:        go1.10.3
 Git commit:        0ffa825
 Built:             Wed Jul 18 19:05:28 2018
 OS/Arch:           windows/amd64
 Experimental:      false

Server:
 Engine:
  Version:          18.06.0-ce
  API version:      1.38 (minimum version 1.12)
  Go version:       go1.10.3
  Git commit:       0ffa825
  Built:            Wed Jul 18 19:13:46 2018
  OS/Arch:          linux/amd64
  Experimental:     false

Since I was sure I did not change my user password nor did modify permissions on the shared drives, I simply tried to restart the docker daemon and it solved the issue. I'll report back if it happens again (just to make sure my workaround remains consistent I guess...)

@remmeier

This comment has been minimized.

Copy link

commented Nov 22, 2018

for sure not a password issue in my case, so there is still a deeper issue somewhere i think. but restarting docker helped everytime so far

@obriat

This comment has been minimized.

Copy link

commented Nov 23, 2018

I still get the error frequently. To me the easiest workaround it to uncheck>apply>check>apply my "share drive" (without the need to restart docker).

@rfay

This comment has been minimized.

Copy link

commented Nov 23, 2018

We see this often on Windows test machines running tests. Regardless of any action with docker, it will typically work fine on the test retry. IMO all the workarounds here are probably valid, but I think this is mostly just an intermittent problem.

@jefflill

This comment has been minimized.

Copy link

commented Nov 23, 2018

We also see this when running unit tests on Windows start start/stop lots of containers with mounted host directories but we also see this sometimes when starting containers manually too.

I suspect that this may be a Docker race condition where Docker may sometimes may not have fully removed an old mount before creating the new one. This is actually fairly serious problem and I'm surprised that it hasn't been addressed yet since Windows is an important platform for Docker. Perhaps this isn't an issue for Kubernettes mode or when running on Windows Server.

This thread is getting really long, so I'm going to submit a new issue and see what happens. Unfortunately, I'm not a golang developer so I haven't tried to investigate this.

EDIT: I made it clear that I'm mounting host directories, not volumes.

EDIT: I spent some more time trying to get a reliable repo for this without success.

One thing I did just notice is that I'm using the old -v option instead of --mount. I'm going to update this and try it for a while to see if this helps before looking at submitting a new issue.

@kiahmed

This comment has been minimized.

Copy link

commented Dec 7, 2018

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.

what if removing volume isnt an option. This could happen if docker for windows auto updates docker and loses existing drive permission for some reason or somehow engine lost the credentials that you set first time to access the drive (i ma talking about windows scenario) .

I resolved it by manually un ticking the drive access and tick it back with the credentials again.

@sometumi

This comment has been minimized.

Copy link

commented Dec 14, 2018

docker volume rm -f $(docker volume ls -q)

@VitalyKrenel

This comment has been minimized.

Copy link

commented Dec 25, 2018

Why no one from docker development team has addressed this issue so far? The problem is quite annoying but it doesn't look like the hardest problem to solve (whether it is a race condition or just failed remounting attempt).

If there was a try solving this issue and complications emerged I would easily understand. But the complete silence when so many developers encountering the problem is unimaginable.

@u007

This comment has been minimized.

Copy link

commented Jan 11, 2019

yes this is quite a pain,
ive client that actually requires user to reset their password every 30days

@rfgamaral

This comment has been minimized.

Copy link

commented Jan 15, 2019

I think I'm having a problem where the cause is this same as this issue.

Take the following docker-compose-yml for instance:

version: '3.5'
services:
  traefik:
    image: traefik:1.7-alpine
    volumes:
      - ./placeholder.txt:/placeholder.txt
    restart: always

Running docker-compose up -d works just fine (tried this on WSL and PowerShell), what doesn't work is the restart: always. I mean, say I restart Docker engine:

image

I expect my container to start automatically but it doesn't:

docker ps --all
CONTAINER ID        IMAGE                COMMAND                  CREATED             STATUS                       PORTS               NAMES
a9488288d653        traefik:1.7-alpine   "/entrypoint.sh trae…"   4 minutes ago       Exited (255) 3 minutes ago   80/tcp              docker-test_traefik_1

If it helps:

docker --version
Docker version 18.09.1, build 4c52b90
@rfay

This comment has been minimized.

Copy link

commented Jan 16, 2019

I'd be interested to know if anybody has found a workaround. Our Windows test machines get this so very often:

C:\Program Files\Docker\Docker\Resources\bin\docker.exe: Error response from daemon: error while creating mount source path '/c/Users/testbot/tmp/buildkite/testbot-dell-win10pro-2-1/drud/quicksprint-windows': mkdir /c: file exists.

I'm thinking about wrapping docker-compose in a script that retries (it normally succeeds the next time, or the time after, same machine, no config change). But that seems so very ugly. But it would deal with the fact that we have to push the button to retry these tests.

@gimntut

This comment has been minimized.

Copy link

commented Jan 17, 2019

I changed the Windows user password.
Previously, the password was written in Cyrillic. I got the error in 2-3 hours.
Now the numeric password. The mount error only appears after 2 weeks.

@dlencer

This comment has been minimized.

Copy link

commented Jan 22, 2019

For those looking for a workaround for the time being:
The issue seems to be some kind of timeout for the credentials required to access your (shared) drive as someone noted before. The problem might be related to using a Windows domain user accounts, but I cannot check that, unfortunately. By un- and then re-sharing drive c: as advised in this thread, I was reliably able to bring my container (which just serves some code stored on a folder on drive c: of the host and is started via docker-compose up) back up each time I was confronted with the error message [...] mkdir /host_mnt/c: file exists upon trying to restart it. Just retrying did not help, un-/resharing was the only way.

Yet, as long as I keep on restarting this container (via docker-compose restart <mycontainer>) frequently enough, that is at least every 10 minutes, everything seems fine so far, the error does not show up anymore (fingers crossed). You can use some simple script for that purpose.

It does not help to keep restarting some other dummy-container which does nothing but having access to some other folder on the same drive of the host, at least my test case failed. Obviously, this workaround will not be helpful for all use-cases, but in my special case during development it is ok as I have to restart frequently anyways. It is definitely more comfortable for me than having to un-/reshare the drive all the time in the GUI.

This issue is a real showstopper for Windows-users, I have a hard time advertising the use of docker in my organization because of it, so I hope someone will be able to fix it soon.

@VitalyKrenel

This comment has been minimized.

Copy link

commented Feb 1, 2019

I've decided to try Docker Toolbox on my computer a month ago (or so), because my team mate have had a problem with starting our containers with Toolbox. We've fixed everything, but that not what's matter.

What's matter is that on Docker Toolbox there's no such issue with that Errror mkdir /host_mnt/c: file exists error message. Though Docker Toolbox is considered to be a legacy solution - Docker Native works only with Education, Pro or Enterprise editions of Windows 10 on the computers with the Hyper V support, that actually is available only on the up-to-date hardware - it is actually a more stable, then the Native version.

Try researching whether the Docker Toolbox is appropriate for your development and use it instead of the Native version, if it's appropriate. I know, it's not a complete solution, but that is what we can stick for now, while Docker is no addressing this issue at all (I hope they are, but there's no any apparent sign of that).

@oldium

This comment has been minimized.

Copy link

commented Feb 1, 2019

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.

@dlencer

This comment has been minimized.

Copy link

commented Feb 1, 2019

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

@herbinator

This comment has been minimized.

Copy link

commented Feb 6, 2019

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

This comment has been minimized.

Copy link

commented Feb 28, 2019

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

This comment has been minimized.

Copy link

commented Feb 28, 2019

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

@JackSlaterIV

This comment has been minimized.

Copy link

commented Mar 2, 2019

Quote from #1560 (comment)

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.

image

Works like a charm then:
image

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)?

@pikenikes

This comment has been minimized.

Copy link

commented Mar 2, 2019

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

This comment has been minimized.

Copy link

commented Mar 3, 2019

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

This comment has been minimized.

Copy link

commented Apr 24, 2019

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

This comment has been minimized.

Copy link

commented May 9, 2019

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

This comment has been minimized.

Copy link

commented May 9, 2019

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

This comment has been minimized.

Copy link

commented May 9, 2019

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

This comment has been minimized.

Copy link

commented May 22, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.