I’m trying to set up seafile CE (v13) on my OMV server. Unfortunately, the setup of the seafile-mysql container fails, with these messages at the end of the log:
seafile-mysql | 2026-06-21 22:04:44 0 [Note] mariadbd: ready for connections.
seafile-mysql | Version: '10.11.18-MariaDB-ubu2204' socket: '/run/mysqld/mysqld.sock' port: 3306 mariadb.org binary distribution
seafile-mysql | 2026-06-21 22:04:58 3 [Warning] Access denied for user 'root'@'localhost' (using password: NO)
seafile-mysql | 2026-06-21 22:04:58 4 [Warning] Access denied for user 'root'@'::1' (using password: NO)
I essentially copied the .env file from the official website with very few modifications, so I’m very confused as to what is going on.
Checks I have done:
Verified that the .env file contains the lines SEAFILE_MYSQL_DB_PASSWORD=PASSWORD and INIT_SEAFILE_MYSQL_ROOT_PASSWORD=ROOT_PASSWORD
Verified that the db service in the compose yml contains the value MYSQL_ROOT_PASSWORD=${INIT_SEAFILE_MYSQL_ROOT_PASSWORD:-}
Following suggestions in another topic (called Docker update v13 database access deny), I verified environment variables from within the container, see below. However, note that unlike in the linked post, there is no SEAFILE_MYSQL_DB_PASSWORDvariable, its simply MYSQL_ROOT_PASSWORD=ROOT_PASSWORDhere.
And have you changed the password in your .env file after a previous failed attempt?
If this is a fresh installation and you changed the password in your .env file after a previous failed attempt, the database may have already been initialized with a different password (or no password). MariaDB only uses the MYSQL_ROOT_PASSWORD variable during the very first run when the data directory is empty.
To ensure a clean start:
Stop the containers: docker compose down
Warning: This will delete all existing data in the DB. Remove the database volume directory (default is /opt/seafile-mysql/db).
Yes, I modified the yml files, combining the 3 files into one. That’s because I prefer to run docker through my server’s web GUI, and it only accepts a single yml and single env file per stack. I could run it through CLI though.
other than that, I originally set different initial passwords. That failed, so I wiped all the volumes (including seafile-mysql/db) like you suggested, and tried again with the default passwords. The only things I changed now are the variables BASIC_STORAGE_PATH, SEAFILE_SERVER_HOSTNAME and JWT_PRIVATE_KEY, as well as the port caddy uses (changed to 8080, since 80 is in use already).
I attached the files below. (I realize that I’ll have to change sensitive info later.)
Could this somehow be related to what user is running docker?
The error message Access denied for user 'root'@'localhost' (using password: NO) in the seafile-mysql logs is a strong indicator that the healthcheck script defined in the db service is attempting to connect to MariaDB as root without providing a password.
In the provided compose.yml, the db service has a healthcheck using /usr/local/bin/healthcheck.sh. When MYSQL_ROOT_PASSWORD is set, this script may fail to authenticate if it doesn’t correctly pick up the password from the environment or if it tries to connect via TCP (as indicated by the ::1 warning) where the unix_socket plugin doesn’t apply.
The official yml also use /usr/local/bin/healthcheck.sh for health check. But I don’t know why it cannot work in your case.
Thank you for this update. I’m tracking down the issue. Indeed, it seems that the health check script is the issue: from within the container, I can log using mysql -u root -p and the password in $MYSQL_ROOT_PASSWORD. So at least we know that the DB is initialized correctly. Running the health check from within the container gives me this:
bash /usr/local/bin/healthcheck.sh --connect
Warning: World-writable config file '/var/lib/mysql/.my-healthcheck.cnf' is ignored
ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: NO)
Unknown error Warning: World-writable config file '/var/lib/mysql/.my-healthcheck.cnf' is ignored
ERROR 1045 (28000): Access denied for user 'root'@'::1' (using password: NO)
healthcheck connect failed
Perhaps it’s this config file that causes the issue. AI suggests changing the access rights. I’ll see what I can do about that, and come back with an update
I have solved the issue. The problem was that my data folders were located on an NTFS file system, which doesn’t support the typical Linux file permissions. Setting everything up on an ext4 partition solved the problem.