I thought about volumes, that is why I asked my last question, but just because of the files are on a volume, permissions shouldn’t be changed. In fact, when you have a volume, files are copied out from the container to the volume while keeping the permissions if there is any file in the folder you set as mount point as long as the volume folder on the host is empty. but the volume is used only when you start a container, not while building the image so how the image was built should not matter.
I do remember one thing though, which I could not explain later. I remember I tried to create a Docker image which had a volume definition in the Dockerfile (Now I think defining a volume in a Dockerfile is a bad idea and bad practice anyway) and depending on whether my commands wee before it or after it, it worked differently.
So I asked Gordon now specifically about how the legacy builder handled volume definitions and I got this:
When a
VOLUMEis declared in a Dockerfile, it creates a mount point and marks it as holding externally mounted volumes. However, any changes made to the data within the volume after it has been declared in the Dockerfile are discarded when using the legacy builder. This means that if you modify the contents of a volume during the build process, those changes will not be reflected in the final image when using the legacy builder.
I share it only becuse I experienced something like it once, but I can’t confirm that every statement is right in the quoted text. But let’s say it is true. Than if you define volume before you run a command that changes the permission, that could be lost. But it is not about permissions than but about any change in the folder that you define as a volume. In this case, you can move the volume definition to the end of the Dockerfile where I usually had those, so I guess that’s why I had the mentioned issue probably only once.
But the volume definition you refer to is not in your Dockerfile but was in the Dockerfile of the base image. Since you cannot undo a volume, if it was the problem, you won’t be able to solve it in the image.
You could create an entrypoint which does what I mentioned before as a possible cause of the issue. The entrypoint script could change the permissions when the container starts. Or you can create an init container and do it from another container as I described here:
If the init container is a dependency of the main containr, it could fix the permissions before the main container needs it.