Dockerfile contains `mkdir` and `chown` commands, but in the resulted built image there is no directory and permissions

[kseniyashaydurova]

Actual behavior

We have below directives in our Dockerfile. They create fpm directory in /var/run path and set nginx ownership for this dir, 2d directive just prints current contents of /var/run folder and its ownership.

RUN mkdir /var/run/fpm && chown nginx:nginx /var/run/fpm RUN ls -lh /var/run/

When we build our Dockerfile with docker build everything builds correctly, fpm directory exists and nginx user is its owner. But when we build our Dockerfile with kaniko executor we end up with docker image which has no fpm folder inside (but what is strange build process logs show correct results on 2d RUN ls -lh /var/run directive).

Expected behavior We expect that in the resulted docker image there would be fpm directory with nginx user ownerhip.

To Reproduce Steps to reproduce the behavior:

1. Build attached docker image with kaniko executor
2. Go inside built container and check whether fpm directory exists in var/run and has nginx owner (ls -lh /var/run)

Additional Information

• Dockerfile Dockerfile.txt

• Build Context /kaniko/executor --build-arg=ENVIRONMENT=dev --dockerfile=/workspace/app/Dockerfile --context=/workspace/app/. --destination=.../saritasa/payment/backend/dev:dev-764aef9

• Kaniko Image (fully qualified with digest) gcr.io/kaniko-project/executor@sha256:b44b0744b450e731b5a5213058792cd8d3a6a14c119cf6b1f143704f22a7c650

• Kaniko logs

• Real container contents

Triage Notes for the Maintainers

Description	Yes/No
Please check if this a new feature you are proposing	- No
Please check if the build works in docker but not in kaniko	- Yes
Please check if this error is seen when you use --cache flag	- Yes
Please check if your dockerfile is a multistage dockerfile	- No, but when multistage behavior is the same

[teklabania]

Same here. mkdir has no effect in RUN.

Kaniko image: gcr.io/kaniko-project/executor:debug@sha256:3bc3f3a05f803cac29164ce12617a7be64931748c944f6c419565f500b65e8db

Image used in Dockerfile: debian:11-slim

[very-doge-wow]

I've got a similar issue, however not when creating directories but when installing bash. Maybe it's related (and maybe not, idk): https://github.com/GoogleContainerTools/kaniko/issues/2177

[xenon-dev]

Similar issue here, after creating the base image, all further dockerfile commands are run as root, in the end we switch to a non-root user. Pod crashes with mkdir write permission errors.

We used a Kaniko implementation on GitLab.com before (were it worked perfectly) and are now on ArgoWorkflows and deploy with argoCD, instead of helm. GitLab.com must have made a serious effort to make Kaniko run smooth on the plattform (see 'entrypoint' adaptations here.)

Difference between Kaniko in GitLab.com and Argo is the entrypoint and the way the cloud information are given to Kaniko (echo oneliner vs. volumemount), but still: Some stuff under the hood must have been adapted hard to make it work.
In our tests the Kaniko Image build on Argo ist 100mb bigger (normally around 600mb+, now 700mb+). Caching was always turned off, SnapshotMode=full, --new-run=off.

Base Image: https://github.com/accetto/ubuntu-vnc-xfce-g3 Base Image Repo: https://hub.docker.com/r/accetto/ubuntu-vnc-xfce-g3

Dockerfile_Layers.txt

[emeric-martineau]

Hi, same issue when I create a folder:

RUN mkdir -p /blaba/

or create an empty file with touch (work if I use echo '' > /toto):

RUN touch /toto