[bitnami/mariadb] Can't create/write to file './ddl_recovery.log' (Errcode: 13 "Permission denied")

[longester]

Name and Version

mariadb

What architecture are you using?

arm64

What steps will reproduce the bug?

after reboot it will show errors:

mariadb 10:07:26.86 INFO  ==> 
mariadb 10:07:26.86 INFO  ==> Welcome to the Bitnami mariadb container
mariadb 10:07:26.86 INFO  ==> Subscribe to project updates by watching https://github.com/bitnami/containers
mariadb 10:07:26.86 INFO  ==> Submit issues and feature requests at https://github.com/bitnami/containers/issues
mariadb 10:07:26.86 INFO  ==> Upgrade to Tanzu Application Catalog for production environments to access custom-configured and pre-packaged software components. Gain enhanced features, including Software Bill of Materials (SBOM), CVE scan result reports, and VEX documents. To learn more, visit https://bitnami.com/enterprise
mariadb 10:07:26.87 INFO  ==> 
mariadb 10:07:26.88 INFO  ==> ** Starting MariaDB setup **
mariadb 10:07:26.89 INFO  ==> Validating settings in MYSQL_*/MARIADB_* env vars
mariadb 10:07:26.90 WARN  ==> You set the environment variable ALLOW_EMPTY_PASSWORD=yes. For safety reasons, do not use this flag in a production environment.
mariadb 10:07:26.90 INFO  ==> Initializing mariadb database
mariadb 10:07:26.91 INFO  ==> Updating 'my.cnf' with custom configuration
mariadb 10:07:26.92 INFO  ==> Setting user option
mariadb 10:07:26.93 INFO  ==> Setting slow_query_log option
mariadb 10:07:26.94 INFO  ==> Setting long_query_time option
mariadb 10:07:26.95 INFO  ==> Using persisted data
mariadb 10:07:26.95 INFO  ==> Running mysql_upgrade
mariadb 10:07:26.96 INFO  ==> Starting mariadb in background
2024-07-20 10:07:27 0 [Note] Starting MariaDB 11.4.2-MariaDB source revision 3fca5ed772fb75e3e57c507edef2985f8eba5b12 as process 59
2024-07-20 10:07:27 0 [ERROR] mysqld: Can't create/write to file './ddl_recovery.log' (Errcode: 13 "Permission denied")
2024-07-20 10:07:27 0 [ERROR] DDL_LOG: Failed to create ddl log file: ./ddl_recovery.log
2024-07-20 10:07:27 0 [ERROR] Aborting
debian@debian:~$ 

What is the expected behavior?

No response

What do you see instead?

mariadb 10:07:26.86 INFO  ==> 
mariadb 10:07:26.86 INFO  ==> Welcome to the Bitnami mariadb container
mariadb 10:07:26.86 INFO  ==> Subscribe to project updates by watching https://github.com/bitnami/containers
mariadb 10:07:26.86 INFO  ==> Submit issues and feature requests at https://github.com/bitnami/containers/issues
mariadb 10:07:26.86 INFO  ==> Upgrade to Tanzu Application Catalog for production environments to access custom-configured and pre-packaged software components. Gain enhanced features, including Software Bill of Materials (SBOM), CVE scan result reports, and VEX documents. To learn more, visit https://bitnami.com/enterprise
mariadb 10:07:26.87 INFO  ==> 
mariadb 10:07:26.88 INFO  ==> ** Starting MariaDB setup **
mariadb 10:07:26.89 INFO  ==> Validating settings in MYSQL_*/MARIADB_* env vars
mariadb 10:07:26.90 WARN  ==> You set the environment variable ALLOW_EMPTY_PASSWORD=yes. For safety reasons, do not use this flag in a production environment.
mariadb 10:07:26.90 INFO  ==> Initializing mariadb database
mariadb 10:07:26.91 INFO  ==> Updating 'my.cnf' with custom configuration
mariadb 10:07:26.92 INFO  ==> Setting user option
mariadb 10:07:26.93 INFO  ==> Setting slow_query_log option
mariadb 10:07:26.94 INFO  ==> Setting long_query_time option
mariadb 10:07:26.95 INFO  ==> Using persisted data
mariadb 10:07:26.95 INFO  ==> Running mysql_upgrade
mariadb 10:07:26.96 INFO  ==> Starting mariadb in background
2024-07-20 10:07:27 0 [Note] Starting MariaDB 11.4.2-MariaDB source revision 3fca5ed772fb75e3e57c507edef2985f8eba5b12 as process 59
2024-07-20 10:07:27 0 [ERROR] mysqld: Can't create/write to file './ddl_recovery.log' (Errcode: 13 "Permission denied")
2024-07-20 10:07:27 0 [ERROR] DDL_LOG: Failed to create ddl log file: ./ddl_recovery.log
2024-07-20 10:07:27 0 [ERROR] Aborting
debian@debian:~$ ^C

Additional information

No response

[javsalgar]

Hi,

Did you change any default value? Just to understand if some extra configuration is the culprit

[maazmmd]

Facing similar issues

[javsalgar]

Hi,

Is this happening on a fresh installation?

[longester]

e0cde9c0f2afAfter the installation is complete, everything runs smoothly. However, after a reboot, issues arise, and it no longer works.

[juan131]

Hi everyone!

Could you please share the exact chart version you're using? Could you also provide the chart parameters (provided via values.yaml or using the --set flag) you used to install your Helm release? Please exclusively provide the parameters you customized avoiding the ones with default values.

Note: you can easily obtain the above parameters using helm get values RELEASE_NAME

[github-actions[bot]]

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.

[DenisKorkut-bcgov]

Seems to be an issue when using Helm 3.15.4 and potentially MariaDB chart version 12.2, then performing an helm upgrade on this.

The upgrade consists of only updating the values.yaml image tag only by updating the MariaDB image from 10.11.4-debian-11-r12->10.11.9-debian-12-r0. Then running helm upgrade bitnami/mariadb -f values.yaml

When using helm 3.15.4, the chart will upgrade to 19.0.5 and the upgrade fails and yields the "mysqld: Can't create/write to file './ddl_recovery.log' (Errcode: 13 "Permission denied")" error above.

When using Helm 3.12.1, the chart will upgrade to 14.1.4 - the upgrade will be successful, MariaDB runs fine.

Was able to reproduce this for a few different database instances.

[juan131]

Hi @DenisKorkut-bcgov

The chart version you upgrade to doesn't depend on whether you're using Helm 3.12.1 or 3.15.4, it depends on the latest version you have in the Helm repo cache. By running helm repo update, you'll update your local repositories and upgrading should target the latest version (which is 19.0.5 at this very moment), see:

$ helm repo update --help

Update gets the latest information about charts from the respective chart repositories.
Information is cached locally, where it is used by commands like 'helm search'.
(...)

Regarding the issue you're facing, it might be related with the changes we introduced at 17.0.0 that implied using a read-only filesystem, see:

• https://github.com/bitnami/charts/tree/main/bitnami/mariadb#to-1700

Take a look to the workaround documented on the section above.