Bind-mounted volume has owner:group set as root when running container as non-root user

[xEtherealx]

Note that this is a copy of #5480 (comment) which is much more well-formatted but closed due to inactivity. I experienced the same exact issue in Docker Desktop 4.16.2 (95914) with gRPC FUSE and switching to osxfs resolved the issue immediately.

Expected behavior
Running a docker image as a non-root user and bind-mounting a directory in the container at run time should should have the bind-mounted directory in the container's permissions set as the owner and group of the user specified in the Dockerfile image.

Actual behavior
Running a docker image as a non-root user and bind-mounting a directory in the container at run time should should have the bind-mounted directory in the container's permissions set as the owner and group of root until the bind-mounted directory has some sort of action happen within the container. See steps 5, 6, and 7 below.

Information
This problem is reproducible, though I'm not sure if it's a new problem. I also made a post here: moby/moby#3124 (comment) and was directed to post on this project instead.

I've tested the following on:

macOS Version: BigSur v11.2.2
Docker Desktop Version: v3.2.2
Engine v20.10.5
AND:

Windows 10 Version: 20H2 build 19042.867
Docker Desktop Version: v3.2.2
Engine v20.10.5
WSL 2 (Ubuntu 20.04)
Steps to reproduce the behavior
For a very simple test, let's say there is a configuration directory on my host user's home directory that I want a running container to be able to modify. Let's call this directory ~/.myconf.

If you're testing this yourself, make this directory in your user profile with mkdir ~/.myconf.

Create a Dockerfile somewhere that looks like this (here is a simple Dockerfile to add and use a non-root user):

FROM alpine:latest

RUN addgroup -S appuser && adduser -S appuser -G appuser

USER appuser
WORKDIR /home/appuser
Okay, let's build this image:
docker build -f Dockerfile -t app .
Now, let's run the image interactively, bind mounting the ~/.myconf directory on the host machine to the /home/appuser/.myconf in the container:
docker run -it -v "$HOME/.myconf":/home/appuser/.myconf app /bin/sh
In the container run:
ls -al
Notice how it shows that the bind mounted directory /home/appuser/.myconf is owned by root. The group is also set as root:

~ $ ls -al
total 16
drwxr-sr-x 1 appuser appuser 4096 Mar 19 13:50 .
drwxr-xr-x 1 root root 4096 Mar 19 13:47 ..
-rw------- 1 appuser appuser 7 Mar 19 13:50 .ash_history
drwxr-xr-x 5 root root 160 Mar 17 13:50 .myconf
Now, and here's where it gets weird, run:
ls -al /home/appuser/.myconf > /dev/null
This actually CHANGES the owner and group to be the correct user and group who should have access to the /home/appuser/.myconf directory.

Here is the result of ls -al again after running the previous command:
~ $ ls -al
total 16
drwxr-sr-x 1 appuser appuser 4096 Mar 19 13:50 .
drwxr-xr-x 1 root root 4096 Mar 19 13:47 ..
-rw------- 1 appuser appuser 53 Mar 19 13:52 .ash_history
drwxr-xr-x 5 appuser appuser 160 Mar 17 13:50 .myconf
~ $

[terencehonles]

At least two of my colleagues on Macs are reporting this issue (both ARM & Intel Macs). Since we're mounting a directory and using ls to check the ownership I would think the ownership would be "fixed", but I don't think we tried to ls twice so I'm not sure if the ownership changed the second time like is suggested fixes this in the original report.

[tloobyCFS]

I am experiencing this on Ubuntu Linux 22.04 LTS using Docker Desktop (also tried manually running docker daemon) with Docker version 23. When I do not bind mount the directory, it appears in the container as user:user but when I bind mount, it appears as root:root. On the host OS the UID/GID are exactly the same as the UID/GID in the container, and the directory ownership on the host os are UID:GID. This is a bug.

[default-value-serhiia]

The same issue.
I added the user: %user_id%:%group_id% service property to the docker-compose (where %user_id% and %group_id% are my user ids).
Then I bind mount the path where my user is the owner of the directory and files/subdirectories.
But I cannot do anything when I connect to the container.
All bind-mounted files have an owner with id 0:0 (root).

[yundddd]

same here. switching to VirtioFS resolved it.

[rittneje]

I'm seeing the same bug with VirtioFS with 4.25.1. There seems to be a race condition because sometimes the volume mounts correctly and sometimes it mounts as root. And sometimes it originally mounts as root but randomly fixes itself some time later. Switching to osxfx seemingly resolves it.

[artm]

I am experiencing this on Ubuntu Linux 22.04 LTS using Docker Desktop (also tried manually running docker daemon) with Docker version 23. When I do not bind mount the directory, it appears in the container as user:user but when I bind mount, it appears as root:root. On the host OS the UID/GID are exactly the same as the UID/GID in the container, and the directory ownership on the host os are UID:GID. This is a bug.

This is due to the way Docker Desktop for Linux shares files with the host:

Docker Desktop maps the current user ID and GID to 0 in the containers.

This remapping is based on Linux namespaces which if I understand it correctly is meant for containers that run as root, which isn't the case with standard dev containers. There is a way to disable namespace remapping for a particular container but this has side effects on the files inside the container layers.

I think Docker Desktop for Linux is just not useful for dev containers, plain docker engine should work better.

[artm]

And just as I sent that I had a change of heart. The reason Docker Desktop for Linux acts this way is to make containers that run as root harmless. And it is easy to make dev containers run as root. But this is unhandy for teams where different developers use different flavors of docker.

[tknerr]

I have the same issue (i.e. volume is mounted as root:root) with 4.29.0 on macOS 14.4.1 (apple silicon), both for VirtioFS and gRPC FUSE, but only when running under a service (azure devops agent service, in my case). When being logged in directly (with the same regular user account), the volumes get mounted with the correct file/group ownership.

Workaround: switching to osxfuse (legacy) fixes it and the volume gets mounted with correct file/group ownership of the regular user (now also when running under the azure devops agent service).

[mserajnik]

I have the same issue when using virtiofs with Docker Desktop 4.29.0 on macOS 14.4.1 (MacBook Air M1); bind mounts are owned by root inside the container. Switching to osxfs fixes the issue.

[jillesca]

thanks default-value-serhiia your workaround helped me user: 1000:100 in my compose file, where 1000 is my user id and 100 my user group.

Experiencing the same issue on MacBook Pro M2 (14.5 (23F79)) with Docker version 26.1.1, build 4cf5afa