Docker LAMP tutorial with pragmatic permission handling

As you have probably already noticed, permission handling between Docker containers and host users can be a tricky issue. That is exactly the point where this Docker LAMP setup comes in.

The difference compared to many other LAMP containers is not some exotic architecture, but the way permissions are handled. In this LAMP setup, the Apache server automatically sets permissions to 777 when files are created. This happens through the use of umask. That makes it much easier to edit files on the host without root.

For this to work in the other direction as well - meaning the Apache server must be able to modify files that were created on the host inside the www directory - the group permissions have to be prepared properly. That is exactly what this guide is about.

The setup consists of:

- Apache/PHP for the application
- MariaDB for the database
- phpMyAdmin for database administration

1. Download and extract the ZIP file

First download the Docker LAMP archive and extract it into a directory:

LAMP-DOWNLOAD

unzip lamp.zip -d lamp
cd lamp

2. Adjust the path to the web directory in docker-compose.yml

In docker-compose.yml, the path to the local web server directory has to be adjusted. The relevant part is the volume of the Apache/PHP container.

Open the file:

nano docker-compose.yml

Example:

volumes:
  - /srv/docker/lamp/www/:/var/www/html/

3. Start Docker Compose

If the path is set correctly, the stack can be built and started:

sudo docker compose up -d --build

To verify:

sudo docker compose ps

4. Why permissions are especially important in this setup

The practical advantage of this setup is that Apache can create files with open permissions. That makes editing on the host much easier than with many other LAMP containers.

The problem shifts in the other direction, though: if files are created on the host and copied into the www directory, Apache must still be able to modify them later. For that to work, at least the group permissions have to be correct.

Therefore, after creating directories or files inside the www directory, their group ownership should be adjusted and, ideally, read and write permissions should be set right away.

Normally, the Apache server is started as a user with ID 33. Depending on the system, this ID 33 is usually named www-data or http.

4.1. Check the current owner and group

Before changing anything, you should first check who currently owns the webroot and which groups are set. This can be done in the terminal or in the file manager. In the terminal, the following commands are useful:

ls -ln /srv/docker/lamp/www
stat -c '%U %G %u %g' /srv/docker/lamp/www
getent group 33

If only IDs are shown instead of user or group names, that is a sign that the mapping on the host is not prepared properly yet.

4.2. Prepare the group with ID 33

The group ID should normally be 33. The group name is usually www-data, sometimes http. If this group does not yet exist on the host, it can be created together with the user:

sudo groupadd -g 33 www-data
sudo useradd -u 33 -g 33 -M -N www-data

After that, your own user should be added to the group:

sudo usermod -aG 33 "$USER"

If needed, the primary group can be changed for the current user in the current session.

newgrp www-data

If the group already exists, groupadd and useradd is not necessary. In that case it is enough to add the user to the existing group.

4.3. Adjust the group after copying files

If files are copied into or created inside the www directory, the group should then be changed to the Apache group so that the web server can work with them later:

sudo chgrp -R www-data /srv/docker/lamp/www

Optional check:

ls -ln /srv/docker/lamp/www

That ensures that files coming from the host do not suddenly become a problem for Apache.

5. Important note about server startup

Every time the server starts, the permissions of the entire www directory are reset. That is convenient locally, but it costs time as the amount of files grows.

Important to know:

- The more files are inside the www directory, the longer startup takes.
- This behavior comes from run.sh.
- chown and chmod are currently executed on the entire webroot there.

The relevant lines look like this:

chown -R www-data:www-data /var/www/html
chmod -R 777 /var/www/html

In theory, this behavior can be avoided by commenting out or adjusting these lines in run.sh. That makes the setup stricter, but also less convenient.

6. Result

If everything is prepared correctly, this setup gives exactly the advantage it was designed for:

- Apache can modify files inside the container
- the host user can work with the same files without a constant root detour
- local Joomla and PHP projects become much easier to maintain

This is not a production model, but a deliberately pragmatic development setup. For local work, exactly that compromise can make a lot of sense.