Volumes mounted from a Linux WSL instance don't resolve in container #2151

jamesyale · 2018-06-25T17:06:28Z

I have tried with the latest version of my channel (Stable or Edge)
I have uploaded Diagnostics
Diagnostics ID: 71D6E138-AC1D-4851-B563-2929CF3EC790/2018-06-25_17-53-12

Expected behavior

When a valid path, within the Linux filesystem with WSL is specified and mounted into a docker container, the volume should be readable as if one were accessing it on the host system.

Actual behavior

Mounted volumes appear empty.

Information

Windows Version:
Docker for Windows Version:

Steps to reproduce the behavior

Install WSL
Launch WSL
Navigate to directory within the WSL Linux instance, eg, below /
Attempt to volume mount any directory / file into a container

The above behavior is demonstrated below:

jim@jimbook ~ $ uname -a
Linux jimbook 4.4.0-17134-Microsoft #112-Microsoft Thu Jun 07 22:57:00 PST 2018 x86_64 x86_64 x86_64 GNU/Linux
jim@jimbook ~ $ pwd
/home/jim
jim@jimbook ~ $ mkdir test
jim@jimbook ~ $ cd test
jim@jimbook ~ $ echo $PWD
/home/jim/test
jim@jimbook ~/test $ touch afile anotherfile
jim@jimbook ~/test $ ls
afile  anotherfile
jim@jimbook ~/test $ docker run -it -v $PWD:/tmp/test ubuntu:14.04 /bin/bash
root@12147d23d142:/# ls -la /tmp/test
total 4
drwxr-xr-x 2 root root   40 Jun 25 16:57 .
drwxrwxrwt 1 root root 4096 Jun 25 16:57 ..
root@12147d23d142:/# exit

Matching log entries:

[17:57:58.423][ApiProxy       ][Info   ] time="2018-06-25T17:57:58+01:00" msg="proxy << POST /v1.37/images/create?fromImage=ubuntu&tag=14.04\n"
[17:57:58.426][ApiProxy       ][Info   ] time="2018-06-25T17:57:58+01:00" msg="proxy >> POST /v1.37/containers/create [rewriteBinds]\n"
[17:57:58.427][ApiProxy       ][Info   ] time="2018-06-25T17:57:58+01:00" msg="Rewrote mount /home/jim/test:/tmp/test (volumeDriver=) to /home/jim/test:/tmp/test"
[17:57:58.427][ApiProxy       ][Info   ] time="2018-06-25T17:57:58+01:00" msg="proxy >> POST /v1.37/containers/create\n"
[17:57:58.427][ApiProxy       ][Info   ] time="2018-06-25T17:57:58+01:00" msg="Dial Hyper-V socket 4a0eb536-c64f-474b-ab2e-92eadcab5904:23a432c2-537a-4291-bcb5-d62504644739"
[17:57:58.428][ApiProxy       ][Info   ] time="2018-06-25T17:57:58+01:00" msg="Successfully dialed Hyper-V socket 4a0eb536-c64f-474b-ab2e-92eadcab5904:23a432c2-537a-4291-bcb5-d62504644739"
[17:57:58.589][ApiProxy       ][Info   ] time="2018-06-25T17:57:58+01:00" msg="proxy << POST /v1.37/containers/create\n"
[17:57:58.593][ApiProxy       ][Info   ] time="2018-06-25T17:57:58+01:00" msg="proxy >> POST /v1.37/containers/12147d23d142ce5aeb8d56fd17dc868eaac8ae9c7be7e31d17f46c82d1ad33c9/attach?stderr=1&stdin=1&stdout=1&stream=1\n"
[17:57:58.594][ApiProxy       ][Info   ] time="2018-06-25T17:57:58+01:00" msg="Dial Hyper-V socket 4a0eb536-c64f-474b-ab2e-92eadcab5904:23a432c2-537a-4291-bcb5-d62504644739"
[17:57:58.595][ApiProxy       ][Info   ] time="2018-06-25T17:57:58+01:00" msg="Successfully dialed Hyper-V socket 4a0eb536-c64f-474b-ab2e-92eadcab5904:23a432c2-537a-4291-bcb5-d62504644739"
[17:57:58.600][ApiProxy       ][Info   ] time="2018-06-25T17:57:58+01:00" msg="Upgrading to raw stream"
[17:57:58.602][ApiProxy       ][Info   ] time="2018-06-25T17:57:58+01:00" msg="proxy >> POST /v1.37/containers/12147d23d142ce5aeb8d56fd17dc868eaac8ae9c7be7e31d17f46c82d1ad33c9/wait?condition=next-exit\n"
[17:57:58.602][ApiProxy       ][Info   ] time="2018-06-25T17:57:58+01:00" msg="Dial Hyper-V socket 4a0eb536-c64f-474b-ab2e-92eadcab5904:23a432c2-537a-4291-bcb5-d62504644739"
[17:57:58.604][ApiProxy       ][Info   ] time="2018-06-25T17:57:58+01:00" msg="Successfully dialed Hyper-V socket 4a0eb536-c64f-474b-ab2e-92eadcab5904:23a432c2-537a-4291-bcb5-d62504644739"
[17:57:58.611][ApiProxy       ][Info   ] time="2018-06-25T17:57:58+01:00" msg="proxy >> POST /v1.37/containers/12147d23d142ce5aeb8d56fd17dc868eaac8ae9c7be7e31d17f46c82d1ad33c9/start [start]\n"
[17:57:58.611][ApiProxy       ][Info   ] time="2018-06-25T17:57:58+01:00" msg="proxy >> POST /v1.37/containers/12147d23d142ce5aeb8d56fd17dc868eaac8ae9c7be7e31d17f46c82d1ad33c9/start\n"
[17:57:58.611][ApiProxy       ][Info   ] time="2018-06-25T17:57:58+01:00" msg="Dial Hyper-V socket 4a0eb536-c64f-474b-ab2e-92eadcab5904:23a432c2-537a-4291-bcb5-d62504644739"
[17:57:58.613][ApiProxy       ][Info   ] time="2018-06-25T17:57:58+01:00" msg="Successfully dialed Hyper-V socket 4a0eb536-c64f-474b-ab2e-92eadcab5904:23a432c2-537a-4291-bcb5-d62504644739"

