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

[alexey-igrychev]

In my case, docker has stopped supporting short windows filenames... I face it using the CLI tool written in Go that uses temp directory, https://golang.org/pkg/io/ioutil/#TempDir, as container mount.

To put it more simply:

$ docker run -ti --rm -v "C:\Users\ADMINI~1\AppData\Local\Temp\2":/host alpine
C:/Program Files/Docker/Docker/resources/bin/docker.exe: Error response from daemon: error while creating mount source path '/host_mnt/c/Users/ADMINI~1/AppData/Local/Temp/2': mkdir /host_mnt/c/Users/ADMINI~1: file exists.

$ docker run -ti --rm -v "C:\Users\Administrator\AppData\Local\Temp\2":/host alpine
/ # ok

$ docker info
Client:
 Debug Mode: false

Server:
 Containers: 1
  Running: 0
  Paused: 0
  Stopped: 1
 Images: 4
 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.19.76-linuxkit
 Operating System: Docker Desktop
 OSType: linux
 Architecture: x86_64
 CPUs: 2
 Total Memory: 1.92GiB
 Name: docker-desktop
 ID: DNFH:TI6L:TVPB:Z7ZK:IK65:6V57:IMZY:FZZL:XEGE:C3QF:KQ3Q:CYPZ
 Docker Root Dir: /var/lib/docker
 Debug Mode: true
  File Descriptors: 35
  Goroutines: 52
  System Time: 2020-01-22T20:17:52.675875272Z
  EventsListeners: 3
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false
 Product License: Community Engine

[AndrewSav]

In my case I'm getting this error because I have a junction in the host path

[f2calv]

After upgrading to Docker Desktop 2.2 I had the same issue as above;

ERROR: for redis Cannot start service redis: error while creating mount source path '/host_mnt/c/Users/XXXX/source/repos/MyProject/_DockerCompose/redis': mkdir /host_mnt/c/Users/XXXX/source/repos/MyProject: file exists

Below is a snippet from my failing compose file, the docker-compose.yaml file is located at c:/Users/XXXX/source/repos/MyProject/docker-compose.yaml on Windows 10.

version: '3.7'

services:
  redis:
    container_name: redis
    image: "redis:alpine"
    ports:
      - "6379:6379"
    volumes:
      - ./_DockerCompose/redis:/data #fails with docker desktop 2.2
      #- c:/temp/_DockerCompose/redis:/data #this (obviously?) works with docker desktop 2.2.0.0, was working with previous versions
    entrypoint: redis-server --appendonly yes

  p3x:
    container_name: redisui
    image: "patrikx3/p3x-redis-ui"
    ports:
      - "7843:7843"
    volumes:
      - ./_DockerCompose/p3x-redis-ui-settings:/settings #fails with docker desktop 2.2.0.0, was working with previous versions
      #- c:/temp/_DockerCompose/p3x-redis-ui-settings:/settings #this (obviously?) works with docker desktop 2.2
    depends_on:
      - redis

When switching the volume mounts to point to c:/temp the problem goes away, so yes something fundamental has changed or there is a junction issue?

[PetaPetaPeta]

Upgrading to Docker Desktop 2.2 resulted in the same error for me. I solved it by changing my relative paths in volumes to full paths.
./project1
to
c:/Users/docker/Documents/code/project1

[mat007]

The apparently similar error you’re seeing in 2.2.0.0 has a different root cause, the related ticket is #5516

[redec]

FYI I just installed 2.2 and encountered this same error when trying to run any container with a mounted volume. In my case it was because I had my host directory casing incorrect (c:\users\whatever instead of c:\Users\whatever). I'm just mentioning it in case it helps someone else in the same situation.

[eoussama]

Same here after the 2.2 update.

[lvkins]

I'm facing the same problem right now.

Been trying latest Docker Desktop for Windows as well as the Docker Desktop from edge channel.

My setup details:

OS Name:                   Microsoft Windows 10 Pro
OS Version:                10.0.18363 N/A Build 18363

