https://rancher.com/ logo
Join Slack
Powered by
Rancher Desktop (traditional Windows) bind-mounts:...
# rancher-desktop
e
Rancher Desktop (traditional Windows) bind-mounts: Hi, DDEV maintainer here. We have supported Rancher Desktop on macOS as a Docker provider for some years now, but from time to time I try to test it on traditional Windows (in git-bash or PowerShell) and it fails to mount any bind mounts, so fails. I assume this has to do with Lima settings, but internet searches have failed me. What do I need to do to get Rancher Desktop to do bind mounts (using docker compose) of subdirectories of home dir?
w
e
No, stumbled around on that for a while.
Currently, Rancher Desktop allows creating bind mounts only on the following directories by default: 
/Users/$USER
on macOS, 
/home/$USER
on Linux, and 
/tmp/rancher-desktop
on both. For Windows, all files are automatically shared via WSL2.
It says "automatically shared via WSL2" but that's not terribly helpful when talking about traditional Windows.
w
yup in the WSL distro. you would see /mnt/C
e
Right, but here I'm not running anything from WSL2 - although I know that Rancher Desktop uses it like Docker Desktop does (Rancher Desktop is not really very useful in WSL2 when docker-ce is so available and predictable)
w
no? RD uses WSL for its distro?
e
Yes, understood. But does that mean you can't use docker bind-mounts on traditional Windows?
w
no they work fine? it will redirect using the wsl file system stuff as noted in that page. what error are you getting?
e
I get an empty mounted dir inside the container. Trying to mount something from C:/.../homedir into container.
w
you may want to bind mount to something like /mnt/C/Temp as an example see if that helps
e
Well, this is standard DDEV docker-compose stuff. Has worked for years with Docker Desktop for Windows. Don't have any interest really in workarounds for Rancher. No workarounds are required on macOS.
This is the actual line in the compose volumes section:
Copy code
- .:/mnt/ddev_config:ro
compose config
transforms that to:
Copy code
- bind:
                create_host_path: true
              read_only: true
              source: /c/Users/randy/workspace/d11/.ddev
              target: /mnt/ddev_config
              type: bind
w
so that path wouldn't work in the VM itself.
you can do a 
rdctl shell
and look in the container host
e
Sounds like the answer is that traditional bind mounts in Windows just can't work?
(I'm not a WSL2 n00b. We recommend using WSL2 to every DDEV user on Windows, and discourage traditional Windows.)
w
i haven't used them in a bit, but never had issues myself
my gut says the issue is in the dot usage and the different shells at play and how they handle relative pathing. spinning up a windows machine to check it though
didn't toy with compose, but the path translation seemed to be working fine with a simple 
docker container run --rm -it -v .:/test alpine:latest cat /test/test.txt
command. so maybe the compose is munging things up with the relative path
e
dot doesn't actually get used here, because we do 
docker-compose config
on the file before using it, so it ends up being as shown above, https://rancher-users.slack.com/archives/C0200L1N1MM/p1749652791575849?thread_ts=1749651227.298549&cid=C0200L1N1MM
w
still don't think that source will work unless you tweak wslconfig to change your C drive mount point. you can jump into the distro and try it manually
e
Right. We're running on Windows, not in the distro. Trying to use the WIndows filesystem, not the WSL2 filesystem.
w
yeah but dockerd is in the container host. the rancher-desktop distro
so it needs to map from the distro so the path needs to be consistent there
e
Understood. But Windows users don't want to know anything about the distro.
p
I think we do the right thing for Windows-style paths (i.e. 
C:\Users\randy\workspace\d11\.ddev
), but 
/c/Users/…
smells like a *nix-style path and I don't think we handle that (roughly around https://github.com/rancher-sandbox/rancher-desktop/blob/f10bcec04e9ced15111cb67606[…]2e3/src/go/wsl-helper/pkg/dockerproxy/platform/serve_windows.go ). I'm not ruling out classifying that as a bug on our side, though? 🙂
f
Bind mounts do work for me, but the 
/c/users/suse
style does not:
Copy code
C:\Users\SUSE>echo "Hello world" >hello.txt

C:\Users\SUSE>docker run -it --rm -v .:/host alpine cat /host/hello.txt
"Hello world"

C:\Users\SUSE>docker run -it --rm -v c:/users/suse:/host alpine cat /host/hello.txt
"Hello world"

C:\Users\SUSE>docker run -it --rm -v /c/users/suse:/host alpine cat /host/hello.txt
cat: can't open '/host/hello.txt': No such file or directory
👍 1
e
I'll try further repro cases and simpler ones, but I think the /c/users rewrite is coming from 
docker-compose config
, and works with Docker Desktop, etc.
f
Yeah, but I've also seen instances via Google search where it was used with 
docker run -v
. But those examples may have been ancient, when it was docker-toolbox running with VirtualBox
Trying to figure out if this is some proxy component that does this
👍 1
https://github.com/docker/cli/blob/61c6818f/cli/compose/loader/loader.go#L492-L494 makes me suspicious that it may be a proprietary part of Docker for Windows
Copy code
// Note that this is not required for Docker for Windows when specifying
// a local Windows path, because Docker for Windows translates the Windows
// path into a valid path within the VM.
I'm giving up for now. I have not been able to find any path normalization code in 
docker/cli
, 
moby/moby
, or 
moby/buildkit
that would translate /c/data to c:\data. I suspect this is part of the proprietary code of Docker Desktop.
👍 1
e
The /c is what git-bash would use...
f
Yes, it is an MSYS thing. But I don't see how MSYS would be involved in processing the docker-compose file, or the -v arguments
e
Thanks for taking a look, I'll try for a simpler repro. I just always had assumed Rancher Desktop couldn't work on Windows with bind-mounts at all.
f
Please file a GitHub issue. Stuff on Slack easily gets lost. And since this is a free Slack instance, everything older than 3 months or so is inaccessible
👍 1
So it is good for chat, but not as a permanent record
w
Long shot but maybe if you switch root to / instead of the default /mnt maybe the path will start working. https://learn.microsoft.com/en-us/windows/wsl/wsl-config#automount-settings
e
👍 1
Open in Slack
PreviousNext
Powered by