It looks like the path being passed up to Windows for the volume mount isn't valid on the host system and needs some kind of transformation - in Windows land, the correct path is something like: c:/Users/jim/AppData/Local/Packages/CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc/LocalState/rootfs/home/jim/test

The text was updated successfully, but these errors were encountered:

jamesyale · 2018-07-03T13:46:46Z

The work around here is to move your project to somewhere on the Windows file system and run the compose from there, where it works as expected, eg:

broken:

/home/jim/myproject > docker-compose up

working:

ln -s /mnt/c /c
cp -R /home/jim/myproject /c/Users/jim/myproject
cd /c/Users/jim/myproject
/c/Users/jim/myproject > docker-compose up

docker-robott · 2018-10-14T14:00:21Z

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale comment.
Stale issues will be closed after an additional 30d 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

jgoux · 2018-10-15T14:37:44Z

I'm hitting this issue too. I'd like to use docker-run with npx to bootstrap javascript projects.

When I use the -v option, nothing is written within WSL.

timhowes · 2018-10-15T22:50:03Z

There's no clear way to make this work. When you use docker within WSL, you're only running the docker client. The docker daemon is not running within WSL; it's running in a Hyper-V virtual machine, and that virtual machine accesses the Windows filesystem as a network share.

WSL can also access the Windows filesystem, so you can move your WSL folder to /mnt/c/ and then mount it with docker as -v /c/foldername or -v "C:\foldername". The docker container will be able to see the files. However, the unix-style permissions and file metadata will not be recognized.

Alternatively, open up the Hyper-V Manager and use the Quick Create menu to create an Ubuntu virtual machine. Then you can install both the docker daemon and client within the VM, and mounting volumes will work as expected.

jamesyale · 2018-10-16T09:54:40Z

Given that the VM running docker has access to the Windows FS, shouldn't it also be able to access the WSL filesystem that is within said Windows FS?

