I have a docker container with a -v /home/dan:/home/dan:rw
. When the container writes files to /home/dan
, the files are owned by root in the host filesystem. Is there a way to make it so that files written from the container to the mounted volume are owned by some arbitrary user on the host filesystem?

- 4,474
- 40
- 55

- 765
- 2
- 9
- 13
4 Answers
As François Zaninotto has pointed out, the user id can be used.
This can be done by using the -u switch for the docker run command.
For example:
docker run -v /home/dan:/home/dan -u `id -u $USER` IMAGE
-
1How do you deal with the fact that the docker container is now running in non-root mode? This seems like a huge inconvenience to deal with while developing. – David Parks Jul 20 '19 at 19:48
-
Not sure if I understand. When you develop without docker, you are using a non-root user I assume, right? Please elaborate. – mandark Jul 21 '19 at 00:49
-
You have to specify a uid/gid (user/group) which isn't portable so file permissions match on the local src mount. Do you create a user with your dev uid/gid, then install all dependencies under that user in the docket env, then set that user as the default when deploying in a cluster environment? By default most docker images are configured with root in the container. – David Parks Jul 21 '19 at 01:49
-
1@DavidParks Maybe I am assuming too much so please correct me - but it seems like you have two different use cases. In one case you want to be able to change the environment i.e. install dependencies - in the other case, you want to run a specific process with limited privileges. I would maintain the image using root and once I have all the libs/dependencies, commit the container, tag the image and use that with a specific user id / group id. – mandark Jul 21 '19 at 11:54
EDIT: this has changed since my original answer which said it couldn't be done. As per answer of Mandark:
This can be done by using the -u switch for the docker run command.
For example:
docker run -v /home/dan:/home/dan -u `id -u $USER` IMAGE
-
2See the answer from mandark, that is the correct answer now (perhaps it changed since this was originally posted) – rgardler May 16 '16 at 23:01
A follow up to mandark answer - I would say it's also good to include the user group otherwise you will end up with stuff belonging to user: USER
and group: root
. To achive user:user
just pass in group id as well, for example:
docker run -v /home/dan:/home/dan -u `id -u $USER`:`id -g $USER` IMAGE
# if it's for the current user, then you can omit the $USER env var
docker run -v /home/dan:/home/dan -u `id -u`:`id -g` IMAGE

- 1
- 1

- 416
- 4
- 5
It's possible. It's hard to automate, but it's possible. Here is the process:
- in the host, determine the current user id and group id
in the docker container, run a shell script to:
- add a new group with the group id from the host
- add a new user with the same user id from the host (and belonging to the group just created)
- sudo as this new user
Now, each file generated inside the container will be using the right user id and group id, and the host will attach them to your user.
I've written a tool to automate that using make, it's called make-docker-command. Hope this helps.

- 7,068
- 2
- 35
- 56