search

tessellator / openfaas-clojure-template

An OpenFaaS template for writing functions in Clojure
MIT License
9 stars 6 forks source link

can't find gid for group app: no such group: app #4

Closed ccfontes closed 3 years ago

ccfontes commented 3 years ago

When running faas-cli up using Docker version 2.1.0.3, I get this:

received non-zero exit code from build, error: unable to convert uid/gid chown string to host mapping: can't find gid for group app: no such group: app

The reason is explained here https://github.com/PsychoinformaticsLab/pliers/issues/413:

which occurs during COPY --from=builder --chown=pliers /opt/venv /opt/venv because if a group is not specified in --chown, the version of docker I'm using assumes the group is the same as the user (e.g., pliers), but since RUN useradd --no-user-group --create-home --shell /bin/bash pliers specifies that a group should not be added, then the error occurs since the pliers group does not exist.

Also, seems that when creating a user with adduser, Alpine doesn't create a group for said user?

To solve the issue, replaced line in: https://github.com/tessellator/openfaas-clojure-template/blob/main/template/clojure/Dockerfile#L24 with:

RUN addgroup -S app
RUN adduser -S app -G app

Not issuing a PR, because you may have a more elegant way to solve this, like specifying some group at COPY --chown.

I can verify your fix later, but running in your local should at least assure nothing breaks. :)

Thanks.

tessellator commented 3 years ago

This is interesting. I have not been able to reproduce this issue locally. However, since I know this worked for you before my latest changes to the Dockerfile, I am going to re-add the addgroup command as you have suggested and put it into a PR for your review.

It appears that the group that was created for the app user is called nogroup. This was surprising to me. I had seen the following excerpt from the Alpine docs and incorrectly interpreted it as talking about names instead of IDs. (Although even this excerpt does not seem to match what is happening in my local builds either.)

If --ingroup isn't set, then the new user is assigned a new GID that matches the UID. And if the GID corresponding to a provided UID already exists, adduser will fail. This makes new users default to having a "user's private group" (UPG) as primary group. It allows using a permissive umask (002) that automatically leaves new files group-writable, only to the user's private group by default, but writable to an actual user group if saving a file in special set-group-id group directories.