> docker version
Client: Docker Engine - Community
 Version:           19.03.5
 API version:       1.40
 Go version:        go1.12.12
 Git commit:        633a0ea
 Built:             Wed Nov 13 07:22:37 2019
 OS/Arch:           windows/amd64
 Experimental:      true

Server: Docker Engine - Community
 Engine:
  Version:          19.03.5
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.12.12
  Git commit:       633a0ea
  Built:            Wed Nov 13 07:29:19 2019
  OS/Arch:          linux/amd64
  Experimental:     true
 containerd:
  Version:          v1.2.10
  GitCommit:        b34a5c8af56e510852c35414db4c1f4fa6172339
 runc:
  Version:          1.0.0-rc8+dev
  GitCommit:        3e425f80a8c931f88e6d94a8c831b9d5aa481657
 docker-init:
  Version:          0.18.0
  GitCommit:        fec3683

> docker-compose version
docker-compose version 1.25.1-rc1, build d92e9bee
docker-py version: 4.1.0
CPython version: 3.7.5
OpenSSL version: OpenSSL 1.1.1d  10 Sep 2019

When trying uncheck & check again shared drives in the Settings > Resources > File Sharing I'm being prompted to enter the user password all the time (I enter correct password). This happens only AFTER I face the mkdir /host_mnt/c: file exists error. When Docker is restarted I can (un)check shared drives successfully again, but as soon as the error comes by, it's failing (continuously prompts for password).

#edit

After several tries, restarts and running docker-compose up I get a new error from SSHD:

ERROR: for nginx Cannot start service nginx: error while creating mount source path '/host_mnt/c/Users/samm/Desktop/wordpress-nginx-docker/logs/nginx': mkdir /host_mnt/c/Users/samm/Desktop/wordpress-nginx-docker/logs: transport endpoint is not connected

To reproduce, simply clone and docker-compose this repo.

[CodeGTDLearn]

I had a lot of problems with volumes. I catalog some solutions about theses troubles. I hope taht thses solutions can help someone in this topic.

• Error 1: "Drive has not been shared":
  -Solution:

1. In cmd with powershell admin rights and enter the following commands:

net user /add DockerDiskSharing DockerDiskSharing
net localgroup Administrators DockerDiskSharing /add
net localgroup docker-users DockerDiskSharing /add
icacls "%UserProfile%" /q /c /t /grant docker-users:F

2. In Docker Daemon > Settings -> Shared Drives screen:
   • click Reset credentials > tick drive C > click Apply
   • type DockerDiskSharing in user name and DockerDiskSharing in password
   • click OK

• Error 2: "error while creating mount source path" or "drive has not been shared":
  -Solution:

1. Uncheck/remove the port(445), in the firewall rule. For example in kaspersky:
   
   
   
   

2. No Docker Daemon > Settings -> Shared Drives screen:
   • click Reset credentials > tick drive C > click Apply
   • type DockerDiskSharing in user name and DockerDiskSharing in password
   • click OK

• Error 03: “permission denied” in the docker-compose, dockerfile ou simple run
  -Solution:

1. Give FULL-PERMISSION for the HOST-FOLDER

I hope that these tips help someone

[dejanmr]

I can also confirm the issue, present after upgrade to 2.2.0.0 (42247),engine 19.03.5 on windows 10 Professional.
In my case issue is present because of symbolic links.
It was working fine for years, until now, I was always up-to-date with the latest update.
I need symbolic links it do avoid issues I have with folders with space in name, which I can't avoid due to some legacy software.

[kevingentile]

Docker Desktop 2.1.7.0 (41536) on Windows 10

The error I get is as follows:

ERROR: for container_alpine_1  Cannot start service alpine: error while creating mount source path '/host_mnt/c/Users/[...]/dist/alpine': mkdir /host_mnt/c/Users/[...]/dist/alpine: file exists

In docker-compose.yaml I have a mount:

volumes:
    - "./dist/alpine:/var/tmp/dist"

On the first run, the container creates the dist folder on my local machine. I hit the error when I delete the dist directory on my local machine and re-run the container.

I would expect docker to re-create dist again with docker-compose up.

