This message was deleted.

I have to admit I'm confused about this as well. I don't have a mac, so I poked around on my Linux machine and came to the same result: UID and GID are passed through to the container. An important thing to keep in mind when working with mounts is that Rancher Desktop runs docker inside a VM, so any directories you want to mount in a container must first be mounted in a VM. Only then can they be mounted in a container from the VM. I'm not sure this is unexpected behavior though - see the following links: https://stackoverflow.com/questions/64106038/docker-bind-mount-permissions-unexpected-mounting-as-rootroot https://stackoverflow.com/questions/30140911/can-i-control-the-owner-of-a-bind-mounted-volume-in-a-docker-image This indicates that it is expected that a directory mounted in a container should have the same ownership as that directory on the host. If that is true, it is Docker Desktop that is showing unexpected behavior. The question is: what are you trying to do? Are you trying to spin up a container to use as a throwaway development environment? If so, you might find that other tools are better suited than vanilla docker. Some examples might be

toolbx

or

distrobox

(I'm not sure if those work for macOS, but I'm sure there are alternatives. Maybe the

-u

argument to

docker run

would be useful to you?

Thanks for the confirmation. I agree that Docker Desktop seems off to automatically mount the volume to the target user in the case of a bind mount - at least I can’t find docs indicating that that should be expected. My use case is mounting my ssh creds into a custom container to be able to use ansible orchestration to interact with a remote git repo over ssh as part of the management of a cloud instance. My tools need to be hardened, so not expecting toolbx or distrobox to pass that test, but haven’t ran vulnerability scans on them. We’re semi-locked into the current path for now either way.

docker run -u

didn’t seem to affect the mounts, just the user I run the container as. And kinda went down the path of

setfacl

that several posts mentioned, but wasn’t getting anywhere with the time I could give it. Maybe a possible solution is to copy the directories/files I want to mount to the

/tmp/rancher-desktop

directory which appears to be mounted to the VM rancher is running, but assign ownership/permissions in that directory based on the target container uid/gid.

That sounds like it could work. I'm sure there are lots of ways to make it work... best of luck and let me know if you have any other questions 😄