moby: linux spec user: Unable to find user xxx
Since upgrading to Docker 1.11.0 the following won’t work anymore:
$ docker run -it --rm --user $(whoami) -v /etc/passwd:/etc/passwd:ro busybox
docker: Error response from daemon: linux spec user: Unable to find user xxx
You also get some funny behavior when using a non root user that exists in the image’s /etc/passwd:
$ docker run -it --rm --user operator -v /etc/passwd:/etc/passwd:ro busybox whoami
whoami: unknown uid 37
Depending on your system the above might actually work fine or output some other random user name, on my host /etc/passwd has no entry for uid 37.
Apparently --user is now set before the /etc/passwd file of the host is mounted in the container. Can this functionality be restored in a future release? If not, mounting the host’s /etc/passwd should not be allowed as it will just lead to problems down the road.
The use case for this is mainly for local development, where, for example, you would like to run a css preprocesser watching your source files and want to avoid any file permission head aches.
About this issue
- Original URL
- State: closed
- Created 8 years ago
- Reactions: 26
- Comments: 18 (8 by maintainers)
Commits related to this issue
- Attempt different way to set docker user Otherwise, this issue is encountered: https://github.com/moby/moby/issues/22323#issuecomment-214727951 — committed to raymondEhlers/OVERWATCH by raymondEhlers 6 years ago
- Attempt different way to set docker user Otherwise, this issue is encountered: https://github.com/moby/moby/issues/22323#issuecomment-214727951 — committed to raymondEhlers/OVERWATCH by raymondEhlers 6 years ago
- Attempt different way to set docker user Otherwise, this issue is encountered: https://github.com/moby/moby/issues/22323#issuecomment-214727951 — committed to raymondEhlers/OVERWATCH by raymondEhlers 6 years ago
- Try to fix Docker error in Github Actions. Not entirely sure what's causing it but found a comment that indicates adding the `--user` option as I did here may solve it: <https://github.com/moby/moby/... — committed to karlmdavis/fhir-benchmarks by karlmdavis 4 years ago
Why not use the numeric ID of the user, instead of a user-name; doing so, you don’t have to bind-mount
/etc/passwd, because that file is only needed to convert the username to its uid/gid inside the container.the only thing you’ll miss is having a “nice” name visible inside the container, but I suspect the reason you’re doing this is for setting the right permissions, and not to show a user’s name.
The docs over at https://docs.docker.com/engine/reference/run/#user should be updated to reflect that only UIDs work and usernames don’t.
The opencontainers specification requires that the user id passed to runc in Linux is a number, and resolving user names is left to the layers above, see https://github.com/opencontainers/runtime-spec/blob/master/config.md#linux-user
Therefore since we use
runcthe name has to be derived before the mounts take place, so bind mounting/etc/passwdwill be too late. Although this used to work, I think that it was just because the ordering happened to be like that, and I don’t think it can really be seen as a regression, and I don’t think it is sensible to fix it, as numeric ids are what the kernel really uses. (Despite the fact it has been a convenient use case!)I think I’m encountering https://success.docker.com/article/ucp-health-checks-fail-unable-to-find-user-nobody-no-matching-entries-in-passwd-file-observed
That’s unfortunately not very helpful, there’s no reference number and there is no datestamp anywhere on the page. But at least it’s something…
@edannenberg it would be good to know the reason this changed, it’s possible this change is actually related to creating volumes with the right permissions (i.e., if I start a container as user 123, and create a volume, then the volume should be owned by 123). If that is the reason, then I’m not sure we’d be able to revert to the old behavior
@thaJeztah the
docker run -it --rm --user $(id -u) busyboxsolution works. However, there is still 1 use case for/etc/passwd, if you don’t mind I describe it below.If you need to use SSH protocol inside a container (e.g., git clone), you will need the password file.
So, I’ve modified our build environment to something like:
docker run --rm -it -v $SSH_AUTH_SOCK:/ssh-agent -e SSH_AUTH_SOCK=/ssh-agent -u $UID -v /etc/passwd:/etc/passwd:ro <builder-image>That way I’ve my ssh-agent inside the container and my user is known by the contianer, which is a must for SSH.