10

I've got a Docker image which generates log-like files when errors occur. I've mounted the directory it writes to to my host machine with a bind mount. However, the created files are owned by root. Though my user account has root privileges, it is tedious to run chown and chgrp after every run of the container in order to inspect the files.

Is there a way to have the container set the owner and group of the files to that of the user who ran the container?

For some context, here's a toy example I created:

Dockerfile

FROM debian

WORKDIR /root
VOLUME /root/output

COPY run.sh /root/

ENTRYPOINT ["./run.sh"]

run.sh

#!/bin/bash

echo hello > output/dump

My execution command is

docker run -v $PWD/output:/root/output test
0

3 Answers 3

12

The files are created by the user that runs within the container. Iif your containerized command runs as root, then all files will be created as root.

If you want your files to be created as another user, run the container as this other user. e.g.

docker run -v "$(pwd)/output":/root/output -u $(whoami) test

Note: Depending on your container, this might not work out of the box (e.g., because, within the container, you need to open a privileged port or your script is only accessible by a given (super)user).

7
  • 1
    So, I have to create a user with the same name inside the container? Otherwise, the container complains that the user could not be found in /etc/passwd. Jan 1, 2021 at 0:43
  • 2
    you could also just use the (numeric) uid instead of the username. e.g. docker run -v "$(pwd)/output":/root/output -u ${UID} test
    – umläute
    Jan 1, 2021 at 20:19
  • Passing in the UID gave docker: Error response from daemon: OCI runtime create failed: container_linux.go:349: starting container process caused "exec: \"./run.sh\": stat ./run.sh: permission denied": unknown.. run.sh is executable by all. Jan 1, 2021 at 22:01
  • 2
    well your run.sh script lives in /root/, and /root/ is typically not readable by anyone but the superuser.
    – umläute
    Jan 1, 2021 at 22:49
  • 4
    Note that -u $(whoami) requires that the user exists in the container. If that's not the case, you can use -u $(id -u):$(id -g) instead.
    – Ignitor
    Nov 18, 2021 at 7:07
1

It's an old known bug. As a workaround, one may use Podman, it is compatible with Docker, they even suggest adding an alias docker=podman. One advantage in context of the question here is that Podman does not require a service running as root. Not only it's good for security, but it actually avoids bugs like this.

Demonstration:

$ ls -l /tmp/hello
ls: cannot access 'hello': No such file or directory
$ podman run --rm -v /tmp/:/mnt/ -it ubuntu:22.04 sh -c "touch /mnt/hello && ls -l /mnt/hello"                                                                                           2 ↵
-rw-r--r--. 1 root root 0 Sep 26 03:57 /mnt/hello
$ ls -l /tmp/hello
-rw-r--r--. 1 konstantin konstantin 0 сен 26 06:57 hello
0

I had this issue too but likely for a different reason than the majority here and I like to spare some frustration for those in the same boat.

I have dual boot and had my docker images and code on a NTFS-3G drive. I tried all dirty tricks with chmod and chown but it just would not work.

When the penny dropped NTFS-3G was causing the issue, I moved Docker back to the default configuration. Images & containers are then located in /var/lib/docker and my code, I moved to ~/code/project.

Now it's flying again with sane permissions after the container ran.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.