[bitnami/wordpress] Container does not start with Docker rootless

[MiltiadisKoutsokeras]

Name and Version

bitnami/wordpress:6

What architecture are you using?

amd64

What steps will reproduce the bug?

1. Host: AMD64 GNU/Linux Debian 11
2. Docker version: 20.10, Docker Compose version: v2.9.0
3. Create the following compose.yaml

services:
  database:
    image: docker.io/bitnami/mariadb:11.0
    ports:
      - "127.0.0.1:3306:3306/tcp"
    environment:
      MARIADB_MASTER_PORT_NUMBER: 3306
      MARIADB_ROOT_PASSWORD: mariadb_root_pass
      MARIADB_DATABASE: wordpress
      MARIADB_USER: wordpress_user
      MARIADB_PASSWORD: wordpress_pass

  wordpress:
    image: docker.io/bitnami/wordpress:6
    ports:
      - "127.0.0.1:8080:8080/tcp"
      - "127.0.0.1:8443:8443/tcp"
    depends_on:
      - database
    environment:
      WORDPRESS_USERNAME: test
      WORDPRESS_PASSWORD: test_pass
      WORDPRESS_DATABASE_HOST: database
      WORDPRESS_DATABASE_PORT_NUMBER: 3306
      WORDPRESS_DATABASE_NAME: wordpress
      WORDPRESS_DATABASE_USER: wordpress_user
      WORDPRESS_DATABASE_PASSWORD: wordpress_pass

4. Execute docker compose up.

What is the expected behavior?

The Docker containers start up and Wordpress site is available in http://localhost:8080.

What do you see instead?

Docker container for Wordpress site fails to start up. It seems that initialization scripts cannot remove files inside the folder /opt/bitnami/wordpress/wp-content due to permission errors. The command id inside the container returns uid=1001 gid=0(root) groups=0(root). 1001 is the user id on host that launches the docker compose command.

Additional information

Wordpress Docker container log:

wordpress 14:12:11.31 
wordpress 14:12:11.31 Welcome to the Bitnami wordpress container
wordpress 14:12:11.31 Subscribe to project updates by watching https://github.com/bitnami/containers
wordpress 14:12:11.31 Submit issues and feature requests at https://github.com/bitnami/containers/issues
wordpress 14:12:11.31 
wordpress 14:12:11.31 INFO  ==> ** Starting WordPress setup **
wordpress 14:12:11.32 INFO  ==> Generating sample certificates
Generating RSA private key, 4096 bit long modulus (2 primes)
....................................................................++++
..........................++++
e is 65537 (0x010001)
Signature ok
subject=CN = example.com
Getting Private key
realpath: /bitnami/apache/conf: No such file or directory
wordpress 14:12:11.58 INFO  ==> Configuring Apache ServerTokens directive
wordpress 14:12:11.59 INFO  ==> Configuring PHP options
wordpress 14:12:11.59 INFO  ==> Setting PHP expose_php option
wordpress 14:12:11.60 INFO  ==> Setting PHP output_buffering option
wordpress 14:12:11.91 INFO  ==> Validating settings in MYSQL_CLIENT_* env vars
wordpress 14:12:12.20 INFO  ==> Ensuring WordPress directories exist
wordpress 14:12:12.20 INFO  ==> Trying to connect to the database server
wordpress 14:12:17.22 INFO  ==> Configuring WordPress with settings provided via environment variables
wordpress 14:12:17.78 INFO  ==> Installing WordPress
wordpress 14:12:18.95 INFO  ==> Persisting WordPress installation
rm: cannot remove '/opt/bitnami/wordpress/wp-content/plugins/jetpack/extensions/blocks/cookie-consent': Directory not empty
rm: cannot remove '/opt/bitnami/wordpress/wp-content/plugins/jetpack/src': Directory not empty

[carrodher]

Bitnami containers are designed to operate as non-root by default. Consequently, any files or directories used by the application should be owned by the root group, as the random user (1001 by default) is a member of this root group. To ensure proper permissions, you'll need to adjust the ownership of your local directory accordingly.

