Plesk “Unable to connect to database”: PleskDBException Fix

Short answer: Plesk keeps its own configuration in a MariaDB/MySQL database called psa, and “Unable to connect to database” means the panel could not reach it. In most cases the database service is stopped (often because the disk is full), the encrypted admin password in /etc/psa/.psa.shadow no longer matches or has the wrong owner, the server has run out of connections, or InnoDB has crashed. Read the exact error, start MariaDB and fix whatever stops it, then run plesk repair db and log in again.

Applies to Plesk Obsidian 18 on Linux

Commands checked against the official Plesk documentation and Plesk support articles (linked below) on 7 October 2026; not yet run on our lab servers (we do not have a Plesk lab yet).

“ERROR: PleskDBException: Unable to connect to database”: read the full message

The text after the first colon tells you which fix you need. Older Plesk versions print ERROR: PleskDBException: Unable to connect to database: …; Plesk Obsidian usually shows Server Error 500 Plesk\Exception\Database DB query failed: …. The causes are the same:

Message contains	Likely cause	Go to
SQLSTATE[HY000] [2002] No such file or directory or mysql_connect(): No such file or directory … (Error code: 2002)	MariaDB/MySQL is not running (or its socket is elsewhere)	Step 1 and 2
[1045] Access denied for user 'admin'@'localhost' (using password: YES) or saved admin password is incorrect	Password in .psa.shadow does not match the database	Step 3
[1045] Access denied for user 'admin'@'localhost' (using password: NO)	Wrong owner on .psa.shadow, so Plesk cannot read it	Step 3
SQLSTATE[08004] [1040] Too many connections	max_connections reached	Step 5
Unknown database 'psa', Incorrect information in file: './psa/misc.frm', InnoDB: Assertion failure	Missing or corrupted psa database / InnoDB crash	Step 6

If the browser only shows a generic 500 error without details, start with the database service: it is the most common cause.

Step 1: check the MariaDB or MySQL service

Connect over SSH as root. On AlmaLinux, Rocky and most current Ubuntu/Debian installs the service is mariadb; on servers with MySQL it is mysql (or mysqld on some RHEL builds):

systemctl status mariadb --no-pager
journalctl -u mariadb -n 50 --no-pager

If it is stopped and the log shows no obvious error, start it. This is the fix in Plesk’s 2002 support article:

systemctl start mariadb
systemctl is-active mariadb
systemctl enable mariadb

enable makes sure it starts after the next reboot, a common cause of this error on servers that were rebooted for updates. If the service starts and stays up, reload the panel. If it fails again within seconds, read the journal or the MariaDB error log before retrying: repeated restarts of a crashing InnoDB server can make the damage worse.

Step 2: rule out a full disk

MariaDB cannot start, or stops accepting writes, when the disk holding /var/lib/mysql is full. Check both space and inodes:

df -h /var/lib/mysql /var /tmp
df -i /var/lib/mysql
du -xsh /var/log/* /var/lib/psa/dumps 2>/dev/null | sort -h | tail

Free space by clearing old logs and backups you have copied elsewhere, not by deleting files inside /var/lib/mysql: removing ib_logfile0, ibdata1 or binary logs by hand can make every database unreadable. Then start MariaDB again (Step 1).

Step 3: fix the admin password file without printing it

Plesk connects to its database as the MySQL user admin. The password is stored, encrypted, in /etc/psa/.psa.shadow. Treat that file like a private key: do not cat it, paste it into tickets or chats, or copy it into scripts. You can check it safely with stat, which shows only owner and permissions:

stat -c '%U:%G %a %n' /etc/psa/.psa.shadow

“using password: NO”: wrong owner

Plesk’s support article for this case says the file must be owned by psaadm. If stat shows root:root (for example after a restore or a manual edit), fix it and restart the database service:

chown psaadm:psaadm /etc/psa/.psa.shadow
systemctl restart mariadb

“using password: YES”: password mismatch

The stored password no longer matches the admin user in MariaDB, often after someone changed it directly in SQL. If you know the MySQL admin password, Plesk’s procedure is: back up the file, write the password into it in plain text, then set the same password with Plesk’s utility so it is stored encrypted. This version reads the password without echoing it or saving it in your shell history:

cp -a /etc/psa/.psa.shadow /root/psa.shadow.bak-$(date +%F)
read -rs PSAPW
printf '%s\n' "$PSAPW" > /etc/psa/.psa.shadow
PSA_PASSWORD="$PSAPW" /usr/local/psa/admin/sbin/ch_admin_passwd
unset PSAPW
stat -c '%U:%G %a %n' /etc/psa/.psa.shadow

If you do not know the password, Plesk’s article describes resetting it with skip-grant-tables.

Warning: skip-grant-tables lets anyone who can reach MariaDB log in without a password. Block port 3306 from outside, keep the window short, and remove the line and restart MariaDB as soon as the admin user is fixed. Forgetting to remove it is a serious security hole.

Step 4: check the psa database with plesk repair db

Once MariaDB runs and Plesk can log in, check the psa database itself. The Plesk Repair Utility has a diagnostic mode (-n) that only reports, and a repair mode (-y) that fixes without asking:

plesk repair db -n
plesk repair db
plesk repair mysql -connection

Without -n or -y, the utility runs interactively and asks before each change. According to the db aspect documentation, if it finds inconsistencies it first creates a dump of the database and then tries to correct them. plesk repair mysql -connection checks that the database servers registered in Plesk are reachable. The utility exits with code 1 when it finds errors and 0 when there are only warnings or nothing at all, so echo $? after a run tells you the result.

Step 5: “Too many connections”

When every connection slot is used, both Plesk and websites fail. Plesk’s 1040 article checks the current limit with plesk db (which connects with the stored admin credentials), raises it at runtime, and then makes it permanent:

plesk db "SHOW VARIABLES LIKE 'max_connections'"
plesk db "SET @@GLOBAL.max_connections=300;"

To keep the value after a restart, add max_connections=300 under [mysqld] in /etc/my.cnf (RHEL family) or /etc/mysql/my.cnf (Debian/Ubuntu) and restart MariaDB. Raising the limit treats the symptom: find what holds the connections (a stuck site, a bot flood, slow queries) or the limit will fill again.

Step 6: InnoDB crash or missing psa database

If MariaDB will not start and its log shows InnoDB errors or an assertion failure, the data files are damaged. Plesk’s InnoDB corruption article lists two routes:

• Plesk Repair Kit (Plesk 18.0.63 and later): open https://SERVER-IP:8443/repair, log in with the admin credentials, run Check in the MariaDB/MySQL section and then Repair. Make sure there is free disk space first.
• Manual recovery: stop MariaDB, copy /var/lib/mysql to a safe place, start with innodb_force_recovery, dump the databases, re-create the data directory and import the dumps. Our MariaDB crash recovery runbook walks through the same steps.

Before any manual step: stop MariaDB and copy the whole data directory (cp -a /var/lib/mysql /root/mysql_backup, as in Plesk’s article). Recovery modes and re-initialising the data directory are destructive if something goes wrong.

Restoring psa from Plesk’s daily dump

If only psa is missing or damaged, Plesk keeps nightly dumps of its system databases in /var/lib/psa/dumps. Plesk’s “Unknown database psa” article finds the newest dump that contains psa and restores only that database from it:

cd /var/lib/psa/dumps
ls -l mysql.daily*
zgrep "Current Database:" mysql.daily* | grep psa

The daily dump holds several databases (not only psa). Restoring the whole file with zcat … | plesk db replaces all of them, including recent changes elsewhere. Extract only the psa section as shown in Plesk’s article, and if the current psa still exists, dump it first so you can go back.

plesk db dump psa > /root/psa-before-restore-$(date +%F).sql   # only if psa still exists (Plesk's documented dump command)
zcat mysql.daily.dump.0.gz | sed -n '/-- Current Database: `psa`/,/-- Current Database:*/p' | plesk db

