chmod not working correctly in Docker

I'm building a Docker image for my Symfony app and I need to give permission to apache server to write into cache and log folders

#Dockerfile
FROM php:7-apache

RUN apt-get update \
&& apt-get install -y libicu-dev  freetds-common freetds-bin unixodbc \
&& docker-php-ext-install intl mbstring \
&& a2enmod rewrite

COPY app/php.ini /usr/local/etc/php/
COPY app/apache2.conf /etc/apache2/apache2.conf
COPY ./ /var/www/html

RUN find /var/www/html/ -type d -exec chmod 755 {} \; 
RUN find /var/www/html/ -type f -exec chmod 644 {} \;
RUN chmod -R 777 /var/www/html/app/cache /var/www/html/app/logs

When I build this image with docker build -t myname/symfony_apps:latest . and run the container with docker run -p 8080:80 myname/symfony_apps:latest. Apache log is flooded by permission denied errors , the strange thing that I've checked with ls -a and permissions are fine. and when I run chmod from container's bash , apache permission issues are gone and the app works well

The situation

Running chmod commands from dockerfile: permissions are changed but apache still complains about permission denied. Running chmod same commands with bash inside the container: permissions are changed and my app is running

Any idea , Am I missing something, maybe I should add root user somewhere in the Dockerfile ?

I had the same issue and it seems that there is some bug in docker or overlay2 if directory content is created in one layer and its permissions are changed in other.

As a workaround you could copy sources to temporary directory:

COPY . /src

And then move it to /var/www/html and setup permissions (in one RUN command):

RUN rm -rf /var/www/html && mv /src /var/www/html &&\
    find /var/www/html/ -type d -exec chmod 755 {} \; &&\
    find /var/www/html/ -type f -exec chmod 644 {} \; &&\
    chmod -R 777 /var/www/html/app/cache /var/www/html/app/logs

Also I created GitHub issue.

Try adding :

USER root

It worked for me.

The default shell of RUN in Docker is /bin/sh and this is where the permissions not being set correctly actually has a problem.

But you can change to just use /bin/bash instead to easily fix, notice before and after directory listing

Step 7/9 : RUN /bin/bash -c 'ls -la; chmod +x gitlab-properties-builder.sh; ls -la'
---> Running in dc57ae77aa67

drwxr-xr-x. 3 root root      103 Mar  8 17:56 .
drwxr-xr-x. 1 root root       46 Mar  8 17:57 ..
drwxr-xr-x. 2 root root        6 Mar  7 20:47 config
-rw-r--r--. 1 root root     2340 Mar  7 21:20 gitlab-properties-builder.sh
-rw-r--r--. 5 root root 57325770 Mar  5 14:39 gitlab-scm-collector-2.0.5-SNAPSHOT.jar

drwxr-xr-x. 1 root root       42 Mar  8 17:56 .
drwxr-xr-x. 1 root root       61 Mar  8 17:57 ..
drwxr-xr-x. 2 root root        6 Mar  7 20:47 config
-rwxr-xr-x. 1 root root     2340 Mar  7 21:20 gitlab-properties-builder.sh
-rw-r--r--. 5 root root 57325770 Mar  5 14:39 gitlab-scm-collector-2.0.5-SNAPSHOT.jar
---> 8b5de6e348d3

This issue is likely the result of a VOLUME definition inside the upstream Dockerfile. When a volume is defined in the Dockerfile, you can add files with a COPY or ADD command directly into the image. However, a RUN line will:

• Create a temporary container using the image definition as of the current point of the dockerfile
  • That temporary container will have an anonymous volume mounted as you or a parent image specified inside the Dockerfile
  • The anonymous volume will be initialized from the contents of the image
• Your command will run inside the container
  • If you list the directory during this RUN command, you will see your changes applied, but those changes have been applied to the volume
• When your run command completes, docker will capture the changes to the container
  • These changes can be seen with a docker diff if you do not delete the temporary containers (you can run a build with --rm=false to have them remain)
  • These changes will not include the anonymous volume contents because they do not exist inside the temporary container filesystem, volumes are separate

Because of this behavior, you have the options to:

1. you can copy your files to a different directory and change the permissions there
2. you can fix the permissions on your host so they get copied in with those permissions directly
3. you can remove the volume from either your image, get the upstream image to remove their volume definition, or you can rebuild your own copy of the upstream image without the volume definition and base your images off of that

Note that inside the current php images, it appears that the volume has been removed, which means we effectively have option 3.

I just made an experiment with the following:

FROM alpine

LABEL MAINTAINER="YIMGA YIMGA Salathiel Genèse"
RUN apk add --no-cache inotify-tools
CMD [ "./script.sh" ]
WORKDIR /opt/app/
COPY src/ /opt/app/
RUN chmod a+x *.sh

And it just works great.

However

When I override that executable file through docker-compose volumes, the execute permission is simply like rolled-back - technically overrode to original file permission.

The fix for dev mode is simply to chmod a+x yourfile from host, which will be inherited at compose volume mounting.