For more comprehensive information about non-root containers and their significance for security, you can explore the following resources:

• Why non-root containers are important for security
• Use Non-Root Containers
• Work With Non-Root Containers for Bitnami Applications
• Running non-root containers on Openshift

These references provide valuable insights into the best practices and considerations when working with non-root containers in Bitnami applications.

[MiltiadisKoutsokeras]

Using a non-root/rootless Docker setup to launch the docker compose command with the attached compose.yaml reproduces the error. It seems there was effort made to make the containers run fron non-root host users, but the problem exists.

By the way, I am not mounting any volumes from local folders, I will try this also.

[MiltiadisKoutsokeras]

By adding volumes to compose YAML:

services:
  database:
    image: docker.io/bitnami/mariadb:11.0
    ports:
      - "127.0.0.1:3306:3306/tcp"
    environment:
      MARIADB_MASTER_PORT_NUMBER: 3306
      MARIADB_ROOT_PASSWORD: mariadb_root_pass
      MARIADB_DATABASE: wordpress
      MARIADB_USER: wordpress_user
      MARIADB_PASSWORD: wordpress_pass
    volumes:
      - ./bitnami_mariadb:/bitnami/mariadb

  wordpress:
    image: docker.io/bitnami/wordpress:6
    ports:
      - "127.0.0.1:8080:8080/tcp"
      - "127.0.0.1:8443:8443/tcp"
    depends_on:
      - database
    environment:
      WORDPRESS_USERNAME: test
      WORDPRESS_PASSWORD: test_pass
      WORDPRESS_DATABASE_HOST: database
      WORDPRESS_DATABASE_PORT_NUMBER: 3306
      WORDPRESS_DATABASE_NAME: wordpress
      WORDPRESS_DATABASE_USER: wordpress_user
      WORDPRESS_DATABASE_PASSWORD: wordpress_pass
    volumes:
      - ./bitnami_wordpress:/bitnami/wordpress

The database cannot start at all:

50295-database-1   | mariadb 08:44:19.32 
50295-database-1   | mariadb 08:44:19.32 Welcome to the Bitnami mariadb container
50295-database-1   | mariadb 08:44:19.32 Subscribe to project updates by watching https://github.com/bitnami/containers
50295-database-1   | mariadb 08:44:19.32 Submit issues and feature requests at https://github.com/bitnami/containers/issues
50295-database-1   | mariadb 08:44:19.33 
50295-database-1   | mariadb 08:44:19.33 INFO  ==> ** Starting MariaDB setup **
50295-database-1   | mariadb 08:44:19.35 INFO  ==> Validating settings in MYSQL_*/MARIADB_* env vars
50295-database-1   | mariadb 08:44:19.35 INFO  ==> Initializing mariadb database
50295-database-1   | mkdir: cannot create directory '/bitnami/mariadb/data': Permission denied
50295-database-1 exited with code 1
50295-wordpress-1  | wordpress 08:44:19.76 
50295-wordpress-1  | wordpress 08:44:19.76 Welcome to the Bitnami wordpress container
50295-wordpress-1  | wordpress 08:44:19.76 Subscribe to project updates by watching https://github.com/bitnami/containers
50295-wordpress-1  | wordpress 08:44:19.76 Submit issues and feature requests at https://github.com/bitnami/containers/issues
50295-wordpress-1  | wordpress 08:44:19.76 
50295-wordpress-1  | wordpress 08:44:19.77 INFO  ==> ** Starting WordPress setup **
50295-wordpress-1  | wordpress 08:44:19.79 INFO  ==> Generating sample certificates
50295-wordpress-1  | Generating RSA private key, 4096 bit long modulus (2 primes)
50295-wordpress-1  | ................................................................................................................................................................................................................................................................................................................................................................................................++++
50295-wordpress-1  | ...............................++++
50295-wordpress-1  | e is 65537 (0x010001)
50295-wordpress-1  | Signature ok
50295-wordpress-1  | subject=CN = example.com
50295-wordpress-1  | Getting Private key
50295-wordpress-1  | realpath: /bitnami/apache/conf: No such file or directory
50295-wordpress-1  | wordpress 08:44:21.24 INFO  ==> Configuring Apache ServerTokens directive
50295-wordpress-1  | wordpress 08:44:21.27 INFO  ==> Configuring PHP options
50295-wordpress-1  | wordpress 08:44:21.27 INFO  ==> Setting PHP expose_php option
50295-wordpress-1  | wordpress 08:44:21.29 INFO  ==> Setting PHP output_buffering option
50295-wordpress-1  | wordpress 08:44:21.61 INFO  ==> Validating settings in MYSQL_CLIENT_* env vars
50295-wordpress-1  | wordpress 08:44:21.66 WARN  ==> Hostname database could not be resolved, this could lead to connection issues
50295-wordpress-1  | wordpress 08:44:22.42 INFO  ==> Ensuring WordPress directories exist
50295-wordpress-1  | wordpress 08:44:22.42 INFO  ==> Trying to connect to the database server
50295-wordpress-1  | wordpress 08:45:22.61 ERROR ==> Could not connect to the database
50295-wordpress-1 exited with code 1

