How-to: Address Common Issues with Container Deployments
Issue:
While in the process of deploying a new build, updating the instance to 3.0.2 in a self-hosted sandbox environment, and running `docker-compose up`, a ‘permissions denied’ error appears - how can this be addressed?
Solution:
The 'PermissionError' is typically that the UID of the host account running the container and the container bind mount being set to UID '1000' are not the same
The container bind mount is set to UID '1000' since there is only one (1) user in the container (i.e., l7esp) it’s UID is '1000'
Users may run "id" to first get the UID of the host account and modify 'DockerFile'
This change to 'docker/Dockerfile' will set the UID for the bind mount to match the host UID and change the owner of '/opt/l7esp' folders for the new UID
Users may need to rebuild the container with the new image using:
docker compose up --buildThis should execute the additional shell commands to get permissions aligned within the container volumes
Additional information:
The user that logs in and starts the container in the host machine should be aligned with the user id # inside the container (one common issue is sometimes users run into trouble because they log in as different users on the host machine which means the user id number is shifting)
In Linux, the first custom user created is usually user id '1000', but this can sometimes very by the exact operating system distribution: https://www.redhat.com/sysadmin/user-account-gid-uid
By default, Linux systems automatically assign UIDs and GIDs to new user accounts in numerical order starting at '1000' (in other words, if creating a new user account during installation, it will have UID = '1000' and GID = '1000')
If the administrative user on the host machine does not happen be user id '1000' and group id '1000', the user will likely want to use the Dockerfile to update the userid and groupid for the ESP Server service container