<p>For the easy solution, use named volumes when possible. They will initialize to the contents of the image, include file owners and permissions.</p>

<p>When you need host volumes, my preferred solution for developer machines is to run the entrypoint as root and drop permissions to the application user after adjusting uid/gid values of the users inside the container to match the the id's on volumes that have been mounted. For example, here's a repo where I've done this for a Jenkins container that needs to run as the jenkins user but with gid access to the mounted docker socket: <a href="https://github.com/sudo-bmitch/jenkins-docker" rel="nofollow noreferrer">https://github.com/sudo-bmitch/jenkins-docker</a></p>

<p>The key steps to the solution:</p>

<ul>
<li>Start the container as root on developer machines (in production you can put some logic in the entrypoint to know that it's not root and make the file permissions on the server match those of the container).</li>
<li>Configure the entrypoint to lookup the uid/gid of a selected host volume.</li>
<li>Compare the volume uid/gid to the container user's uid/gid. If they do not match, update the user's uid/gid inside the container and adjust file permissions on files outside of the volume. Be careful to handle the scenario where the uid/gid already exists inside the container.</li>
<li>Use gosu to switch from root to your container user and run the desired application.</li>
</ul>

CC BY-SA 4.0
2018-10-06T21:43:34.547Z
This looks nice! But I'm not sure if I understand you correctly. By "Start the container as root on developer machines" you mean start container with root as the container user, not run docker with sudo, am I right? Then it makes sense, even if I wonder how to "lookup the uid/gid of a selected host volume" from inside a container...
Pawel
CC BY-SA 4.0
2018-10-07T01:15:03.740Z
@Pawel root as the container user. There's a link to a repo with an example of this. It was napping the gid of the docker socket, but that can be the uid/gid of any volume mounted into the container.
BMitch
CC BY-SA 4.0
2018-10-05T12:49:49.493Z
2018-10-05T12:49:49.493Z
BMitch
<p>I'm a little confused about the exact use case. Are you asking about writing to volumes that are mounted inside the container? </p>

<p>You can change what the process in the docker container runs as by using --user on your run commands.</p>

<pre><code>docker run --user 1000 --ti centos/7 /bin/bash
</code></pre>

<p>This answer may help you: 
<a href="https://stackoverflow.com/questions/41100333/difference-between-docker-run-user-and-group-add-parameters">https://stackoverflow.com/questions/41100333/difference-between-docker-run-user-and-group-add-parameters</a></p>

<p>The manual explains this as well: <a href="https://docs.docker.com/engine/reference/run/#user" rel="nofollow noreferrer">https://docs.docker.com/engine/reference/run/#user</a></p>

CC BY-SA 4.0
2018-10-05T07:12:48.503Z
I still have to pass user id explicitly.

This question is not new, and I was able to find a solution that worked for me, but still, I think it can be improved somehow.

In the docker-compose.yml file I pass the UID variable to the container, and then I change user id for the given in the Dockerfile. It has some cons though: if I want to use container directly from the image, I have to wrap it in my build.
Pawel
CC BY-SA 4.0
2018-10-05T07:18:07.323Z
Also, I can no longer simply run `docker-compose up -d`, it has to be like `UID=$(uid) docker-compose up -d`
Pawel
CC BY-SA 4.0
2018-10-08T14:24:00.960Z
Thanks for following up with the solution you found which worked for you.

I stumbled upon this article which describes what you discovered:
https://jtreminio.com/blog/running-docker-containers-as-current-host-user/
Ghost
CC BY-SA 4.0
2018-10-04T14:04:35.853Z
2018-10-04T14:04:35.853Z
Ghost
<p>I'm using docker some time and I like the conception very much. But I found a thing is a big problem for me.</p>

<p>I'm talking about permissions. While I'm not worrying about production, setting up my docker development environment becomes hell, because of file ownerships and permissions. For example:</p>

<ul>
<li>www-data user from php container cannot create files in my directories (www-data uid is 82 while my uid is 1000)
I was trying to change www-data id to 1000 but I share this environment with macOS users, who typically have uid of 500</li>
<li>I cannot remove files that have been created within container - that makes it hard for me to jump between git branches sometimes (<code>sudo rm somefile</code>).</li>
</ul>

<p>I spend hours, no, days looking for ultimate solution. Tried <code>gosu</code> in containers, mounting <code>/etc/shadow</code> as a volume etc. The problem is, I was unable to find a solution that can be considered multi-platform and proper (mounting local system files readonly just doesn't look good).</p>

<p>Thank you!</p>

CC BY-SA 3.0
2018-04-10T11:30:19.247Z
There's no magic trick, you have to configure your system, if the base docker image doesn't fir your need, modify it and create your own... All in all, sharing files between host and container is not what docker is made for at root, so obviously it comes with management overhead.
Tensibai
CC BY-SA 3.0
2018-04-10T14:44:03.010Z
What OS do you use?
030
CC BY-SA 3.0
2018-04-10T17:09:23.850Z
@030 I'm using Ubuntu Linux as well as majority of people with I work with. Some of them have macs though.
Pawel
<docker><linux>
Ultimate docker permission solution
Pawel
# Ultimate docker permission solution

(Asked by: username_0 on 2018-04-10)

I'm using docker some time and I like the conception very much. But I found a thing is a big problem for me.

I'm talking about permissions. While I'm not worrying about production, setting up my docker development environment becomes hell, because of file ownerships and permissions. For example:

* www-data user from php container cannot create files in my directories (www-data uid is 82 while my uid is 1000)
  I was trying to change www-data id to 1000 but I share this environment with macOS users, who typically have uid of 500
* I cannot remove files that have been created within container - that makes it hard for me to jump between git branches sometimes (`sudo rm somefile`).

I spend hours, no, days looking for ultimate solution. Tried `gosu` in containers, mounting `/etc/shadow` as a volume etc. The problem is, I was unable to find a solution that can be considered multi-platform and proper (mounting local system files readonly just doesn't look good).

Thank you!

**Tags:** docker, linux

> **Comments:**
> **username_1**: There's no magic trick, you have to configure your system, if the base docker image doesn't fir your need, modify it and create your own... All in all, sharing files between host and container is not what docker is made for at root, so obviously it comes with management overhead.  
> **username_2**: What OS do you use?  
> **username_0**: @username_2 I'm using Ubuntu Linux as well as majority of people with I work with. Some of them have macs though.  

---

## 2 answers

### Answer by username_3 on 2018-10-05. Score: 1

For the easy solution, use named volumes when possible. They will initialize to the contents of the image, include file owners and permissions.

When you need host volumes, my preferred solution for developer machines is to run the entrypoint as root and drop permissions to the application user after adjusting uid/gid values of the users inside the container to match the the id's on volumes that have been mounted. For example, here's a repo where I've done this for a Jenkins container that needs to run as the jenkins user but with gid access to the mounted docker socket: <https://github.com/sudo-bmitch/jenkins-docker>

The key steps to the solution:

* Start the container as root on developer machines (in production you can put some logic in the entrypoint to know that it's not root and make the file permissions on the server match those of the container).
* Configure the entrypoint to lookup the uid/gid of a selected host volume.
* Compare the volume uid/gid to the container user's uid/gid. If they do not match, update the user's uid/gid inside the container and adjust file permissions on files outside of the volume. Be careful to handle the scenario where the uid/gid already exists inside the container.
* Use gosu to switch from root to your container user and run the desired application.

> **Comments:**
> **username_0**: This looks nice! But I'm not sure if I understand you correctly. By "Start the container as root on developer machines" you mean start container with root as the container user, not run docker with sudo, am I right? Then it makes sense, even if I wonder how to "lookup the uid/gid of a selected host volume" from inside a container...  
> **username_3**: @username_0 root as the container user. There's a link to a repo with an example of this. It was napping the gid of the docker socket, but that can be the uid/gid of any volume mounted into the container.  

---

### Answer by username_4 on 2018-10-04. Score: 1

I'm a little confused about the exact use case. Are you asking about writing to volumes that are mounted inside the container? 
You can change what the process in the docker container runs as by using --user on your run commands.
docker run --user 1000 --ti centos/7 /bin/bash

This answer may help you: 
https://stackoverflow.com/questions/41100333/difference-between-docker-run-user-and-group-add-parameters
The manual explains this as well: https://docs.docker.com/engine/reference/run/#user

> **Comments:**
> **username_0**: I still have to pass user id explicitly.  This question is not new, and I was able to find a solution that worked for me, but still, I think it can be improved somehow.  In the docker-compose.yml file I pass the UID variable to the container, and then I change user id for the given in the Dockerfile. It has some cons though: if I want to use container directly from the image, I have to wrap it in my build.  
> **username_0**: Also, I can no longer simply run `docker-compose up -d`, it has to be like `UID=$(uid) docker-compose up -d`  
> **username_4**: Thanks for following up with the solution you found which worked for you.  I stumbled upon this article which describes what you discovered: https://jtreminio.com/blog/running-docker-containers-as-current-host-user/  

---

