<pre><code>docker run -ti --rm \
  -v $PWD:/workdir \
  -v $HOME/.ssh:/root/.ssh \
  --user $(id -u):$(id -g) \
  dockerizedxyz "$@"
</code></pre>

<p>As long as you're not doing anything funny with the entrypoint in the container, this will leave files owned as the user that invoked Docker.</p>

CC BY-SA 3.0
2017-10-20T05:32:33.477Z
Doh. Talk about overthinking this problem. That obvious option works and does what you said.
AnoE
CC BY-SA 4.0
2019-04-09T01:51:13.530Z
Keep in mind that this will only work when the user ID and group ID already exist in the Docker image.
user30747
CC BY-SA 4.0
2020-01-22T13:31:39.543Z
It will work even if user ID does not exist in docker image. If it _does_ exist it will assume that identity which is probably not what you want. An approach is to add -v /etc/passwd:/etc/passwd:ro, but that will completely replace the users which may or may not work.
Marcus Philip
CC BY-SA 3.0
2017-10-19T22:34:10.353Z
2017-10-19T22:34:10.353Z
user2640621
<h1>Background</h1>

<p>I wish to make sure all people and automated processes working with my project use the exact same version and environment of some tool which has to do work on the <em>host</em> file system. </p>

<p>Instead of running <code>/usr/bin/xyz</code> or whatever, people will then use a wrapper/shim script similar to:</p>

<pre><code>docker run -ti --rm \
  -v $PWD:/workdir \
  -v $HOME/.ssh:/root/.ssh \
  dockerizedxyz "$@"
</code></pre>

<p>This is working splendidly but...</p>

<h1>Problem</h1>

<p>Obviously, if I stop right here, then files created by the <code>xyz</code> running inside the container will be ending up belonging to <code>root:root</code> on the host. It is clear why this happens, and as expected.</p>

<p>Hence, I have enabled user namespaces for the docker demon. This works fine as well. My host user has UID 1000 and the subuid 493216.</p>

<p>If I run the docker-xyz-shim in a directory (on the host) that belongs to 1000, and if that container starts to create files, my expectation at first had been that they would have ended up as belonging to 1000 on the host (i.e., forward- and backward-mapping).</p>

<p>But, lo and behold, they belong to 493216, i.e., they belong to the subuid instead of the host uid. There is only a forward-mapping happening (from host-uid to sub-uid, no backward-mapping from sub-uid to host-uid).</p>

<p>I understand why that is, and that this is working as intended. First, there is a 1:n mapping involved, and it would be non-trivial to map the potentialla 65536 sub-uid back to the one host-uid. It allows us to do all kinds of things that would be practical in other use-cases. But in my particular case, I actually do wish the files to end up with 1000 on the host.</p>

<p><em>Is there anything I can do about it?</em></p>

<h1>What I tried</h1>

<p>I added the host user 493216 to the host group 1000 and set the <code>g+rwx</code> permissions. If I do a <code>su - 493216</code> on the host, I can now edit the files belonging to 1000. But from inside the container, the files are shown to be owned by <code>nobody:nobody</code> and I can read them, but not write them.</p>

<p>I can create new files inside the container if I do a <code>chmod 777</code> on a directory on the host (it then belongs to <code>nobody:nobdy</code> with 777 permissions in the container), and they end up belonging to <code>root:root</code> in the container (fine) and to 493216:493216 on the host (to be expected after all this).</p>

<p>EDIT: replaced "git" with "xyz", this is not about git at all, but about how to modify host files from inside a docker container without having <code>root</code> on the host.</p>

