chmod not working correctly in Docker

Solution 1:

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.

Solution 2:

Try adding :

USER root

It worked for me.

---

Solution 3:

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

---

Solution 4:

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.