This message was deleted.

I’d suggest going into the container and running

ls -lad

on

/home/atlantis/

and

/home/atlantis/.atlantis

and then look at the process table to see which user owns the atlantis process. I’ve only read the readme on the recent permission changes, but my hunch is that a temporary directory was created inside the image with one user, and now you’re trying to put subdirectories and files under it with another. If that’s the case, starting over with a fresh container or

chown

against one of those two directories should fix it.

ok so we discovered we don't run as the atlantis user after executing

whoami

(forced the pod to stay alive).

you can set

USER root

in your docker container but it’s not recommended to run as root

Yes I want to avoid that too. Is it possible to give the generic user the same privileges as the atlantis user? I am new to docker so sorry for asking the basic questions!

I am not sure how you are setting your Dockerfile, but I had a similar issue but related to the level of permission the atlantis user had in the container and I kinda fixed it this way:

FROM <http://ghcr.io/runatlantis/atlantis:v0.27.0|ghcr.io/runatlantis/atlantis:v0.27.0>
USER root

COPY generator/requirements.txt /tmp/
COPY generator/generator.py /usr/local/bin/

ENV VIRTUAL_ENV=/opt/venv
RUN apk add --no-cache python3 py3-pip 
RUN python3 -m venv $VIRTUAL_ENV
ENV PATH="$VIRTUAL_ENV/bin:$PATH"
RUN pip install -r /tmp/requirements.txt
USER atlantis

Not sure if you need to force the UID on your deployment, but this should be enough to make sure the user running in the image to be

atlantis

thank you, I saw that example in a git issue, but it didn't solve our problem since we didn't set the virtual env/dont need a virtual env

the key is

FROM <http://ghcr.io/runatlantis/atlantis:v0.27.0|ghcr.io/runatlantis/atlantis:v0.27.0>
USER root

# .. anything ...

USER atlantis

My colleague figured it out just recently and the githook ran fine.

FROM <http://ghcr.io/runatlantis/atlantis:v0.27.0|ghcr.io/runatlantis/atlantis:v0.27.0>

COPY . /app
WORKDIR /app 

USER 0 

RUN chown -R atlantis:root /home/atlantis; \ 
    chmod 770 /home/atlantis; 

USER 1001 

CMD ["/bin/bash", "docker-entrypoint.sh"]

``````

you may also be able to set the run user and run group in k8s (if thats how youre deploying)

well no, tbh but its a standard in our team so trying to be consistent

how did you folks get that standard? out of curiosity.

Sorry, my intention was to show you the USER at the end of the Dockerfile, not the other parts. I should have been more clear. Glad it worked out for you

Oh I saw it dont worry! We already went this route. Thank you @Vinicius Oliveira. Previously we changed

USER 1001

to

USER atlantis

but thanks ran into issues. Thanks to @Gabor Maghera we discovered while in the container (we forced it to stay alive after deployment) that we were running as user

100905000

. We can't change this, we can't configure the OCP deployments fully (enterprise restrictions). Luckily with the details of how the pod was running and who owned what, groups, etc. we were able to find the solution above

still seems like a mystery to me. id be curious what the OCP team says about human readable vs uid.

Possibilities: • The person who wrote the instructions just uses that standard • Avoid unnecessarily freaking out the security team and others with the word

root

lol oh boy. If the second option is the reason, that would be a hilarious way of getting around security.

This may be related to https://github.com/terraform-aws-modules/terraform-aws-atlantis/issues/382

Yes it is related to that