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

[noahjahn]

• I have tried with the latest version of Docker Desktop
• I have tried disabling enabled experimental features
• I have uploaded Diagnostics
• Diagnostics ID: 5C4B7958-B047-4869-8386-358281ABB1F5/20210319155312

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.

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

2. 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

3. Okay, let's build this image:

docker build -f Dockerfile -t app .

4. 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

5. 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

6. 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.

7. 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
~ $ 

[devantoine]

I'm facing the exact same issue.

I don't know why the bind mounted volume is owned by root:root and then after doing an ls of this directory the ownership is set to the user and group it's supposed to be.

[Aposhian]

I don't think this is completely specific to docker for mac. Also getting this on Docker 20.10.7 on Linux, although I don't get the weird error with the ownership fixing itself. It just stays broken.

[noahjahn]

I don't think this is completely specific to docker for mac. Also getting this on Docker 20.10.7 on Linux, although I don't get the weird error with the ownership fixing itself. It just stays broken.

I agree, in fact I noted that this also happens on Windows with WSL.

I was directed to make the post here. A link to my original comment is here moby/moby#3124 (comment)

[namedgraph]

Experiencing the same issue with Docker Desktop (Docker Engine v20.10.8) and WSL2 (Ubuntu filesystem) on Windows 10.

Dockerfile does chown -R fuseki ${FUSEKI_DIR}.

When I login into the container without mounting the folder, the owner of ${FUSEKI_DIR} is fuseki.

When I mount ${FUSEKI_DIR} to host, I see the owner of ${FUSEKI_DIR} is root, which messes up privileges in the container running with the fuseki user.

Moreover my WSL2 Linux user that I run docker-compose from is not root either.

[korridor]

We faced the same issue with Docker for Mac 4.0.1 (Engine 20.10.8) and for us deactivating "Use gRPC FUSE for file sharing" fixed the problem.

I also tried exactly the same steps as @noahjahn and had similar results. Only the steps 6 and 7 did not work.
With gRPC FUSE deactivated the owner of the file was appuser and with gRPC FUSE activated the user was root.

[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

[noahjahn]

/remove-lifecycle stale

[docker-robott]

Closed issues are locked after 30 days of inactivity.
This helps our team focus on active issues.

If you have found a problem that seems similar to this, please open a new issue.

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