Could it be a case of mapping the Linux path onto the WSL root, eg: /home/jim/test -> c:/Users/jim/AppData/Local/Packages/CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc/LocalState/rootfs/home/jim/test and then attempting to mount?

timhowes · 2018-10-16T19:02:35Z

I don't think that's an intended way to interact with the files. It might work as a kludgy way to get read access to the files, but files you write there won't be recognized by WSL, and you'll still have the problem of not being able to read the unix-style permissions and ownership metadata.

If the WSL developers can provide some way to expose the WSL-internal filesystem to the Docker VM, that would get things working.

mikehenrty · 2018-11-28T00:00:59Z

Could it be a case of mapping the Linux path onto the WSL root, eg: /home/jim/test -> c:/Users/jim/AppData/Local/Packages/CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc/LocalState/rootfs/home/jim/test and then attempting to mount?

I don't think that's an intended way to interact with the files. It might work as a kludgy way to get read access to the files, but files you write there won't be recognized by WSL, and you'll still have the problem of not being able to read the unix-style permissions and ownership metadata.

Note I was able to get read/write working based on @jamesyale's suggestion, but my Docker Host was using a MobyLinuxVM filesystem (which I think is what most people are using), so the mapping was linux fs to linux fs. See the following Stack Exchange thread for more info:
https://superuser.com/a/1378927/967739

mikehenrty · 2018-11-28T00:40:09Z

/remove-lifecycle stale

timhowes · 2018-11-28T04:04:08Z

Your symlink will save you some typing, but it doesn't get around the problems I mentioned above. You are not mapping "linux fs to linux fs", you're accessing the Windows filesystem (NTFS) via Samba, inside the MobyLinuxVM. You can read the files in the AppData subfolder that way, but if you try to modify or create files, you're likely to run into problems as described here: https://blogs.msdn.microsoft.com/commandline/2016/11/17/do-not-change-linux-files-using-windows-apps-and-tools/

davispw · 2019-03-28T14:16:57Z

Workaround for files hosted on NTFS (not Linux native): mkdir -p /c; sudo mount --bind /mnt/c/ /c, then cd /c/your/project and run docker commands from there. The bind mount resolves some issues with symlinks.

gapkalov · 2019-05-04T02:35:15Z

how to use Docker with WSL
https://nickjanetakis.com/blog/setting-up-docker-for-windows-and-wsl-to-work-flawlessly

The last thing we need to do is set things up so that volume mounts work. This tripped me up for a while because check this out…

When using WSL, Docker for Windows expects you to supply your volume paths in a format that matches this: /c/Users/nick/dev/myapp.

But, WSL doesn’t work like that. Instead, it uses the /mnt/c/Users/nick/dev/myapp format. Honestly I think Docker should change their path to use /mnt/c because it’s more clear on what’s going on, but that’s a discussion for another time.

f0zi · 2019-06-10T16:29:20Z

Ok, so now that WSL has file sharing through Plan 9, can this be made to work?

Can Docker for Windows mount paths that start with \\wsl$\?

Could the client translate the paths to that namespace?

timhowes · 2019-06-10T16:54:19Z

It doesn't seem to work with network share paths (see #2163).

However, the upcoming WSL 2 looks like it will solve all these problems. You'll be able to fully run docker within WSL: https://devblogs.microsoft.com/commandline/announcing-wsl-2/

Zatte · 2019-07-24T08:22:11Z

Leaving this here for anyone in similar situation:
I'm using mkdir -p /c; sudo mount --bind /mnt/c/ /c which mostly works fine but I ran into an issue with all mounted folders always empty; Solved it by removing the c-share (from docker desktop settings) and adding it back in; restarting any affected containers.

coltenkrauter · 2019-09-19T18:32:00Z

This tutorial was helpful to me:
https://nickjanetakis.com/blog/setting-up-docker-for-windows-and-wsl-to-work-flawlessly

carlinmack · 2019-09-23T02:21:39Z

To get this working I did the following:

