Both DB's failing with similar issue
mysql - 025-11-05T18:18:51.785885Z 0 [Warning] [MY-011068] [Server] The syntax '--skip-host-cache' is deprecated and will be removed in a future release. Please use SET GLOBAL host_cache_size=0 instead.

2025-11-05T18:18:51.785963Z 0 [System] [MY-013169] [Server] /usr/sbin/mysqld (mysqld 8.0.44) initializing of server in progress as process 80

2025-11-05T18:18:51.786940Z 0 [ERROR] [MY-010457] [Server] --initialize specified but the data directory has files in it. Aborting.

2025-11-05T18:18:51.786944Z 0 [ERROR] [MY-013236] [Server] The designated data directory /var/lib/mysql/ is unusable. You can remove all files that the server added to it

postgresql15 - initdb: error: directory "/var/lib/postgresql/data" exists but is not empty

initdb: hint: If you want to create a new database system, either remove or empty the directory "/var/lib/postgresql/data" or run initdb with an argument other than "/var/lib/postgresql/data".

initdb:
PostgreSQL Database directory appears to contain a database; Skipping initialization

Installed 7.2 upgrade from 7.1.2 a few days back and didn't notice these - perhaps they weren't an issue after what looked like a perfect upgrade.
Any help appreciated. Would like to keep existing data!

Edited November 5, 2025Nov 5 by comet48

verify your appdata location is in tact and read/writeable

if you're using zfs for your cache pool, see this thread: https://forums.unraid.net/topic/194091-720-rc1-sabnzbd-issue/

Not using zfs, and its read/writeable. I have an appdata backup from prior to the 7.2 upgrade. Would you suggest a restore from there?

Thanks

Edited November 5, 2025Nov 5 by comet48

I just noticed that both have UNKNOWN as owners.  An Issue?

1 hour ago, comet48 said:

Not using zfs, and its read/writeable. I have an appdata backup from prior to the 7.2 upgrade. Would you suggest a restore from there?

Thanks

I would be extremely cautious restoring databases if you didn't take a proper database backup using the proper procedures from the database documentation.

47 minutes ago, comet48 said:

I just noticed that both have UNKNOWN as owners.  An Issue?

No that generally is not an issue, appdata gets permissions set from the containers, changing them manually can break containers though.

Finally solved the problem by deleting both containers and restoring from previous Unraid 7.1.2 Appdata backup :(

Witch docker images?

I asked cuz if you're using bitnami those images are no longer in in the hub and the unraid upgrade can sometimes cause a repo or change in the docker volumes. Due to how the unreaid driver can be touched and upgraded. But it shouldn't stop existing images or data within the docker volume from running. Can you do a docker pole of your current MySQL and postgres image?

This kind of issue after an Unraid upgrade usually points to the database data directories not being picked up correctly by the containers, often due to permission or ownership changes. When MySQL/PostgreSQL see existing files but can’t access them properly, they try to re-initialize and then fail because the directory isn’t empty. I’d first double-check appdata paths, permissions, and make sure the containers are pointed to the original data folders. If you have logical backups (SQL dumps), restoring from those is always the safest route. However, if the raw MySQL data files themselves were damaged during the upgrade and the server won’t start at all, native recovery options are very limited in those cases you can try some third-party tools like Stellar Repair for MySQL can sometimes extract data from corrupted InnoDB files when standard restores don’t work.