Re-using a path that was previously mounted as a folders to mount a file does not work

[tomasaschan]

• I have tried with the latest version of my channel (Stable or Edge)

Expected behavior

If, using the WSL2 backend, I mount a directory at a local path, I can then at a later point mount a file from the same path.

Actual behavior

The container cannot start, because it gets confused about directory vs file mount. To reproduce:

$ mkdir /tmp/docker-repro && cd /tmp/docker-repro
/tmp/docker-repro$ mkdir foo
/tmp/docker-repro$ docker run --rm -v /tmp/docker-repro/foo:/foo ubuntu ls -la foo
total 8
drwxr-xr-x 2 1000 1000 4096 Dec 15 14:07 .
drwxr-xr-x 1 root root 4096 Dec 15 14:07 ..
/tmp/docker-repro$ rm -rf foo/
/tmp/docker-repro$ touch foo
/tmp/docker-repro$docker run --rm -v /tmp/docker-repro/foo:/foo ubuntu ls -la foo
docker: Error response from daemon: not a directory.
See 'docker run --help'.

It seems that this is because there is some stuff related to the bind mount left in /mnt/host/wsl/docker-desktop-bind-mounts, keyed by a hash of the path - which means after the first docker run command above, there is a folder at /mnt/host/wsl/docker-desktop-bind-mounts/Ubuntu-20.04/0d1e47568a672c2207104a286da74d16833178614f8ef6fa7021553d27e443a1 (assuming Ubuntu-20.04 is the WSL distro name), and docker run fails to mount this as a file, with the error message shown above.

[JokerQyou]

Thanks for the information! I've been hitting this issue for a few time today as I was tuning my docker-compose config. You know, when I wanted to mount a file like nginx.conf into a container, but forgot to actually create this file on the host side, docker simply creates it as a directory and bind-mount that directory instead. Later after I deleted the directory and replaced it with a regular file, docker gets confused and refuse to create the container.

In my case the leftover directory is located in /mnt/wsl/docker-desktop-bind-mounts/DIST_NAME/ in which DIST_NAME is the WSL distro name like Ubuntu-20.04. Do you happen to know the hash algorithm of the path? I want to manually delete the leftover directory to workaround this issue, but can't locate the exact hash.

Update:

The hash algorithm is SHA256. Removing the leftover directory did workaround this issue.

[docker-robott]

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

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

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

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

[ttutko]

/remove-lifecycle stale

[richardhendricks]

Issue is still present in Windows Docker Desktop 3.3.1.
While getting windows -> wsl1 -> wsl2 all sorted out, I tried my standard docker command without the correct path to my file .bash_aliases in the host filesystem.
Docker "kindly" produced a new directory for me.
When I fixed up my path issues, Docker refused to connect to the file

rihendri ~/dev/git/master-blaster/linux-shortcuts (master) $ docker run --user=buildengineer --rm -i -t --mount type=bind,source=$HOME/dev/git,target=/dev/git,consistency=cached --mount type=bind,source=/home/rihendri/dev/git/master-blaster/linux-shortcuts/.bash_aliases,target=/home/buildengineer/.bash_aliases rail-dev:latest
docker: Error response from daemon: not a directory.

I had to delete the SHA directory in docker-desktop-bind-mounts to get it recognize, per above.

rihendri /mnt/wsl/docker-desktop-bind-mounts/Ubuntu-20.04 $ sudo rmdir ac9c0412e6f10dba0c22c29eb2dc759b4aa2e094c9090e1ba928239edbc8aca4

rihendri ~ $ docker run --user=buildengineer --rm -i -t --mount type=bind,source=$HOME/dev/git,target=/dev/git,consistency=cached --mount type=bind,source=/home/rihendri/dev/git/master-blaster/linux-shortcuts/.bash_aliases,target=/home/buildengineer/.bash_aliases rail-dev:latest
buildengineer / $

[namedgraph]

What is the hash calculated from?

[namedgraph]

Wasted 2 hours on this crap! 😡

[tomasaschan]

@namedgraph

The hash is realpath $WSL_PATH_TO_FILE_OR_FOLDER | tr -d '\n' | sha256sum, e.g. after mounting /home/namedgraph/.config/gcloud from your distro Ubuntu-20.04 into a container, you'll have a folder at /mnt/wsl/docker-desktop-bind-mounts/Ubuntu-20.04/aac9fd9be5bafc1fc123c9d142dc9407ac844da6346b150db76dc757e8dd7ffa (because aac9fd9be5bafc1fc123c9d142dc9407ac844da6346b150db76dc757e8dd7ffa is the sha256 of /home/namedgraph/.config/gcloud)

