Issue postalias fatal: open database virtual.lmdb: No such file or directory (Plesk 18.0.81.2, Ubuntu 26.04) - related to PPPM-15128?

[Fabian]

Server operating system version

Ubuntu 26.04.1

Plesk version and microupdate number

18.0.81 #2

Hello,

I'm seeing the following fatal error repeatedly (many times per day) in journalctl / mail log:

postfix/postalias[...]: fatal: open database /var/spool/postfix/plesk/virtual.lmdb: No such file or directory

Checked main.cf: default_database_type = hash, and all Plesk-managed map references (virtual_alias_maps, alias_maps, transport_maps, tls_server_sni_maps, etc.) explicitly use hash:/var/spool/postfix/plesk/... pointing to existing, working .db files. postconf -m confirms lmdb is supported by this Postfix build.

It looks like one of the Plesk mail management tools (mailmng-core and related binaries under /opt/psa/admin/sbin/) is invoking postalias with a hardcoded lmdb: prefix regardless of the actually configured default_database_type/map type, so it fails trying to open a .lmdb file that was never created (since the real maps are in hash format).

Practical impact so far: existing mailboxes/aliases work fine (the live hash: database is untouched), but this would presumably break adding/editing mailboxes or aliases via the Plesk panel, since the database rebuild step fails every time.

plesk repair mail -n -v reports 0 errors/warnings, so the repair tool doesn't seem to catch this.

This looks related to the known bug PPPM-15128 ("Postfix LMDB database file becomes corrupted"), but in my case the file is missing entirely rather than corrupted, and I'm already on a newer version (18.0.81.2) than the one where PPPM-15128 was supposedly fixed (18.0.75). Could this be a new variant of the same underlying issue, specific to fresh Ubuntu 26.04 installs?

Happy to provide more logs/details if useful.

 

[Sebahat.hadzhi]

Hi, @Fabian . I don't think this is a regression of PPPM-15128. For now, I configured a fresh Ubuntu 26 server and will attempt to replicate the error. I will let you know if I need some additional details.

 

[Sebahat.hadzhi]

Thank you for your patience, @Fabian . I have configured a test Ubuntu 26 server, but I was unable to replicate the behavior. On a fresh Plesk server, the mail maps in main.cf use the lmdb: type (for example virtual_alias_maps = ..., lmdb:/var/spool/postfix/plesk/virtual), and /var/spool/postfix/plesk/virtual.lmdb exists along with the other .lmdb files. With that said, I am wondering if in your case it is also a fresh Ubuntu server, an upgrade, migration, etc. and has the Postfix configuration been manually adjusted?
Also, could you please provide the output from the following:

postconf -n | grep -E "database_type|_maps"
ls -la /var/spool/postfix/plesk/

 

[Fabian]

Hi Sebahat,

Thanks for looking into this. Here's the requested output:

$ postconf -n | grep -E "database_type|_maps"
alias_maps = hash:/etc/aliases, hash:/var/spool/postfix/plesk/aliases
recipient_canonical_maps = tcp:127.0.0.1:12346
sender_dependent_default_transport_maps = hash:/var/spool/postfix/plesk/sdd_transport_maps
smtpd_discard_ehlo_keyword_address_maps = cidr:/etc/postfix/esmtp_cidr
tls_server_sni_maps = hash:/var/spool/postfix/plesk/certs
transport_maps = , hash:/var/spool/postfix/plesk/transport
virtual_alias_maps = $virtual_maps, hash:/var/spool/postfix/plesk/virtual
virtual_gid_maps = static:31
virtual_mailbox_domains = $virtual_mailbox_maps, hash:/var/spool/postfix/plesk/virtual_domains
virtual_mailbox_maps = , hash:/var/spool/postfix/plesk/vmailbox
virtual_uid_maps = static:30