The MariadDB image is marked as non-root in the link you shared.

[MiltiadisKoutsokeras]

Using Podman to launch the containers showcases a similar error:

podman network create github-issue-50295

podman run --detach --network github-issue-50295 --name database  \
-p 3306:3306 \
--env MARIADB_MASTER_PORT_NUMBER=3306 \
--env MARIADB_ROOT_PASSWORD=mariadb_root_pass \
--env MARIADB_DATABASE=wp_langaware_db \
--env MARIADB_USER=wp_langaware  \
--env MARIADB_PASSWORD=wp_langaware_pass \
docker.io/bitnami/mariadb:11.0

podman run --network github-issue-50295 --name wordpress  \
-p 8080:8080 -p 8443:8443 \
--env WORDPRESS_USERNAME=langaware \
--env WORDPRESS_PASSWORD=langaware_pass \
--env WORDPRESS_DATABASE_HOST=database \
--env WORDPRESS_DATABASE_PORT_NUMBER=3306 \
--env WORDPRESS_DATABASE_NAME=wp_langaware_db \
--env WORDPRESS_DATABASE_USER=wp_langaware \
--env WORDPRESS_DATABASE_PASSWORD=wp_langaware_pass \
docker.io/bitnami/wordpress:6

Output:

wordpress 11:39:57.57 
wordpress 11:39:57.57 Welcome to the Bitnami wordpress container
wordpress 11:39:57.57 Subscribe to project updates by watching https://github.com/bitnami/containers
wordpress 11:39:57.57 Submit issues and feature requests at https://github.com/bitnami/containers/issues
wordpress 11:39:57.58 
wordpress 11:39:57.58 INFO  ==> ** Starting WordPress setup **
wordpress 11:39:57.61 INFO  ==> Generating sample certificates
Generating RSA private key, 4096 bit long modulus (2 primes)
..........................................................................................................................++++
...++++
e is 65537 (0x010001)
Signature ok
subject=CN = example.com
Getting Private key
realpath: /bitnami/apache/conf: No such file or directory
wordpress 11:39:58.13 INFO  ==> Configuring Apache ServerTokens directive
wordpress 11:39:58.17 INFO  ==> Configuring PHP options
wordpress 11:39:58.17 INFO  ==> Setting PHP expose_php option
wordpress 11:39:58.19 INFO  ==> Setting PHP output_buffering option
wordpress 11:39:58.53 INFO  ==> Validating settings in MYSQL_CLIENT_* env vars
wordpress 11:39:59.86 INFO  ==> Ensuring WordPress directories exist
wordpress 11:39:59.86 INFO  ==> Trying to connect to the database server
wordpress 11:39:59.94 INFO  ==> Configuring WordPress with settings provided via environment variables
wordpress 11:40:00.93 INFO  ==> Installing WordPress
wordpress 11:40:10.80 INFO  ==> Persisting WordPress installation
rm: cannot remove '/opt/bitnami/wordpress/wp-content/plugins/jetpack/extensions/blocks/cookie-consent': Directory not empty
rm: cannot remove '/opt/bitnami/wordpress/wp-content/plugins/jetpack/src': Directory not empty

