sparkbox@sparkbox:/opt/sparkbox$ sudo docker inspect sb-nextcloud-db \ --format '{{range
Posted by cheetah959
My question: sparkbox@sparkbox:/opt/sparkbox$ sudo docker inspect sb-nextcloud-db \ --format '{{range .Config.Env}}{{println .}}{{end}}' \ | grep -E '^(MARIADBAUTOUPGRADE|MYSQLROOTPASSWORD|MARIADBROOTPASSWORD|MYSQLDATABASE|MYSQLUSER)=' \ | sed -E 's/(PASSWORD|PASS)=./\1=[REDACTED]/' MYSQLDATABASE=nextcloud MYSQLUSER=nextcloud MYSQLROOTPASSWORD=[REDACTED] SparkBox AI replied: That confirms it: text MARIADBAUTOUPGRADE is missing from the running container. The database was created with the normal MYSQL variables, but MariaDB’s healthcheck user setup was skipped. The root password isn’t the problem by itself — the healthcheck is falling back to a root login without credentials. Also, the compose file’s second check uses nextcloud, but MariaDB never reaches it because this part fails first: text healthcheck.sh --connect --innodbinitialized Don’t add the variable by hand to docker-compose.yml, and don’t delete the MariaDB data directory. SparkBox regenerates compose files, and the database appears intact. Run: bash sudo sparkbox upgrade If it reports an update, then: bash sudo sparkbox restart cloud If it says the box is already current, this needs a SparkBox-side Cloud compose fix. The evidence is now clear: - MariaDB starts normally. - InnoDB initializes. - MARIADBAUTOUPGRADE is absent. - The MariaDB image says upgrade/healthcheck-user creation was skipped. - The generated healthcheck then fails on …(reply truncated — full chat sent to Tom)
5 replies
Chris wrote:
Got it — this is an automatic acknowledgment from Chris, your AI support representative. Your post is in the support queue, and we’ll get to it as soon as we can. Legend members receive priority replies. If you’d like faster support while helping fund the project’s goals and continued development, consider becoming a Legend backer. <!-- chris-support-queue-ack:v1 --
Chris wrote:
I’m sorry, but the quoted AI reply treated one missing environment variable as proof of the cause without verifying the running healthcheck or the SparkBox compose definition. The current Cloud definition uses the MYSQL credentials and a two-part healthcheck; MARIADBAUTOUPGRADE is not evidence by itself. Please run this one read-only check on the SparkBox host and paste only the result, with passwords removed: sudo sparkbox logs sb-nextcloud-db | tail -30. Do not edit the compose file or delete the MariaDB data directory. I’ve corrected this guidance so an unverified database diagnosis is not repeated.
cheetah959 wrote:
2026-09-19 17:22:52 218 [Warning] Access denied for user 'root'@'localhost' (using password: NO) ^C2026-09-19 17:23:22 219 [Warning] Access denied for user 'root'@'localhost' (using password: NO) 2026-09-19 17:23:22 220 [Warning] Access denied for user 'root'@'::1' (using password: NO) 2026-09-19 17:23:22 221 [Warning] Access denied for user 'root'@'localhost' (using password: NO)
Chris wrote:
Thanks — those lines show MariaDB is rejecting a root healthcheck attempt that supplied no password, but they do not prove that the missing MARIADBAUTOUPGRADE variable caused it. Please do not edit the compose file or delete the database. Does the Cloud database currently show as healthy or unhealthy in the dashboard? That single status will tell us whether this is only noisy root-probe logging or an actual database startup failure. I’ve corrected the earlier diagnosis so the unverified environment-variable explanation is not repeated.
cheetah959 wrote:
currently shows as unhealthy