# Plesk “Unable to connect to database”: PleskDBException Fix

Source: https://srvscripts.com/guides/plesk-unable-to-connect-database/
Updated: 2026-10-07
Publisher: srvScripts (https://srvscripts.com/)

**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.

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](https://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):

```
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](https://support.plesk.com/hc/en-us/articles/12377017328791-Unable-to-access-Plesk-interface-Access-denied-for-user-admin-localhost-using-password-NO) 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](https://support.plesk.com/hc/en-us/articles/12377966359319-Unable-to-access-Plesk-GUI-Access-denied-for-user-admin-localhost-using-password-YES) 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](https://docs.plesk.com/en-US/obsidian/administrator-guide/plesk-administration/plesk-repair-utility.74649/) 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](https://docs.plesk.com/en-US/obsidian/administrator-guide/plesk-administration/plesk-repair-utility/plesk-repair-utility-plesk-database.74665/), 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](https://support.plesk.com/hc/en-us/articles/12377801985047) 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](https://support.plesk.com/hc/articles/12377798484375) 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](/guides/runbook-mysql-crashed/) 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](https://support.plesk.com/hc/en-us/articles/12377932978839-Unable-to-access-Plesk-Unknown-database-psa) 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

- The service is up and enabled: `systemctl is-active mariadb` and `systemctl is-enabled mariadb`.

- Plesk can query its database: `plesk db "SHOW TABLES FROM psa" | head` returns table names without an error.

- The database is consistent: `plesk repair db -n; echo $?` ends with `0`.

- The panel loads at `https://SERVER-IP:8443` and you can open a subscription.

- Websites that use MariaDB load, and there is enough free disk space to keep it that way (`df -h`).

- 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](/get-it-fixed/) service handles Plesk database recoveries.

**Official documentation:** [Plesk: MariaDB stopped (2002)](https://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) · [Plesk: Access denied for admin (YES)](https://support.plesk.com/hc/en-us/articles/12377966359319-Unable-to-access-Plesk-GUI-Access-denied-for-user-admin-localhost-using-password-YES) · [Plesk Repair Utility](https://docs.plesk.com/en-US/obsidian/administrator-guide/plesk-administration/plesk-repair-utility.74649/) · [Plesk: fix InnoDB corruption on Linux](https://support.plesk.com/hc/articles/12377798484375)

**Related:** [MySQL/MariaDB won’t start: crash recovery runbook](/guides/runbook-mysql-crashed/) · [MySQL ERROR 1040 Too Many Connections: Fixes for cPanel](/guides/fix-mysql-too-many-connections-cpanel/) · [Plesk AlmaLinux 10: Supported Version and What Is Missing](/guides/plesk-almalinux-10/) · [Migrate Plesk to cPanel (and cPanel to Plesk): Tools and Limits](/guides/migrate-plesk-to-cpanel/) · [MySQL Health Snapshot Script: Free 10-Second MariaDB Check](/scripts/mysql-health-snapshot/)

**See also:** [Plesk AlmaLinux 10: Supported Version and What Is Missing](/guides/plesk-almalinux-10/) · [Migrate Plesk to cPanel (and cPanel to Plesk): Tools and Limits](/guides/migrate-plesk-to-cpanel/) · [cPanel vs Plesk (2026): Which Control Panel for Hosting?](/guides/cpanel-vs-plesk/)

## Frequently asked questions

### What does “Unable to connect to database” mean in Plesk?

Plesk could not connect to its own psa database on the local MariaDB or MySQL server. The rest of the message says why: the service is down (2002), the admin password does not match (1045), there are too many connections (1040), or the database is missing or corrupted.

### Where is the Plesk database password stored?

In /etc/psa/.psa.shadow, encrypted. It must be owned by psaadm. Do not print or share it; plesk db connects with it for you.

### Is plesk repair db safe to run?

Run it with -n first, which only reports problems. Without -n it asks before each change, and according to Plesk it creates a dump of the database before correcting inconsistencies.

### Can a full disk cause the Plesk database error?

Yes. If the partition holding /var/lib/mysql is full, MariaDB can fail to start or stop accepting writes, and Plesk reports that it cannot connect. Free space, then start the service.

### How do I restore the Plesk psa database?

Use the nightly dumps in /var/lib/psa/dumps. Extract only the psa section of the newest good dump and import it with plesk db, as described in Plesk’s “Unknown database psa” article. Changes made after that dump are lost from the panel.