$ ls -la /var/spool/postfix/plesk/
-rw-r--r-- 1 root root 12288 Sep 15 19:32 aliases.db
-rw-r--r-- 1 root root 12288 Sep 28 09:56 blacklists.db
-rw-r--r-- 1 root root 28672 Sep 15 19:31 certs.db
-rw-r--r-- 1 root root 28672 Jun 17 10:31 certs.db.bak
-rw-r--r-- 1 root root 36864 Oct 5 12:08 certs.lmdb
-r--rw---- 1 postfix root 36864 Sep 15 19:32 passwd.db
-r--r----- 1 postfix root 32 Sep 15 19:32 passwd_db_key
lrwxrwxrwx 1 root root 23 Sep 15 19:31 poplock.db -> ../plesk-pop/poplock.db
-rw-r--r-- 1 root root 12288 Sep 15 19:32 sdd_transport_maps.db
-rw-r--r-- 1 root root 12288 Sep 15 19:32 transport.db
-rw-r--r-- 1 root root 12288 Sep 15 19:32 virtual.db
-rw-r--r-- 1 root root 12288 Sep 15 19:32 vmailbox.db

So postconf shows hash: for all the virtual/alias maps, not lmdb: - and virtual.db exists and is current.

But this is not a one-off - checking my logs, the error happens dozens of times per day, every day, going back at least to Oct 2 (the day after I upgraded this box from Ubuntu 24.04 to 26.04 on Oct 1), right up through today:

postfix/postalias[...]: fatal: open database /var/spool/postfix/plesk/virtual.lmdb: No such file or directory
psa-pc-remote[...]: <queue-id>: check-quota: stderr: postalias: fatal: open database /var/spool/postfix/plesk/virtual.lmdb: No such file or directory

It's triggered by Plesk's own check-quota logic (shows up via psa-pc-remote and plesk-sendmail in the log line), which seems to call postalias against a hardcoded virtual.lmdb path regardless of what postconf actually has configured (hash:, not lmdb. So check-quota and the main Postfix map config appear to have drifted apart on which database format they expect.

Mail delivery itself keeps working (quota enforcement presumably just fails silently/no-ops when this lookup errors), so it's not visibly breaking anything, but it's clearly not supposed to error on every single message either. Happy to pull the actual check-quota script/command Plesk is invoking if that would help narrow down the cause - just let me know what to grab.

edit:
Quick follow-up - I dug a bit further and found the actual root cause:


/opt/psa/handlers/hooks/check-quota is a compiled, setuid-root ELF binary (not a script), and running strings on it shows the lmdb: map type is hardcoded inside it:

$ strings /opt/psa/handlers/hooks/check-quota | grep -i "lmdb\|postalias"
lmdb:/var/spool/postfix/plesk/aliases
lmdb:/var/spool/postfix/plesk/virtual
/usr/sbin/postalias

So check-quota always calls postalias against hardcoded lmdb: paths internally, completely independent of what main.cf actually has configured (hash: in my case). That's why it fails on every single invocation - the binary and the live Postfix config have simply drifted apart on expected map format. Looks like a genuine bug baked into the check-quota binary itself, presumably assuming every install has migrated to lmdb:-format maps, which clearly isn't universal.

 

[Sebahat.hadzhi]

Thank you for the provided details. Just so I have the full picture and attempt to replicate the potential bug - did you use Plesk's Ubuntu 24>26 dist-upgrade script?

 

[Fabian]

Hi Sebahat,

To answer your question: no, I did not use a Plesk-provided dist-upgrade script for the Ubuntu 24.04 → 26.04 jump — as far as I know, Plesk doesn't currently ship a dedicated tool for that specific version jump (only for 22.04 → 24.04).

What I actually did was the standard Ubuntu-native path:

1. Ubuntu's own do-release-upgrade (ran do-release-upgrade -c as a check a few times beforehand, then the actual upgrade)
2. Afterwards, plesk installer --select-release-current --upgrade-installed-components to let Plesk realign its own components/packages post-upgrade

So the sequence for anyone trying to reproduce this would be: OS upgrade via do-release-upgrade, then Plesk's own installer in component-upgrade mode — not any Plesk-specific OS dist-upgrade tooling, since none exists for this jump.

Let me know if you need the exact command history or timestamps around the upgrade — happy to provide more detail if it helps narrow down the check-quota/lmdb issue.

Thanks,Fabian

 

[Sebahat.hadzhi]

Thank you. I will attempt to replicate the behavior and cosult with our team further if needed. I will follow up with more details as soon as possible. Thank you for your patience in the meantime.