frappe_docker: pymysql.err.OperationalError: (1045, "Access denied for user 'root'@'172.19.0.6' (using password: YES)")

Found the issue! When following the single bench install instructions, the DB_ROOT_USER variable must remain on the default value of root in the .env file. This is because the mariadb image does not support changing the root username, and docker-compose.yml consequently does not set MariaDB’s root username to the DB_ROOT_USER value.

After deleting all of my volumes (with docker volume prune) and starting over with DB_ROOT_USER=root in .env, ERPNext is successfully installed.

The issue still exists. Local docker (swarm), using env.local, all volumes clean, mysql/mariadb root user name is ‘root’, all other components get deployed (not using traefik), site-creator fails when deployed from within docker-compose.yml because its unable to connect to the db - error is ‘access denied for user ‘root’, using password: yes’

However - the error seems to happen when site-creator is deployed from within the docker-compose.yml file - using ‘docker run’ from the command line works…!

Workaround that got the installation done for me:

• Comment out the entire site-creator service in docker-compose.yml, bring down the stack if already running
• Create an overlay network using: ‘docker network create --driver overlay --attachable <NW_NAME>’
• Specify the above network in the docker-compose.yml file:

networks:
  default:
    external: true
    name: <NW_NAME>

• Bring up the stack without site-creator
• Run the site-creator from the command line using ‘docker run’ - full command below:

docker run \
    -e "SITE_NAME=$SITE_NAME" \
    -e "DB_ROOT_USER=$DB_ROOT_USER" \
    -e "MYSQL_ROOT_PASSWORD=$MYSQL_ROOT_PASSWORD" \
    -e "ADMIN_PASSWORD=$ADMIN_PASSWORD" \
    -e "INSTALL_APPS=erpnext" \
    -v <project-name>_sites-vol:/home/frappe/frappe-bench/sites \
    --network ${NW_NAME} \
    frappe/erpnext-worker:$VERSION new

In the above command, NW_NAME should be the same you specified in step 1 and in docker-compose.

Basic principles behind the workaround:

• Site creator is not able to connect to mysql from within docker-compose, but can connect to mysql if run through docker run - I still dont know the reason for this, but all that we want is to get the instance up, while wiser folks look at the root cause…
• Trying to run site creator using docker run without an attachable network will fail since site creator cannot connect to the default overlay network created for the stack deployed through docker compose
• So we create an attachable network manually, tell docker to use this network when deploying the stack, and then run site creator manually from the command line

Hope that helps.

I had the same problem when I tried to install Frappe from docker-compose. Changing the environment simply using MARIADB_ROOT_PASSWORD instead of the MYSQL_ROOT_PASSWORD did the trick for me. db: image: mariadb:10.7.8 healthcheck: test: mysqladmin ping -h localhost --password=admin interval: 1s retries: 15 deploy: restart_policy: condition: on-failure command: - --character-set-server=utf8mb4 - --collation-server=utf8mb4_unicode_ci - --skip-character-set-client-handshake - --skip-innodb-read-only-compressed # Temporary fix for MariaDB 10.6 environment: MARIADB_ROOT_PASSWORD: "admin" # MYSQL_ROOT_PASSWORD: "admin" # MYSQL_ROOT_HOST: "%" volumes: - db-data:/var/lib/mysql

I made similar experiences as @jreduar. Either the password changed or the host ip changed. Inside the Frappe-bench container:

• Connect to mysql metatable with: mysql -h mariadb -u root -prootpass mysql
• Use select * from user; to identify user names.
• Change password with ALTER USER 'username'@'%' IDENTIFIED BY 'newpass';, eg. ALTER USER '_ab9080ba42f22828'@'%' IDENTIFIED BY 'password_from_site_config.json';
• If USER@HOST does not yet exist CREATE USER '_ab9080ba42f22828'@'%' IDENTIFIED BY 'password_from_site_config.json';
• Delete all other USER@HOST entries with DROP USER '_ab9080ba42f22828'@'172.20.0.4';
• Make sure the user has the priviliges for the database: GRANT ALL PRIVILEGES ON database_name.* TO 'username'@'localhost';, eg. GRANT ALL PRIVILEGES ON _41da75e60133e6ed.* TO '_41da75e60133e6ed'@'%';

I found the following, when the setup is done, the mariaDB user is set to another Host (or maybe change while build) and its rejected when the main container wants interact, so I had done the following to make it work:

• connect to the mariadb container and delete the user displayed inside the site_config.json at the main container (DROP USER)
• Create a new user with the credentials showed at the site_config.json ( CREATE USER, with the ‘%’ so all host fall into)
• Assign the privileges to that user for the db (GRANT)

Hope this helps

@revant can the issue be reopened as it seems it’s confirmed to still exist?

no news on this? The provided docker-compose file should be able to reproduce the issue.

I was also having this issue, and managed to track it down to the fact that WSL reads files in Windows as having global permissions (-rwxrwxrwx), so if you are using Docker Desktop on Windows 10, this might be a solution.

Upon booting, the mariadb container gives the following message:

Warning: World-writable config file '/etc/mysql/conf.d/frappe.cnf' is ignored

So what I did was:

1. Shutdown and delete the docker-compose project I had created for frappe;
2. Run docker volume prune, since it was a clean install and I had no data to keep (it might not be needed);
3. On WSL, cd to the path where you cloned the repo and cd installation + chmod a-wx frappe-mariadb.cnf (I have not tested other permission combinations);
4. Run docker-compose --project-name <project-name> up -d again.

If the warning isn’t present on the mariadb container logs, it should now work normally.

Windows 10 v2004 Docker Desktop with Docker Engine v20.10.5