[mahadi]

What was essential for me: My directory containing the file to be mounted was a symlinked directory (target on a windows drive in docker's mounted directory), so realpath yielded actually the correct path, but it seems docker expects another path.

Symlink: ~/workingdir/cfg/filetobe.mounted -> /e/some_path_on_a_windows_drive/filetobe.mounted

$ realpath ~/workingdir/cfg/filetobe.mounted
/e/some_path_on_a_windows_drive/filetobe.mounted

No corresponding hash for this path existed in /mnt/wsl/docker-desktop-bind-mounts/Ubuntu-18.04

Manually trying
$ echo "/home/myuser/workingdir/cfg/filetobe.mounted" | tr -d '\n' | sha256sum
returned the correct hash and saved my day.

[docker-robott]

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

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

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

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

[JokerQyou]

/remove-lifecycle stale

[marksteward]

Still getting this on 20.10.8 with the WSL2 backend. This fixed it:

$ sudo rmdir /mnt/wsl/docker-desktop-bind-mounts/$WSL_DISTRO_NAME/$(echo -n $(realpath "$PWD/file-that-refuses-to-mount")|sha256sum|cut -d\  -f1)

Can this perhaps be set not to go stale?

[firrae]

This needs a solution. I just spent hours trying to figure out why my NGINX config was failing until I found this issue that was my exact issue. I can't remove the folder as "it's currently in use" meaning I have to fully shut down Docker to even remove it. That's a pretty big pain.

[douglasparker]

This should probably be addressed soon...

[ArthurJam]

Hi,

A fix or a better message (maybe with a workaround) would be appreciated.

[Dacesilian]

Same problem is under Windows 11 / WSL Ubuntu 20.04.3 and Docker 4.3.1 (72247). Please, try to fix this. Thank you.

[jababda]

I think I've just had the problem as well.
Very new to docker to not sure how to diagnose it, but for me after most pc restarts I end up with a volume bind mount failing with a normal drive.

Looking at the location /mnt/wsl/docker-desktop-bind-mounts/$WSL_DISTRO_NAME I see

Is there anything that can be done to stop that folder turning into a file?

[KimCalvin]

This issue is almost 1.5 years old, is there any news on this?

[lemonied]

the same problem

[jeroen-fonky]

bump

[beavel]

+1 for a fix. Add my 2 hours of life to the list that have been wasted on this issue.

[athamidn]

please close docker desktop and all terminals , reopen docker desktop and run docker-compose up :| it worked for me.

[docker-robott]

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

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

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

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

[rossketron]

/remove-lifecycle stale

[docker-robott]

There hasn't been any activity on this issue for a long time.
If the problem is still relevant, mark the issue as fresh with a /remove-lifecycle stale comment.
If not, this issue will be closed in 30 days.

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

/lifecycle stale

[ArthurJam]

/remove-lifecycle stale

[prodkt]

/remove-lifecycle stale

[hoangtp165]

I have jump into the similar problem after update Docker Desktop.

After every time i started my docker containers -> close the terminal -> open a new terminal -> run wsl -> the working directory will become /mnt/wsl/docker-desktop-bind-mounts/Ubuntu-20.04/aaa30a8fc97875a015c84cccf7a05703d33c597c9ca4728540f9d42354fb65de

[khalilahmad0]

same problem. @hoangtp165 any luck?

[pr3l14t0r]

Maybe it helps someone. I had the same issue:

docker: Error response from daemon: error while creating mount source path '/run/desktop/mnt/host/wsl/docker-desktop-bind-mounts/Ubuntu/cb467e12876c1cc32cfb6e8646305b3bb9101e24116bf7529dab56dddc4f92f5': mkdir /run/desktop/mnt/host/wsl/docker-desktop-bind-mounts/Ubuntu/cb467e12876c1cc32cfb6e8646305b3bb9101e24116bf7529dab56dddc4f92f5: file exists.

When checking the bind mounts via ls i've noticed some paths where the permissions were unknown / set to ?

 ls -la /mnt/wsl/docker-desktop-bind-mounts/Ubuntu

srwxrwxrwx 1 pr3l14t0r users        0 Nov  1 13:18 1e3f10efd5b66e89511d4ace575ae6f00a11f07d7c405a94977aebc6893fa00c
drwxrwxrwx 1 pr3l14t0r pr3l14t0r 4096 Nov  1 17:36 3cdd9e653b4660ab91997340888700f2789b9f97440ad4433d4abbb938811d3e
-????????? ? ?         ?            ?            ? 44fc05c273fae58e9bedbfd57b270ea60f4b149c86f3b64f98360a6fc6b54625
drwxr-xr-x 4 pr3l14t0r pr3l14t0r 4096 Feb 23  2023 4ff0bba71df7b7a4b91e8f0c8decad797a60388c9055baab4721a58469b91f59
-rwxrwxrwx 1 pr3l14t0r pr3l14t0r  404 Nov  1 18:56 5d336b5ddc405b30a908dab76f5fb393e0e416cfb38a12c02d7b7c0cdf2d12c2
srw-rw---- 1 root      docker       0 Nov  1 17:38 71329c4cc6e32171553fa81d044eb31d1a3aac52ba9376c4a99f4505c494cf5b
-rwxrwxrwx 1 pr3l14t0r pr3l14t0r  688 Nov  1 17:45 865db8924075502eaec920f12e8a585dcab19b15437bf2b99d6c768c6585fd93
-????????? ? ?         ?            ?            ? cb467e12876c1cc32cfb6e8646305b3bb9101e24116bf7529dab56dddc4f92f5
drwxr-xr-x 2 root      root      4096 Nov  1 17:38 eee3fc5f280b7268a5b5a9980770488ffa2852f0b5b3ad4c2478e321fc99cb47

Here's what i have done to resolve it:

1. Kill all docker related process in an administrative powershell session:

get-process *docker* | Stop-Process -Force

2. Unmount and remove the paths in WSL shell:

sudo umount /mnt/wsl/docker-desktop-bind-mounts/Ubuntu/cb467e12876c1cc32cfb6e8646305b3bb9101e24116bf7529dab56dddc4f92f5
sudo rm -rf /mnt/wsl/docker-desktop-bind-mounts/Ubuntu/cb467e12876c1cc32cfb6e8646305b3bb9101e24116bf7529dab56dddc4f92f5
sudo umount /mnt/wsl/docker-desktop-bind-mounts/Ubuntu/44fc05c273fae58e9bedbfd57b270ea60f4b149c86f3b64f98360a6fc6b54625
sudo rm -rf /mnt/wsl/docker-desktop-bind-mounts/Ubuntu/44fc05c273fae58e9bedbfd57b270ea60f4b149c86f3b64f98360a6fc6b54625

3. Start Docker Desktop again on Windows, restart your WSL shell as well

4. Restart your container(s).

Everything should be back to normal. I don't know what causes this. Please Microsoft, fix!

[nag92]

I am having a similar problem, I am trying to create dev containers it creates some hashed file path and I cannot mount the workspace in vscode. Is there any fix yet? what is causing this issue?

[lutfiarahmanda]

same problem

[rgdigital]

So this seems to be a volume-mapping issue as per the above and comments like this, which I'm sure could be resolved via script somehow, but for a lack of traceable debug info.

FWIW I seemed to resolve this on WSL as a side-effect of installing Lando, then updating it to a new version via lando update. I guess it fixed whatever volume-mapping issues had occurred before the install by re-configuring something at Docker / WSL-level.

[eric900115]

same problem

[ArthurPatriot]

Same issue... Each time i get new path... When run wsl command... Any fix?

[PerryRylance]

Same issue on Windows 10, WSL 2, Ubuntu 20.

Manifests itself as Laravel Sail PHP files not synced correctly and PHP not able to find files which definitely do exist.

[stefanmohl]

I am having the same issue in Windows11, WSL2, with Docker version 24.0.7, build afdd53b, directly installed to my Ubuntu 22.04.4 LTS. Please note, I am running WSL2, but I am not running docker-desktop; I am running docker directly in my Ubuntu from apt-get.

I have a directory that I bind-mount to my docker container -v<local directory>:<container directory>. I run this container daily. The local directory is a mountpoint and needs to be mounted before it has correct contents.

Directly after reboot, if I run the container before I have mounted the local directory, it gets cached somewhere and even if I mount the correct content to the local directory (using local directory as a mount-point) later, the container still sees the old empty mountpoint. This does not happen if I mount the data first thing, before running the container.

[PerryRylance]

Resetting my Ubuntu via Windows and a restart fixed this for me on Win 10, WSL 2

[stefanmohl]

Yes, rebooting my Ubuntu works, but is less than ideal.

[marksteward]

Still getting this on 20.10.8 with the WSL2 backend. This fixed it:

$ sudo rmdir /mnt/wsl/docker-desktop-bind-mounts/$WSL_DISTRO_NAME/$(echo -n $(realpath "$PWD/file-that-refuses-to-mount")|sha256sum|cut -d\  -f1)

Can this perhaps be set not to go stale?

Got this again today, and to confirm, it still works but I needed to umount the directory first. I'm guessing that's more likely to upset Docker?