Adding volumes (--volume mariadb_data:/bitnami/mariadb and --volume wordpress_data:/bitnami/wordpress respectively) does not change the behavior.

[MiltiadisKoutsokeras]

Update: the compose.yaml attached in this issue can be launched with root host user, if no host directory is mounted to the containers. If you add something like this:

volumes:
      - ./bitnami_wordpress:/bitnami/wordpress

to the wordpress container the process again fails due to permission error:

wordpress 08:08:27.06 
wordpress 08:08:27.06 Welcome to the Bitnami wordpress container
wordpress 08:08:27.06 Subscribe to project updates by watching https://github.com/bitnami/containers
wordpress 08:08:27.06 Submit issues and feature requests at https://github.com/bitnami/containers/issues
wordpress 08:08:27.06 
wordpress 08:08:27.06 INFO  ==> ** Starting WordPress setup **
wordpress 08:08:27.07 INFO  ==> Generating sample certificates
Generating RSA private key, 4096 bit long modulus (2 primes)
......................................................................................................................................................................................................++++
...++++
e is 65537 (0x010001)
Signature ok
subject=CN = example.com
Getting Private key
realpath: /bitnami/apache/conf: No such file or directory
wordpress 08:08:27.55 INFO  ==> Configuring Apache ServerTokens directive
wordpress 08:08:27.56 INFO  ==> Configuring PHP options
wordpress 08:08:27.56 INFO  ==> Setting PHP expose_php option
wordpress 08:08:27.57 INFO  ==> Setting PHP output_buffering option
wordpress 08:08:27.58 INFO  ==> Validating settings in MYSQL_CLIENT_* env vars
wordpress 08:08:27.68 INFO  ==> Ensuring WordPress directories exist
wordpress 08:08:27.68 INFO  ==> Trying to connect to the database server
wordpress 08:08:32.69 INFO  ==> Configuring WordPress with settings provided via environment variables
wordpress 08:08:33.19 INFO  ==> Installing WordPress
wordpress 08:08:34.26 INFO  ==> Persisting WordPress installation
cp: cannot create regular file '/bitnami/wordpress/wp-config.php': Permission denied

The ./bitnami_wordpress folder in the host is owned by root, so the container's non-root user cannot write into it.

[MiltiadisKoutsokeras]

There is something wrong with file ownership and permission in this container. Launching the container with Bash instead of the default entrypoint:

docker run --rm --tty --interactive --entrypoint /bin/bash bitnami/wordpress:6

showcases the following:

$ id
uid=1001 gid=0(root) groups=0(root)
$ id daemon
uid=1(daemon) gid=1(daemon) groups=1(daemon)
$ ls -la /bitnami/wordpress
total 8
drwxrwxr-x 2 daemon root 4096 Sep 27 01:24 .
drwxr-xr-x 3 root   root 4096 Sep 27 01:24 ..

So the wordpress files belong to daemon(1):root(0) although the run user is uid=1001 gid=0(root). Another strange behavior is that files in /opt/bitnami/wordpress/wp-content cannot be deleted with a single rm -rf command but require multiple tries:

