The problem
My docker-compose stack is comprised of 'postgresql', 'redis' and 'Python api server' along with a few others like opentracing etc., but the problem area is restricted to the before mentioned.
The entrypoint in my compose file is a shell script that creates a few files and folders dynamically by reading the environment variables amongst the other things it is supposed to do. Now, the creation of these files work like a charm but the file and folder permissions of these dynamically generated files get interesting. On macos, these dynamically generated files and folders are owned by the non-root user who ran
docker-compose up. But, on a linux machine running Ubuntu 19.01 these files and folders get owned byrootdespite Dockerfile explicitly doing achown non-root-user:non-root-groupto the whole project's folder and setting active USER as thisnon-root-userThe postgres container mounts itself onto given path but the owner of that directory is no longer who created it but some strange
systemd-coredumpI guess this is because userID and group on Postgres' Dockerfile maps to this username on my linux server? If yes, what is the recommended way to avoid this?
Since the non-root user who ran docker-compose up is unable to retain file and folder permissions on host machine, Im running into permission denied issues. Whilst a chmod 777 helps get away with the problem, I believe chmod 777 never really solves any problem.
Re-iterating that all of this is a problem only on a Linux machine. On Macos running Docker-For-Mac, both pre-existing and dynamically generated files/folders retain the non-root logged in user as their owner and inside the container, the designated USER in Dockerfile remains the owner of all pre-existing (those that get transferred via COPY ) and newly generated dynamic files/folders.
Example
An example of change in file and folder ownership:
drwxrwxr-x 13 sparkle_deployment_2 sparkle_deployment_2 4096 Nov 21 01:00 PROTON/
drwx------ 19 systemd-coredump docker 4096 Nov 21 01:00 proton_db/
From above, proton_db is where Postgres is supposed to mount onto. This folder was created initially by user - sparkle_deployment_2. After docker-compose up, the owner and group is changed to system-coredump and docker respectively.
Here is a slice of my: docker-compose.yaml
version: "3.4"
services:
pg:
container_name: proton_postgres
restart: always
image: postgres
environment:
- POSTGRES_USER=${PG_USERNAME}
- POSTGRES_PASSWORD=${PG_PASSWORD}
- POSTGRES_DB=${PG_TARGET_DB}
volumes:
- ${PROTON_POSTGRES_VOLUME_MOUNT}:/var/lib/postgresql/data
ports:
- ${PG_TARGET_PORT}:${PG_TARGET_PORT}
redis:
container_name: proton_redis
restart: always
image: redis
volumes:
- ${PROTON_REDIS_VOLUME_MOUNT}:/data
ports:
- ${REDIS_TARGET_PORT}:${REDIS_TARGET_PORT}
proton:
container_name: proton
restart: always
image: proton_stretch
ports:
- ${PROTON_TARGET_PORT}:${PROTON_TARGET_PORT}
expose:
- ${PROTON_TARGET_PORT}
volumes:
- .:/PROTON
- ${PROTON_SQLITE_VOLUME_MOUNT}:/PROTON/proton-db
depends_on:
- pg
- redis
entrypoint: ["./proton.sh"]
And, here is my API server's Dockerfile:
FROM python:3.7.3-stretch
RUN apt-get update
RUN apt-get install bash
RUN apt-get install -y gcc g++ unixodbc-dev
RUN groupadd -g proton_user_group
RUN useradd -G proton_user_group default_proton_user
RUN mkdir -p /PROTON
WORKDIR /PROTON
COPY . /PROTON
RUN python3 -m pip install -r requirements.txt --no-cache-dir
RUN chown -R default_proton_user:proton_user_group /PROTON
USER default_proton_user
EXPOSE 3000/tcp
As you see, I'm doing a chown to explicitly have the directory owned by a non-root user. Despite this, when there are files/folders that get dynamically generated, they get root as their owner. And, this happens only on linux.
Win
Like in MacOS, I want the non-root host on linux machine to retain ownership of all pre-existing and dynamically generated files/folders hence not leading to any "permission denied" issues.
Plus the same non-root host on linux machine to retain ownership of the location where Postgres container volume gets mounted onto.
addgroupandadduserexplicitly in your Dockerfile, and set explicitgidanduidrespectively? Docker does not do anything special withgidanduid, so if the values in your image are shadowing values of groups and/or users on your host, then ownership will appear as the shadowed groups and/or users.addgroupandadduseras you see above. Thanks for your time and help.