Upgrade to at least Windows 10 build 18917 by enrolling in Windows Insiders which allows WSL 2. I upgraded to 10.0.18985.1
You then need to upgrade Docker to version 2.1.2.0 (but not 2.1.3.0) and install Ubuntu 18.04 LTS to use WSL 2 Tech Preview. I had to uninstall Docker to do this.
If you are installing Ubuntu for the first time use this guide to get docker set up

rexhsu0624 · 2019-11-16T16:06:11Z

I guess that WSL 1 can not follow the Linux symbol link as /mnt/c/ to Windows FS C:\ path. So we have to define the docker volume parameter as below docker command in Linux.

docker run -d -v "C:\MyPath\MyDir":/data .....

I solve this and not upgrade to WSL 2 yet.

VladRez · 2019-12-01T22:54:42Z

I resolved a similar issue by unblocking 10.0.75.2 in my firewall settings.

For example,
docker run -it --rm --user "$(id -u):$(id -g)" -v "$PWD":/usr/src/app -w /usr/src/app ubuntu

WSL would not resolve files in a volume mounted directory and creating new files would not reflect in the host. In addition, if I re-run the same command the files I created the first time would still be in the running container but not in the host, weird.

There's no clear way to make this work. When you use docker within WSL, you're onl

Adding to @timhowes, since the files are shared via network I checked my firewall and noticed 10.0.75.2 was being blocked and unblocking resolved the issue.

Triple-Z · 2019-12-06T01:49:18Z

I have this issue too, and I use docker from PowerShell instead.

gotpredictions · 2020-01-05T03:48:56Z

I am having the issue with WSL. Mount is not complaining, but it is empty, so it is basically useless.

brad-natelborg · 2020-01-15T13:24:00Z

For what's it worth, the article here describes a solution that has worked great for me. Note that after creating a config file, your path will change from /mnt/c/... to /c/...

This has worked great for me for 6+ months.

flickerfly · 2020-01-30T17:59:45Z

@brad-natelborg Simply changing WSL to mount to /c instead of /mnt/c hasn't allowed me to mount something in my WSL home directory at this point. It just mounts nothing to the location in the container while inspect reports the mount is in place.

realchrisolin · 2020-02-11T21:31:49Z

Ran into this issue recently, came up with a more straightforward workaround for mounting my Windows home directory (which I have symlinked to my C:\Users directory) in Docker. I haven't tried it, but readlink -f ./ looks like it will work for mounting the current working directory.

docker run -v $(wslpath -w `readlink ~`):/path/on/container ...

jacarrico · 2020-02-12T18:00:52Z

I guess that WSL 1 can not follow the Linux symbol link as /mnt/c/ to Windows FS C:\ path. So we have to define the docker volume parameter as below docker command in Linux.

docker run -d -v "C:\MyPath\MyDir":/data .....

I solve this and not upgrade to WSL 2 yet.

This was effectively what worked for me!

f0zi · 2020-02-15T18:37:42Z

Hi all, thanks for all the workarounds but IMHO this is not something we should be solving in a workaround, it should simply work by default to ensure cross platform consistency.

I don't know about you guys but I'm running WSL not because I like to unix while I Windows, but because I'm trying to run something that was written for unix by some unix guy/gal. The whole point is that is should just work the same on both a "real" unix and WSL.

Therefore I think this should be fixed in either the docker client or the docker server. Quite possibly in the unix docker client, with some special case handling for WSL. Wherever it makes sense, as long as the same command that works on unix also works in WSL. It's ok to share the C drive in the Docker for Windows settings, although I would prefer if I could share the WSL sandbox instead. But after that it should Just Work™.

tanyanghan · 2020-06-06T10:08:34Z

Anyone stumbling here over this issue follow this: Docker Desktop WSL2 Backend and make sure you are running the version 2 of the WSL in PowerShell:

> wsl -l -v
  NAME                   STATE           VERSION
* docker-desktop         Running         2
  Ubuntu                 Running         2
  docker-desktop-data    Running         2

If your Ubuntu VERSION doesn't say 2, you need to update it according to the guide above.

After that, you will be able to mount your Linux directory to the Docker Container directly like:
docker run -v ~/my-project:/sources <my-image>