To mitigate this issue I can restart Docker Desktop from the task bar, and the container executes as expected.

[cliffchapmanrbx]

After upgrading to 2.2 I'm also getting the same error message, this time with a docker-compose file. I'm using relative paths to locate a configuration file and mount it.

Original docker-compose.yaml that was working immediately prior to the update:

        volumes:
            - "./nats-server.conf:/etc/nats/nats-server.conf:ro"

"Fixed" configuration that is now working presently:

        volumes:
            - "C:/Git/nats-cluster/spout/nats-server.conf:/etc/nats/nats-server.conf:ro"

Observation: The "Git" folder is capitalized on my windows system. When I use the relative path, the error message has it lowercased:

error while creating mount source path '/host_mnt/c/git/nats-cluster/spout/nats-server.conf': mkdir /host_mnt/c/git: file exists

When I explicitly uppercase it in the configuration it's fine. Are relative paths broken because Docker is tolower()'ing something it shouldn't be?

[mj2015]

Okay, just been through this, and the last comment triggered my solution. I had
-v c:\data:/PersistentData
and it was failing with this mount error. Nothing special about my C:\Data folder at all. Hmm, tried
-v c:\Data:/PersistentData
and it works! Ouch! Hope this helps someone else.

[jsalvadorcaffarena]

Okay, just been through this, and the last comment triggered my solution. I had
-v c:\data:/PersistentData
and it was failing with this mount error. Nothing special about my C:\Data folder at all. Hmm, tried
-v c:\Data:/PersistentData
and it works! Ouch! Hope this helps someone else.

Just to add that this also helped in my case after getting these errors suddenly after upgrading Docker. There seems to have been a regression to case sensitive paths for Windows.

[cliffchapmanrbx]

Looks like the issue with version 2.2.0.0 is being tracked in #5516, we should probably not continue that discussion in this thread here.

[afilcheff]

After upgrading to 2.2 I'm also getting the same error message, this time with a docker-compose file. I'm using relative paths to locate a configuration file and mount it.

Original docker-compose.yaml that was working immediately prior to the update:

        volumes:
            - "./nats-server.conf:/etc/nats/nats-server.conf:ro"

"Fixed" configuration that is now working presently:

        volumes:
            - "C:/Git/nats-cluster/spout/nats-server.conf:/etc/nats/nats-server.conf:ro"

Observation: The "Git" folder is capitalized on my windows system. When I use the relative path, the error message has it lowercased:

error while creating mount source path '/host_mnt/c/git/nats-cluster/spout/nats-server.conf': mkdir /host_mnt/c/git: file exists

When I explicitly uppercase it in the configuration it's fine. Are relative paths broken because Docker is tolower()'ing something it shouldn't be?

Setting the path explicitly worked out for me, thanks

[eoussama]

Simply lowercasing every folder in my driver that matches the volume path seems to solve this for me. I hope a fix for this is introduced that doesn't force me to change anything.

[noobhacker]

I clone a project from Github using Visual Studio. The IDE automatically creates a directory under C:\Users\MyName\source\repo
However, for some reason, the docker is trying to mount to
C:\Users\MyName\Source\Repo
Rename source and repo to Source and Repo solved the problem.

[chopnut]

This is happening to me as well with the latest version.
Every time I load my wordpress docker-compose, it would mount 1 file from the wp container. And the container would stop, and when I restart docker-compose it will flag an error. About unable to mount.

This has never happened to me before.

[stephen-turner]

I think this ticket has accumulated more than one bug. As far as we know, the original issue (and most or all of the later issues) are fixed in 2.2.0.3, so I'm going to close this ticket. If there are further issues in the latest version, please open a new ticket. Thank you.

[ntnhan0612]

Login Docker again solved the issue. It worked for me !

[adamb70]

Restarting docker after deleting the container and volume worked for me.

[rustyx]

This is still happening randomly on latest Docker for Windows running on Windows 10 x64.

Simply un-sharing and re-sharing the C drive in Docker settings "fixes" the issue, without Docker restart.

So the underlying issue seems to still be there.

[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