3

Preliminary

First, a preliminary. When running a docker container with a volume mapped to some part of the host, the user inside the docker container is usually root, so for files generated by the container, the Host cannot edit, modify or delete them. To solve this some people (including the one who created the image I am using) recommends using -u

The Situation

I have a Docker image (built by a different person in a different machine)

This Docker image assumes the user is going to be a user with id 1000

The problem

When a person who is the only user of a Host machine (and whose user id is 1000) runs the image, there is no problem. However, in my case I am the second user of this Host so my user id is 1001. So I have the following:

In the Host I do cat /etc/passwd and I get several users including:

firstuser:x:1000:1000:firstluser,,,:/home/firstuser:/bin/bash

myself:x:1001:1001:My Name,,,:/home/myself:/bin/bash

Then :

CASE 1 I run the container with

docker run -it --rm -u 1001:1001  -v /a/path:/another/path image  /bin/bash

because doing id -u and id -g gives me 1001.(I am the second user after all)

Doing this causes that

groups:cannot find name for group ID 1001

then my user becomes "I have no name!" and when I do cat/etc/passwd I get

originaluser:x:1000:1000::/home/originaluser:bin/bash <---- here there are not ,,,

so obviously my user (1001) does not exist which causes a lot of problems.

To solve this I tried

CASE2 I run the container with

docker run -it --rm -u 1000:1000  -v /a/path:/another/path image  /bin/bash

which does not cause the previous error, and now even though I am myself but run the Docker image as firstuser, in the container I am originaluser (since both are 1000)

Doing the cat /etc/passwd I can see

originaluser:x:1000:1000::/home/sensetime:bin/bash

and as predicted my user is originaluser.

I should be happy but, this also causes problems!

Later on the program inside the container tries to create a file (with user 1000) but since it is mapped and the user owner is 1001 this creation fails.

What is a good way to prevent all these problems and be able to synchronize the user in the host with the user in the container?

halfer
  • 19,824
  • 17
  • 99
  • 186
KansaiRobot
  • 7,564
  • 11
  • 71
  • 150
  • What is your use case where a user on the host needs to directly edit a data file managed by a container process? The "I have no name" message should mostly be a cosmetic issue in the unusual case of running an interactive shell in a container. – David Maze Oct 12 '20 at 13:29
  • @David Maze I can't speak to the op's use case, but I/O is faster on a mounted directory than the docker's virtual memory. The performance benefit is one reason the docker may need access to files on the host machine. – John Colvin Sep 11 '22 at 04:32

1 Answers1

2

I recently discovered fixuid which may solve most of you problems.

The uid/gid in a container cannot (or is not expected to) match the ones on your host.

The fixuid setuid go binary I linked above can solve this by changing the uid/gid of the user in docker to match the one you configured.

For instance:

Host: uid/gid/name=1001/1001/kansai
Guest user: uid/gid/name=1000/1000/user

If you had add the fixuid binary in you container (build phase) then you can run:

docker run --rm -it -u $(id -u):$(id -g) -v /a/path:/another/path image fixuid /bin/bash

You can also set fixuid in an entrypoint so it will be easier to use.

Cyrille Pontvieux
  • 2,356
  • 1
  • 21
  • 29
  • Thanks for the reply!. Actually the person who built the image did include fixuid in the entrypoint but I got the "fixuid: already ran on this system; will not attempt to change UID/GID" error. I wrote a question about this in https://stackoverflow.com/questions/64313676/why-is-fixuid-refusing-to-change-the-uid-gid – KansaiRobot Oct 12 '20 at 08:22