f0zi · 2020-06-06T15:55:49Z

Can confirm, with WSL2 back-end and WSL integration enabled for the distro in Docker it now works as it should without any hacks or workarounds. 👍 🎉

crwgregory · 2020-07-12T01:47:16Z

Seems to also be working with Tensorflow set up:

Docker version 19.03.12, build 48a66213fe

C:\ > wsl --list -v
  NAME      STATE           VERSION
* Ubuntu    Running         2

Windows Version 2004 (OS Build 20161.1000)

build:
	@docker build -t image-rec .

run: build;
	@docker run -v /home/cg/dev/image-recognition:/developer -it image-rec

Spenhouet · 2020-07-22T09:18:10Z

With Windows 10 build 19041 and WSL 2 from a windows terminal (cmd / powershell):

🔴 Doesn't work (successful mount but directory is empty):

docker run -v /mnt/c/Users/Sebastian/Documents:/workspace ...
docker run -v /Users/Sebastian/Documents:/workspace ...
docker run -v ~/Documents:/workspace ...
docker run -v /home/spe/Documents:/workspace ...

🔴 Doesn't work (docker exception):

docker run -v "C:/Users/Sebastian/Documents":/workspace ... -> invalid reference format.

🟢 Works:

docker run -v "C:/Users/Sebastian/Documents:/workspace" ...
docker run -v /c/Users/Sebastian/Documents:/workspace ...

🟢 From within a WSL 2 distribution, the following works:

docker run -v /mnt/c/Users/Sebastian/Documents/:/workspace ...

For testing I used -it nvcr.io/nvidia/cuda:10.2-cudnn8-runtime-ubuntu18.04 instead of ... above.

I had a lot of confusion here. I hope the examples above help someone to waste less time.

OctavioBR · 2020-08-16T22:58:30Z

I don't understand why in Docker Desktop for Windows we should use volumes only from /mnt/c.

From docker blog:

Awesome mounts performance
Both your own WSL 2 distro and docker-desktop run on the same utility VM. They share the same Kernel, VFS cache etc. They just run in separate namespaces so that they have the illusion of running totally independently. Docker Desktop leverages that to handle bind mounts from a WSL 2 distro without involving any remote file sharing system. This means that when you mount your project files in a container (with docker run -v ~/my-project:/sources <...>), docker will propagate inotify events and share the same cache as your own distro to avoid reading file content from disk repeatedly.
A little warning though: if you mount files that live in the Windows file system (such as with docker run -v /mnt/c/Users/Simon/windows-project:/sources <...>), you won’t get those performance benefits, as /mnt/c is actually a mountpoint exposing Windows files through a Plan9 file share.

Also described as Best practices in docker desktop docs:

Store source code and other data that is bind-mounted into Linux containers (i.e., with docker run -v <host-path>:<container-path>) in the Linux filesystem, rather than the Windows filesystem.

Performance is much higher when files are bind-mounted from the Linux filesystem, rather than remoted from the Windows host. Therefore avoid docker run -v /mnt/c/users:/users (where /mnt/c is mounted from Windows).

TBG-FR · 2020-08-17T12:21:07Z

I don't understand why in Docker Desktop for Windows we should use volumes only from /mnt/c.

From docker blog:

Awesome mounts performance
Both your own WSL 2 distro and docker-desktop run on the same utility VM. They share the same Kernel, VFS cache etc. They just run in separate namespaces so that they have the illusion of running totally independently. Docker Desktop leverages that to handle bind mounts from a WSL 2 distro without involving any remote file sharing system. This means that when you mount your project files in a container (with docker run -v ~/my-project:/sources <...>), docker will propagate inotify events and share the same cache as your own distro to avoid reading file content from disk repeatedly.
A little warning though: if you mount files that live in the Windows file system (such as with docker run -v /mnt/c/Users/Simon/windows-project:/sources <...>), you won’t get those performance benefits, as /mnt/c is actually a mountpoint exposing Windows files through a Plan9 file share.

Also described as Best practices in docker desktop docs:

Store source code and other data that is bind-mounted into Linux containers (i.e., with docker run -v <host-path>:<container-path>) in the Linux filesystem, rather than the Windows filesystem.

Performance is much higher when files are bind-mounted from the Linux filesystem, rather than remoted from the Windows host. Therefore avoid docker run -v /mnt/c/users:/users (where /mnt/c is mounted from Windows).

This documentation is for Docker with WSL 2, and the issue addressed here is for Docker with WSL 1.
If you can, I highly suggest you to update windows to use WSL 2, it's more convenient, powerful and you'll have less issues like this one (I've tried both, on separate computers, and I can't wait to upgrade the WSL 1 one, because the struggle with this is real...)

OctavioBR · 2020-08-17T20:12:13Z

I've stumbled here because it happened to me in WSL2. But my issue was due to the Alpine distro, which doesn't have integration enabled to work with the docker-desktop instance. After switching to Ubuntu 20.04, it works like a charm! It even provides docker CLI tools from /mnt/wsl/docker-desktop/cli-tools/usr/local/bin/ 👌

pauloricardomg · 2020-11-04T11:29:47Z

I'm also facing this issue. It's fixed when downgrading docker to work with WSL1.

mirchat · 2020-11-20T07:15:37Z

I have the same issue with WSL2 and Ubuntu20

mircea@DESKTOP-3HUUSU8:~ $ uname -a
Linux DESKTOP-3HUUSU8 4.19.128-microsoft-standard #1 SMP Tue Jun 23 12:58:10 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
mircea@DESKTOP-3HUUSU8:~ $ pwd
/home/mircea
mircea@DESKTOP-3HUUSU8:~ $ mkdir test
mircea@DESKTOP-3HUUSU8:~ $ cd test/
mircea@DESKTOP-3HUUSU8:~ /test $ echo $PWD
/home/mircea/test
mircea@DESKTOP-3HUUSU8:~ /test $ touch file1 file2
mircea@DESKTOP-3HUUSU8:~ /test $ ll
total 8
drwxr-xr-x 2 mircea mircea 4096 Nov 20 08:05 ./
drwxr-xr-x 10 mircea mircea 4096 Nov 20 08:05 ../
-rw-r--r-- 1 mircea mircea 0 Nov 20 08:05 file1
-rw-r--r-- 1 mircea mircea 0 Nov 20 08:05 file2
mircea@DESKTOP-3HUUSU8:~/test $ docker run -it -v $PWD:/tmp/test busybox sh
/ # ls -al /tmp/test/
total 4
drwxr-xr-x 2 root root 40 Nov 20 07:07 .
drwxrwxrwt 1 root root 4096 Nov 20 07:09 ..
/ #

It works fine if I use the Windows file system, but it is VERY slow. Also confirmed by Windows:
https://docs.microsoft.com/en-us/windows/wsl/compare-versions#performance-across-os-file-systems

For me this problem is a STOPPER for using WSL2.
Any ideas please?

TBG-FR · 2020-11-23T08:43:01Z

I have the same issue with WSL2 and Ubuntu20

[...]

It works fine if I use the Windows file system, but it is VERY slow. Also confirmed by Windows:
https://docs.microsoft.com/en-us/windows/wsl/compare-versions#performance-across-os-file-systems

For me this problem is a STOPPER for using WSL2.
Any ideas please?

Which version of Docker Desktop are you using ?

mirchat · 2020-11-23T18:13:30Z

I have the same issue with WSL2 and Ubuntu20
[...]
It works fine if I use the Windows file system, but it is VERY slow. Also confirmed by Windows:
https://docs.microsoft.com/en-us/windows/wsl/compare-versions#performance-across-os-file-systems
For me this problem is a STOPPER for using WSL2.
Any ideas please?

Which version of Docker Desktop are you using ?

I use 2.5.0.1 (49550)

YouveGotMeowxy · 2020-11-24T03:09:20Z

I'm not 100% sure it's the same issue but, for the life of me I CAN NOT get a container to see the files inside a mounted directory when the directory is bound to a shared network path.

Specifically:

I have 2 LAN machines; both Win 10, 1 is running WSL2 + Docker Desktop (latest edge) (let's call the latter machine "machine 2").
I share to the network a local path to a music folder on machine 1.
I mount that network share to a directory from within Ubuntu 20.04 on machine 2 (I've tried both drvfs and cifs).
From within machine 2, when I ls that mounted directory I CAN see all the files from the network share (let's say it's at /mnt/winshares/music).
However, when I mount that same directory to a container, i.e. -v /mnt/winshares/music:/music and then ls the /music directory from within the container, it's empty?

Rican7 · 2020-12-06T23:50:28Z

For anyone else that's running into this issue on WSL 1 (and doesn't yet want to upgrade to WSL 2, for reasons such as microsoft/WSL#4197), you can get around this by using the wslpath tool that's included with WSL distros.

Example:

docker run -v "$(wslpath -w "$(pwd)")":/home/docker ...

lorengordon · 2021-02-18T15:39:47Z

@Rican7 That looks promising! Do you happen to have any more info on how you got it working? I keep getting an error:

$ docker run -v "$(wslpath -w "$(pwd)")":/home/docker python:3 ls -al /home/docker
docker: Error response from daemon: \\wsl$\Ubuntu\tmp%!(EXTRA string=is not a valid Windows path).

EDIT: The path does work if I browse to it on the windows side...

ionut-arm · 2021-02-18T15:46:04Z

This answer helped me get past that error, but now I'm back to having an empty folder mounted :[

lorengordon · 2021-02-18T15:56:27Z

@ionut-arm Same. If I reverse the slashes, then the bindmount is empty:

$ docker run -v //wsl$/Ubuntu/tmp:/home/docker python:3 ls -al /home/docker
total 4
drwxr-xr-x 2 root root   40 Feb 18 15:55 .
drwxr-xr-x 1 root root 4096 Feb 18 15:55 ..

fpsColton · 2021-05-02T08:47:28Z

This post helped me get passed this.

The mount points with WSL are in /run/desktop/mnt/host/ so to mount d:/s/elasticsearch use

docker run --rm -v /run/desktop/mnt/host/d/s/elasticsearch:/mnt alpine ls /mnt

Source: https://forums.docker.com/t/how-do-you-create-a-bind-mount-in-docker-when-running-with-the-wsl2-backend/94097/2

YouveGotMeowxy · 2021-05-05T02:20:44Z

This post helped me get passed this.

The mount points with WSL are in /run/desktop/mnt/host/ so to mount d:/s/elasticsearch use

docker run --rm -v /run/desktop/mnt/host/d/s/elasticsearch:/mnt alpine ls /mnt

Source: https://forums.docker.com/t/how-do-you-create-a-bind-mount-in-docker-when-running-with-the-wsl2-backend/94097/2

I have no /run/desktop/ in any of my WSL OS's (the default, or the installed ubuntu).

centur · 2021-05-10T06:33:46Z

I have no /run/desktop/ in any of my WSL OS's (the default, or the installed ubuntu).

@YouveGotMeowxy check if youre default mount path is something like /mnt
easiest way is to cat /etc/wsl.conf and see what path is used in [automount] section

error0g · 2022-03-08T07:10:13Z

try docker -v /var:{path} exe

Jamie0 · 2022-07-13T23:45:46Z

Several cans of energy drink later, I've found a (hacky) solution to mount any WSL2 DRVFS string inside Docker containers!

In PowerShell:

wsl -d docker-desktop -- bash -c 'mkdir -p /mnt/share && nsenter -t `pidof rpcbind` -n mount.drvfs "S:" /mnt/share'

You can then specify volumes as -v /run/desktop/mnt/share:/mnt/share

docker-robott added the version/18.03.1-ce-win65 label Jun 25, 2018

docker-robott added the lifecycle/stale label Oct 14, 2018

docker-robott removed the lifecycle/stale label Nov 28, 2018

matthewbloch mentioned this issue Apr 5, 2019

Mounted volumes are empty in the container. #25

Closed

stefangordon mentioned this issue Sep 4, 2019

cask - wsl support cloud-custodian/cloud-custodian#4727

Open

dgkanatsios mentioned this issue Oct 5, 2019

[Question] Running a utility that uses gopsutil inside a container shirou/gopsutil#774

Closed

devkanro mentioned this issue Jan 4, 2020

Add kotlin coroutine plugin apache/skywalking#4165

Merged

5 tasks

docker-robott added the lifecycle/frozen label Jan 30, 2020

Kadynm49 mentioned this issue Aug 19, 2020

Docker images - Cannot open /data/livegrep.idx: No such file or directory livegrep/livegrep#275

Closed

NickVeld mentioned this issue May 9, 2021

docker resolves path of mapped network drive incorrectly #11151

Open

3 tasks

alanbueno mentioned this issue Sep 28, 2021

"not a directory: unknown: Are you trying to mount a directory onto a file" error produced when mounting a single file on a container docker-archive/compose-cli#1795

Closed

3 tasks

bsekachev mentioned this issue Nov 2, 2022

Automatic annotation using yolov3 gives error cvat-ai/cvat#5205

Closed

Volumes mounted from a Linux WSL instance don't resolve in container #2151

Volumes mounted from a Linux WSL instance don't resolve in container #2151

Comments

jamesyale commented Jun 25, 2018 • edited Loading

Expected behavior

Actual behavior

Information

Steps to reproduce the behavior

jamesyale commented Jul 3, 2018 • edited Loading

docker-robott commented Oct 14, 2018

jgoux commented Oct 15, 2018

timhowes commented Oct 15, 2018

jamesyale commented Oct 16, 2018 • edited Loading

timhowes commented Oct 16, 2018

mikehenrty commented Nov 28, 2018

mikehenrty commented Nov 28, 2018

timhowes commented Nov 28, 2018

davispw commented Mar 28, 2019

gapkalov commented May 4, 2019

f0zi commented Jun 10, 2019

timhowes commented Jun 10, 2019

Zatte commented Jul 24, 2019

coltenkrauter commented Sep 19, 2019

carlinmack commented Sep 23, 2019

rexhsu0624 commented Nov 16, 2019 • edited Loading

VladRez commented Dec 1, 2019

Triple-Z commented Dec 6, 2019

gotpredictions commented Jan 5, 2020

brad-natelborg commented Jan 15, 2020

flickerfly commented Jan 30, 2020

realchrisolin commented Feb 11, 2020 • edited Loading

jacarrico commented Feb 12, 2020

f0zi commented Feb 15, 2020

tanyanghan commented Jun 6, 2020

f0zi commented Jun 6, 2020

crwgregory commented Jul 12, 2020

Spenhouet commented Jul 22, 2020 • edited Loading

OctavioBR commented Aug 16, 2020 • edited Loading

TBG-FR commented Aug 17, 2020

OctavioBR commented Aug 17, 2020

pauloricardomg commented Nov 4, 2020

mirchat commented Nov 20, 2020 • edited Loading

TBG-FR commented Nov 23, 2020

mirchat commented Nov 23, 2020

YouveGotMeowxy commented Nov 24, 2020

Rican7 commented Dec 6, 2020

lorengordon commented Feb 18, 2021 • edited Loading

ionut-arm commented Feb 18, 2021

lorengordon commented Feb 18, 2021

fpsColton commented May 2, 2021

YouveGotMeowxy commented May 5, 2021

centur commented May 10, 2021 • edited Loading

error0g commented Mar 8, 2022

Jamie0 commented Jul 13, 2022

jamesyale commented Jun 25, 2018 •

edited

Loading

jamesyale commented Jul 3, 2018 •

edited

Loading

jamesyale commented Oct 16, 2018 •

edited

Loading

rexhsu0624 commented Nov 16, 2019 •

edited

Loading

realchrisolin commented Feb 11, 2020 •

edited

Loading

Spenhouet commented Jul 22, 2020 •

edited

Loading

OctavioBR commented Aug 16, 2020 •

edited

Loading

mirchat commented Nov 20, 2020 •

edited

Loading

lorengordon commented Feb 18, 2021 •

edited

Loading

centur commented May 10, 2021 •

edited

Loading