Why Changing MariaDB Docker Passwords May Not Work

changing MariaDB environment variables in a Docker Compose file does not update passwords or users inside an existing database volume.

Those variables are initialization settings. MariaDB reads them when its data directory is empty. After the database has been created, the stored accounts and grants become the source of truth.

Why it happens

A database login can fail even when the username and password in Compose look correct. The container may still be using credentials created during an earlier initialization.

There is a second issue to check: the normal application user may have access to only the main database. Creating a separate test database does not automatically give that user permission to use it.

How to fix it safely

1. Confirm the exact test settings. Check the test database name, username, password, host, and port. Similar names are easy to mix up.

2. Connect with an administrative database account. Use the password that is currently stored in MariaDB, not merely the latest value in Compose.

3. Create the test database and a dedicated test user. Keep test access separate from the normal application account.

4. Grant access only to the test database. This keeps the test user from modifying production-like application data.

5. Run the test connection again. Clear cached application configuration first if the framework caches environment values.

A generalized SQL example looks like this:

CREATE DATABASE IF NOT EXISTS app_testing;
CREATE USER IF NOT EXISTS 'app_test'@'%'
    IDENTIFIED BY 'use-a-secure-password';
ALTER USER 'app_test'@'%'
    IDENTIFIED BY 'use-a-secure-password';
GRANT ALL PRIVILEGES ON `app_testing`.*
    TO 'app_test'@'%';

Common mistakes

• Cause: Compose was edited after the volume was created. Fix: change the account inside MariaDB, or intentionally recreate the volume only when its data can be discarded.

• Cause: the database exists, but the test user has no grant for it. Fix: grant privileges on the specific test database.

• Cause: the database name and username are nearly identical but not the same. Fix: compare each test configuration value exactly.

• Cause: the application still uses cached settings. Fix: clear its configuration cache before retrying.

Be careful with volumes

Deleting a database volume forces initialization to run again, but it also removes the stored databases. That is appropriate only for disposable local data with a backup or no need for recovery.

Limit the example account’s reach

The '%' host in the SQL example matches connections from any permitted host; it is not a network restriction. Use a narrower host where practical and keep the database port private. A dedicated test account still needs protection from accidentally pointing at the live application database.

When a MariaDB container reports a wrong password, check the existing volume and database grants before changing Compose again. The concrete next action is to verify the current account inside MariaDB and grant a dedicated test user access only to the test database.

Reference: MariaDB Docker initialization variables.