

This can work fine on your local environment. In this example a user ‘jboss’ is created with the uid and gid 1000. For example the uid given to the user can be something like 1001 or 1002. This can become difficult later to grant file permissions to mounted volumes.įor that reason you sometimes can see Dockerfiles creating a user like this: RUN groupadd -r jboss -g 1000 & useradd -u 1000 -r -g jboss -m -d /opt/jboss -s /sbin/nologin -c "JBoss user" jboss & \ This will create a normal user with an unpredictable userid (uid). When you look around the docker universum on DockerHub you will find a lot of examples of Dockerfiles created a user like this: # create non-privileged user and group RUN groupadd -r imixs & adduser imixs Otherwise you will get an error message from the docker daemon : docker: Error response from daemon: linux spec user: unable to find user imixs: no matching entries in passwd file.


FROM imixs/wildfly:latestīut to run such an container you have to make sure that this user exists in your container. This can be a security issue for productive environments in case your process becomes vulnerable.įor this reason it is recommended that your run your process inside a Docker container always as a Non-Privileged (or Non-Root) User. This can easily archived with the USER command. When you build your own Docker Image with a Dockerfile, your process inside this container will typically run as the root user per default.