CC BY-SA 3.0
2017-10-17T12:10:40.073Z
`dockerizedgit "$@" && chown you_user:you_group -R .` ?
Tensibai
CC BY-SA 3.0
2017-10-17T14:33:24.923Z
Yes, but I try to keep The Dream running, @Tensibai ... ;) And besides, this would not work because the `chown` is running as user 1000 but the files belong to `root`...
AnoE
CC BY-SA 3.0
2017-10-17T14:42:18.653Z
sorry, I meant the && chown to be within the quotes (to be run within the container and not after it), but this is likely to need a chown  your_user_id instead of name as the container /etc/passwd file would not match your host file to resolve uid from name.
Tensibai
CC BY-SA 3.0
2017-10-17T14:43:43.303Z
Btw this sounds like a footgun bringing more problem than needed, why can't you just enforce the git version on your dev stations ? (they are part of your infrastructure to be managed after all)
Tensibai
CC BY-SA 3.0
2017-10-18T08:33:48.623Z
An alternative to docker could be using [habitat](https://www.habitat.sh/) which isolate processes with their own libraries but doesn't include filesystem isolation nor uid separation.
Tensibai
<docker><permissions><user-namespaces>
Using docker with users leaves files belonging to the subuid/subgid
AnoE
# Using docker with users leaves files belonging to the subuid/subgid

(Asked by: username_0 on 2017-10-17)

Background
I wish to make sure all people and automated processes working with my project use the exact same version and environment of some tool which has to do work on the host file system. 
Instead of running /usr/bin/xyz or whatever, people will then use a wrapper/shim script similar to:
docker run -ti --rm \
  -v $PWD:/workdir \
  -v $HOME/.ssh:/root/.ssh \
  dockerizedxyz "$@"

This is working splendidly but...
Problem
Obviously, if I stop right here, then files created by the xyz running inside the container will be ending up belonging to root:root on the host. It is clear why this happens, and as expected.
Hence, I have enabled user namespaces for the docker demon. This works fine as well. My host user has UID 1000 and the subuid 493216.
If I run the docker-xyz-shim in a directory (on the host) that belongs to 1000, and if that container starts to create files, my expectation at first had been that they would have ended up as belonging to 1000 on the host (i.e., forward- and backward-mapping).
But, lo and behold, they belong to 493216, i.e., they belong to the subuid instead of the host uid. There is only a forward-mapping happening (from host-uid to sub-uid, no backward-mapping from sub-uid to host-uid).
I understand why that is, and that this is working as intended. First, there is a 1:n mapping involved, and it would be non-trivial to map the potentialla 65536 sub-uid back to the one host-uid. It allows us to do all kinds of things that would be practical in other use-cases. But in my particular case, I actually do wish the files to end up with 1000 on the host.
Is there anything I can do about it?
What I tried
I added the host user 493216 to the host group 1000 and set the g+rwx permissions. If I do a su - 493216 on the host, I can now edit the files belonging to 1000. But from inside the container, the files are shown to be owned by nobody:nobody and I can read them, but not write them.
I can create new files inside the container if I do a chmod 777 on a directory on the host (it then belongs to nobody:nobdy with 777 permissions in the container), and they end up belonging to root:root in the container (fine) and to 493216:493216 on the host (to be expected after all this).
EDIT: replaced "git" with "xyz", this is not about git at all, but about how to modify host files from inside a docker container without having root on the host.

**Tags:** docker, permissions, user-namespaces

> **Comments:**
> **username_1**: `dockerizedgit "$@" && chown you_user:you_group -R .` ?  
> **username_0**: Yes, but I try to keep The Dream running, @username_1 ... ;) And besides, this would not work because the `chown` is running as user 1000 but the files belong to `root`...  
> **username_1**: sorry, I meant the && chown to be within the quotes (to be run within the container and not after it), but this is likely to need a chown  your_user_id instead of name as the container /etc/passwd file would not match your host file to resolve uid from name.  
> **username_1**: Btw this sounds like a footgun bringing more problem than needed, why can't you just enforce the git version on your dev stations ? (they are part of your infrastructure to be managed after all)  
> **username_1**: An alternative to docker could be using [habitat](https://www.habitat.sh/) which isolate processes with their own libraries but doesn't include filesystem isolation nor uid separation.  

---

## 1 answers

### Answer by username_2 on 2017-10-19. Score: 2 | Accepted answer

docker run -ti --rm \
  -v $PWD:/workdir \
  -v $HOME/.ssh:/root/.ssh \
  --user $(id -u):$(id -g) \
  dockerizedxyz "$@"

As long as you're not doing anything funny with the entrypoint in the container, this will leave files owned as the user that invoked Docker.

> **Comments:**
> **username_0**: Doh. Talk about overthinking this problem. That obvious option works and does what you said.  
> **username_3**: Keep in mind that this will only work when the user ID and group ID already exist in the Docker image.  
> **username_4**: It will work even if user ID does not exist in docker image. If it _does_ exist it will assume that identity which is probably not what you want. An approach is to add -v /etc/passwd:/etc/passwd:ro, but that will completely replace the users which may or may not work.  

---

