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

[eino-makitalo]

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]

[ibi8588]

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]

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

[ohernandez-getinsoft]

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]

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]

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.

[0xTanvir]

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

[Luto73]

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]

Follow the instructions stated in the following page:

http://support.divio.com/local-development/docker/how-to-use-a-directory-outside-cusers-with-docker-toolbox-on-windowsdocker-for-windows

[jefflill]

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]

@rfulwell's solution worked for me. Thanks!

[Szauka]

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

[andzejsw]

I just rebuilt all images and it worked.

[glaux]

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]

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 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]

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]

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]

I solve it by simply run this safe command

docker volume prune

[alcarcdr]

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

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]

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

[incyg]

I experienced this as well when using Testcontainers for integration testing on a Windows 10 Pro machine Version 1803 (OS Build 17134.228).

That system uses the same Docker version as @niktekusho.

I was able to recover from that problem as mentioned by other commenters here. Note that no changes were made to the Docker installation or its configuration which would somehow explain this problem to appear.

[yanxiaobo]

I fixed it by start windows network for docker

[marcoebbinghaus]

Having the same bug. I created the container successfully (including a volume) and got the error message

Error response from daemon: error while creating mount source path '/host_mnt/c/Users/marcoebbinghaus/.gradle': mkdir /host_mnt/c: file exists

when trying to start it with docker start.

Had to remove / create the container three times and then I could start it successfully.

[CyberGirl007]

When I wanted to set up Windows Subsystem for Linux on my laptop, I had the following error:

Removing db_1
Recreating 7a6d58593003_db_1 ...
Recreating 7a6d58593003_db_1 ... error

ERROR: for 7a6d58593003_db_1  Cannot start service db: error while creating mount source path '/host_mnt/c/Users/user/project/dbdata': mkdir /host_mnt/c: file exists

ERROR: for db  Cannot start service db: error while creating mount source path '/host_mnt/c/Users/user/project/dbdata': mkdir /host_mnt/c: file exists
ERROR: Encountered errors while bringing up the project.

What worked for me was:

1. Remove all containers: docker rm $(docker ps -aq)
2. Remove all volumes that I can: docker volume rm $(docker volume ls -q)
3. Restarting Docker for Windows: right click on Docker in the tray, click Quit Docker, and restart Docker for Windows
4. Unsharing and re-sharing the C:/ drive in the Docker settings
5. Running docker-compose up --build.

[bwhitacrejha]

Resetting the credentials like @rfulwell and @Szauka worked for me as well even in a case where the credentials hadn't changed

[ekomc]

Same here, resetting credentials usually works when I change my password but I had this error message for 3 days in a row without a single password change.

[taikulawo]

Well, I use windows symbol link, because of golang's $GOPATH, I store my codes into D:\\ but I link D:\\codes to my $GOPATH/src/iamwwc.com/codes so I can write codes in $GOPATH, When I run docker-compose up -d in $GOPATH/src/iamwwc.com/codes, this error occur, when run in D:\\codes, all worked

SO please pay attention to whether you use symbol link

[remmeier]

I use git bash on windows a lot and frequently run into the issue. Paths are handled in there a bit differently as well (like /c/ instead of c:/). Not sure whether that might be related.

[luispfgarces]

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.

[JonKoala]

@iamwwc's comment was on point with my case, i was having the same problem trying to start a container using a symlink. It works using junctions though.

[tsadiq]

Thx to @CyberGirl007 unsharing then sharing the C: drive again did the trick 👌

[hammypants]

Thanks to @Szauka as my issue was definitely a changed pw issue.

[LiamKarlMitchell]

Windows 10, Changed password issue, Reset credentials in Docker's system tray then docker-compose up resolved this.

error while creating mount source path '/host_mnt/f/Dev/project': mkdir /host_mnt/f: file exists"

[enhancednaong]

@rfulwell and @Szauka ' solutions worked for me! the reason was changing password periodically.

[obriat]

[edit] I thought Reset credential was working, but it finally failed 15 minutes later... Since my migration to docker CE windows 2.0, my mounts don't last long and I have to restart docker again and again... @remmeier you're right there is a deeper issue

[remmeier]

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]

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]

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]

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]

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.

[K12f]

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

[VitalyKrenel]

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]

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

[rfgamaral]

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:

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]

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]

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]

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]

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