Answers: <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>
  
Answers: CC BY-SA 3.0
Answers: 2017-10-20T05:32:33.477Z
Answers: Doh. Talk about overthinking this problem. That obvious option works and does what you said.
Answers: AnoE
Answers: CC BY-SA 4.0
Answers: 2019-04-09T01:51:13.530Z
Answers: Keep in mind that this will only work when the user ID and group ID already exist in the Docker image.
Answers: user30747
Answers: CC BY-SA 4.0
Answers: 2020-01-22T13:31:39.543Z
Answers: 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.
Answers: Marcus Philip
Answers: CC BY-SA 3.0
Answers: 2017-10-19T22:34:10.353Z
Answers: 2017-10-19T22:34:10.353Z
Answers: user2640621
Body: <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>
  
Comments: CC BY-SA 3.0
Comments: 2017-10-17T12:10:40.073Z
Comments: `dockerizedgit "$@" && chown you_user:you_group -R .` ?
Comments: Tensibai
Comments: CC BY-SA 3.0
Comments: 2017-10-17T14:33:24.923Z
Comments: 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`...
Comments: AnoE
Comments: CC BY-SA 3.0
Comments: 2017-10-17T14:42:18.653Z
Comments: 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.
Comments: Tensibai
Comments: CC BY-SA 3.0
Comments: 2017-10-17T14:43:43.303Z
Comments: 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)
Comments: Tensibai
Comments: CC BY-SA 3.0
Comments: 2017-10-18T08:33:48.623Z
Comments: 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.
Comments: Tensibai
Tags: <docker><permissions><user-namespaces>
Title: Using docker with users leaves files belonging to the subuid/subgid
UserDisplayName: AnoE
ThreadText: # 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.  
  
  ---
  
  