Anything changed in Plesk since that dump (new subscriptions, mailboxes, DNS edits) will be missing from the panel afterwards, although the files on disk are still there. Run plesk repair all -n afterwards to see what no longer matches.

Check that it worked

1. The service is up and enabled: systemctl is-active mariadb and systemctl is-enabled mariadb.
2. Plesk can query its database: plesk db "SHOW TABLES FROM psa" | head returns table names without an error.
3. The database is consistent: plesk repair db -n; echo $? ends with 0.
4. The panel loads at https://SERVER-IP:8443 and you can open a subscription.
5. Websites that use MariaDB load, and there is enough free disk space to keep it that way (df -h).
6. No skip-grant-tables line is left: grep -ri skip-grant-tables /etc/my.cnf /etc/my.cnf.d /etc/mysql 2>/dev/null prints nothing.

Common problems

• MariaDB starts, then stops a few seconds later. It is crashing, not refusing to start. Read the error log; repeated InnoDB messages mean Step 6, not more restarts.
• Socket path mismatch (2002 while MariaDB is running). Something expects the socket in another place. Check where MariaDB puts it (socket in my.cnf) and fix the configuration rather than adding random symlinks.
• “using password: YES” returns after an update. A tool or person changed the admin password directly in SQL. Change it only through Plesk so .psa.shadow stays in sync.
• Plesk works but sites still fail. The panel and the sites share one MariaDB server. Check the site’s own database user and the error log, and run plesk repair mysql.
• Plesk for Windows. The steps differ: Plesk’s own MySQL runs on port 8306 and the admin password is read with plesk sbin psadb --get-admin-password. Follow the Windows sections of the linked articles.

If the server holds production sites and you would rather not experiment on it, our Get it fixed service handles Plesk database recoveries.

Official documentation: Plesk: MariaDB stopped (2002) · Plesk: Access denied for admin (YES) · Plesk Repair Utility · Plesk: fix InnoDB corruption on Linux

Related: MySQL/MariaDB won’t start: crash recovery runbook · MySQL ERROR 1040 Too Many Connections: Fixes for cPanel · Plesk AlmaLinux 10: Supported Version and What Is Missing · Migrate Plesk to cPanel (and cPanel to Plesk): Tools and Limits · MySQL Health Snapshot Script: Free 10-Second MariaDB Check

See also: Plesk AlmaLinux 10: Supported Version and What Is Missing · Migrate Plesk to cPanel (and cPanel to Plesk): Tools and Limits · cPanel vs Plesk (2026): Which Control Panel for Hosting?

Frequently asked questions

Maintenance record

This guide changes servers, data or security settings, so we re-check it against current versions on a fixed schedule. Take a backup or snapshot before you start.

Maintained by

srvScripts editorial team

Supported versions

Plesk Obsidian 18 on Linux

Last full review

7 Oct 2026

Next review

5 Apr 2027

Sources

support.plesk.com/hc/en-us/articles/14267287708055-Unable-to-access-Plesk-when-MySQL-MariaDB-database-server-service-is-stopped-SQLSTATE-HY000-2002-No-such-file-or-directory
support.plesk.com/hc/en-us/articles/12377017328791-Unable-to-access-Plesk-interface-Access-denied-for-user-admin-localhost-using-password-NO
support.plesk.com/hc/en-us/articles/12377966359319-Unable-to-access-Plesk-GUI-Access-denied-for-user-admin-localhost-using-password-YES
docs.plesk.com/en-US/obsidian/administrator-guide/plesk-administration/plesk-repair-utility.74649