$ rm -rf /opt/bitnami/wordpress/wp-content
rm: cannot remove '/opt/bitnami/wordpress/wp-content/plugins/w3-total-cache/vendor/aws/aws-sdk-php/src/Neptune': Directory not empty
rm: cannot remove '/opt/bitnami/wordpress/wp-content/plugins/all-in-one-seo-pack/vendor_prefixed/monolog/monolog/src/Monolog/Handler/Slack': Directory not empty
rm: cannot remove '/opt/bitnami/wordpress/wp-content/plugins/amp/vendor/ampproject/amp-toolbox/src/Dom': Directory not empty
rm: cannot remove '/opt/bitnami/wordpress/wp-content/plugins/simple-tags/vendor/sabre/vobject/lib/Component': Directory not empty
rm: cannot remove '/opt/bitnami/wordpress/wp-content/plugins/wp-mail-smtp/vendor_prefixed/monolog/monolog/src/Monolog/Handler/Slack': Directory not empty
rm: cannot remove '/opt/bitnami/wordpress/wp-content/plugins/jetpack/modules/seo-tools': Directory not empty
rm: cannot remove '/opt/bitnami/wordpress/wp-content/plugins/jetpack/extensions/blocks/cookie-consent': Directory not empty
rm: cannot remove '/opt/bitnami/wordpress/wp-content/plugins/jetpack/src': Directory not empty
$ rm -rf /opt/bitnami/wordpress/wp-content
$ echo $?
0
$ ls -la /opt/bitnami/wordpress/wp-content
ls: cannot access '/opt/bitnami/wordpress/wp-content': No such file or directory

Seeing this completelly strange behavior, I am suspecting that this whole issue is deeper inside the Docker implementation of the filesystem driver. I cannot analyze it further, I will have to find a mitigation strategy.

[carrodher]

This seems to be a unique use case that might be challenging to replicate on our end, as it appears closely tied to your particular scenario. We are not able to manually reproduce this issue nor it is being detected in our automated tests.

As you rightly say, the user running the container is uid=1001, gid=0 root and the folders where this user needs to write are owned by the root group; this combination is enough for the application to work out of the box. Any modification in this sense can make the container to fail.

[MiltiadisKoutsokeras]

In case someone also has the same problem, here is a quick workaround to mitigate the problems:

1. Use a local folder with permissions 775 and ownership belonging to the user that launches docker compose
2. Mount the local folder as volume to the container folder /bitnami/wordpress.
3. Apply this patch to avoid file deletion problems during Wordpress setup:

+++ b/bitnami/wordpress/6/debian-11/prebuildfs/opt/bitnami/scripts/libpersistence.sh
@@ -99,7 +99,15 @@ restore_persisted_app() {
         # We use 'realpath --no-symlinks' to ensure that the case of '.' is covered and the directory is removed
         file_to_restore_origin="$(realpath --no-symlinks "${install_dir}/${file_to_restore_relative}")"
         file_to_restore_destination="$(realpath --no-symlinks "${persist_dir}/${file_to_restore_relative}")"
-        rm -rf "$file_to_restore_origin"
+        while true
+        do
+            # Fix issue https://github.com/bitnami/containers/issues/50295
+            if rm -rf "${file_to_restore_origin}"
+            then
+                info "Successfully deleted ${file_to_restore_origin}"
+                break
+            fi
+        done
         ln -sfn "$file_to_restore_destination" "$file_to_restore_origin"
     done
 }

For example:

wordpress:
    image: docker.io/bitnami/wordpress:6
    ports:
      - "127.0.0.1:8080:8080/tcp"
      - "127.0.0.1:8443:8443/tcp"
    depends_on:
      - database
    environment:
      WORDPRESS_USERNAME: langaware
      WORDPRESS_PASSWORD: langaware_pass
      WORDPRESS_DATABASE_HOST: database
      WORDPRESS_DATABASE_PORT_NUMBER: 3306
      WORDPRESS_DATABASE_NAME: wp_langaware_db
      WORDPRESS_DATABASE_USER: wp_langaware
      WORDPRESS_DATABASE_PASSWORD: wp_langaware_pass
    volumes:
      # Fix issue https://github.com/bitnami/containers/issues/50295
      - ./src/backend/opt/bitnami/scripts/libpersistence.sh:/opt/bitnami/scripts/libpersistence.sh:ro
      # Wordpress site content, permissions of ./bitnami_wordpress should be rwxrwxr-x
      - ./bitnami_wordpress:/bitnami/wordpress:rw

[github-actions]

This Issue has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thanks for the feedback.

[github-actions]

Due to the lack of activity in the last 5 days since it was marked as "stale", we proceed to close this Issue. Do not hesitate to reopen it later if necessary.