Skip to content

Article Title: Resolving Ownership Issues in a Linux-based Docker Container with PHP Service


In the midst of developing applications within our containerized environment on Linux using Docker, I encountered an issue that puzzled me – changing directory ownership inside my containers was not functioning as expected. Although colleagues successfully altered directories’ ownerships in their macOS and Windows setups, this specific problem only arose for us Linux users running Docker 20.10.25 on Ubuntu (version sha256:ab73f23a9843a55ca731c83532c9f1b95e738525c2a8437f58ed7c17d0cf245e).

The core of the dilemma was in a simple Dockerfile, which contained these commands:

FROM php:7.1.33-fpm AS base
RUN mkdir /home/www-data && \
    ls -ld /home/* && \
    usermod -d /home/www-data www-data && \
    ls -ld /home/* && \
    chown -R www-data:www-data /home/www-data && \
    ls -ld /home/* && \
    chmod -R 0777 /home/www-data && \
    ls -ld /home/*

When building the Docker image, this is what I observed in my output:

Step X/9 : RUN mkdir /home/www-data
 ---> Removing intermediate container XXXX...
---> bXXXXX (This step was successful)
(Here you see a directory created under `/home`)

Remaining steps showed the ownership of '/home/www-data' not changing after `RUN chown` command. The permission settings were always reverted back to default: 
```shell
drwxr-xr-x root     root   4096 Aug  17  8:52 /home/www-data
---> eXXXXX (After `RUN chown -R www-data:` command) This step failed to change permissions as expected.

On the contrary, when I run a similar Docker container on Windows or macOS using their respective versions of PHP and running with --no-cache, directory ownership changes correctly:

#8 [5/9] RUN ls -ld /home/*
#8 sha256:XXXXXXX (Timestamp)
...
drwxr-xr-x 2 www-data root   4096 Aug  17  8:39 /home/www-data
(Here directory ownership changes to `www-data`)

This discrepancy led me down a rabbit hole until I uncovered that my initial Docker installation was flawed. After uninstalling and reinstalling Docker Desktop for Linux by downloading the .deb package provided from their official site, chown started to work flawlessly as intended!

This issue served not only an eye-opening moment on how different environments can behave differently with containerized applications but also reinforced that even small details like Docker installation nuances could make a significant impact. It reminds us always in our development journey, troubleshooting is key to uncover the root of unexpected behaviors and learn more about working harmoniously within diverse ecosystems while maintaining robust application architecture consistency across various platforms (Linux/macOS/Windows).


Previous Post
Kubernetes worker node unable to connect to POD ne
Next Post
Ensuring Two Node Ports Share the Same External IP