Error during restore when transferring domains to EL10 system

Virtualmin
1
SYSTEM INFORMATION
OS type and version EL9 and EL10
Webmin version 2.621
Virtualmin version 8
Webserver version Apache

I have been transferring domains from old EL9 VMin server to a new EL10 server.

So far 26 have transferred fine, but 2 have failed in the restore stage.
One is small, one user pretty much a parked domain. I could create it again if need be.
Other is email only (web hosted elsewhere), 12 users a couple are very busy with email.
So, totally different domains, no pattern.
This the error message during restore:

[06/Feb/2026:01:22:22 +1030] Failed to regenerate table /etc/aliases: postalias: warning: unsupported dictionary type: hash. Is the postfix-hash package installed? postalias: fatal: unsupported map type: hash 
Error
-----
Failed to regenerate table /etc/aliases: postalias: warning: unsupported dictionary type: hash. Is the postfix-hash package installed?
postalias: fatal: unsupported map type: hash

Postfix on EL10 has moved away from hash to LMDB and I have had to make edits to postfix for it to work anyway in VMin 8.

1 Like
2

Just checking the larger domain on the new server.
Only 4 users on the VMin domain list screen.
Logged into one of those users, went to Usermin, got this:
Failed to create /home/domain/homes/general/.usermin/mailbox : Permission denied
Looked at the file structure,
/home/domain/homes/ the users are number:domain instead of user:domain so a UID error perhaps?

On the smaller domain, I went to create manually on new server and was told the database already existed. It did and was empty so I deleted it.
Then went back to old VMin deleted the only user and the transfer worked.

3

I tests today using a domain with 10 email users and total size 3.5Gb
Old VMin server, EL9, VMin 8.
New VMin server EL10, VMin 8 - Transfer failed.
Test VMin server EL9, VMin 8 - Transfer succeeded.

Transfer to New was tried both before and after the VMin 8.0.1 update
Transfer to Test was only done after update to VMin 8.0.1

So, problem with changes to EL10
This is interesting part of the log:
Re-creating virtual server Domain.tld ..
Re-allocating user and group IDs ..
.. allocated user ID is 1122 and group ID is 1050

Yet when I look on New server the users are 1422:domain, 1423:domain etc.
This may not by why the transfer fails, but means that Usermin can’t create folders for the 2 users that show on VMin User List.

This is full log for the fail:

root@ NEW’s password:
Checking for missing features ..
.. all features in backup are supported

Checking for errors in backup ..
.. no errors found

Starting restore..
Extracting backup archive files ..
.. done

Re-creating virtual server Domain.tld ..
Re-allocating user and group IDs ..
.. allocated user ID is 1122 and group ID is 1050

[07/Feb/2026:01:25:39 +1030] Failed to work out externally visible IPv6 address
Saving server details ..
.. done

Creating administration group domain ..
.. done

Creating administration user domain ..
.. done

Creating aliases for administration user ..
.. done

Adding administration user to groups ..
.. done

Creating home directory ..
.. done

Creating mailbox for administration user ..
.. done

Adding to email domains list ..
.. done

Adding default mail aliases ..
.. done

Adding new virtual website ..
.. done

Adding webserver user apache to server's group ..
.. done

Performing other Apache configuration ..
.. done

Creating SSL certificate and private key ..
.. done

Adding new SSL virtual website ..
.. done

Setting up log file rotation ..
.. done

Creating MariaDB login ..
.. done

Creating Webmin user ..
.. done

Saving server details ..
.. done

Applying webserver configuration ..
.. done

Restarting PHP-FPM 8.3 server ..
.. done

Re-loading Webmin ..
.. done

Re-starting Usermin ..
.. done

Restarting mail server ..
.. done

Updating Webmin user ..
.. done

Re-loading Webmin ..
.. done

Reloading PHP-FPM 8.3 server ..
.. done

Restoring backup for virtual server Domain.tld ..
Restoring virtual server password, quota and other details ..
.. done

Updating administration password and quotas ..
.. done

Restoring Cron jobs ..
.. done

Extracting TAR file of home directory ..
.. done

Setting ownership of home directory ..
.. done

Restoring Apache virtual host configuration ..
.. done

Checking restored PHP execution mode ..
.. mode FPM works for this system

Updating PHP-FPM configuration ..
.. no fixes needed

Changing CGI scripts execution mode to FCGIwrap server ..
.. done

Restoring Apache log files ..
.. done

Restoring SSL Apache virtual host configuration and certificate ..
.. done

Restoring Logrotate configuration ..
.. done

Restoring allowed MariaDB hosts ..
.. done

Re-loading MariaDB database Domain ..
    Creating MariaDB database Domain ..
    .. done

.. done

Restoring Webmin ACL files ..
.. done

Re-creating mail and FTP users ..

[07/Feb/2026:01:26:55 +1030] Failed to regenerate table /etc/aliases: postalias: warning: unsupported dictionary type: hash. Is the postfix-hash package installed? postalias: fatal: unsupported map type: hash
Error

Failed to regenerate table /etc/aliases: postalias: warning: unsupported dictionary type: hash. Is the postfix-hash package installed?
postalias: fatal: unsupported map type: hash

4

@Jamie, how are we handling this case? hash is no longer available on the newest OSes, and we set it to lmdb in the Virtualmin Config during installation to make it work correctly. Should that setting be respected, or will the restore try to use the old dictionary type from the backup?

5

I took a closer look, and I don’t see how that would be possible unless you include in the backup the Postfix main.cf which overwrites the main.cf on new system. If that’s the case, it’s expected not to work—don’t do it.

6

I exactly followed the docs:

Generate and transfer backups

On your current server, create a backup directory and back up all virtual servers using these commands:

mkdir /root/backups
virtualmin backup-domain --dest /root/backups/ --all-domains --all-features --newformat --all-virtualmin

Transfer the backups to your new server with secure copy:

7

@Randomz That’s right—just manually edit your main.cf to use the correct dictionary type.

@Jamie, when we make a full backup we save virtualmin_mailserver_maincf—this is very risky and probably something we should never do.

Or, at least we should always refrain from restoring sender_dependent_default_transport_maps, smtp_tls_security_level, smtp_dns_support_level, smtp_host_lookup, alias_maps, alias_database, virtual_alias_maps, sender_bcc_maps and tls_server_sni_maps options because they are system dependent!

And, the restore should only restore the allowed options, except the ones mentioned, without simply overriding the config file.

8

After more testing I can confirm that it’s the restoring of virtualmin.tar.gz that is causing most of my problems with EL10.

In light of comments above in Ilia’s post, do you have something I can test or can I remove something from the tar.gz before doing the restore?

9

@Randomz, for now, before starting the restore process, you can deselect the “Mail server settings” option in the “Global settings” panel.

To be clear, this will skip restoring the following files and features:

virtualmin_mailserver_ratelimit
virtualmin_mailserver_grey
virtualmin_mailserver_dkim
virtualmin_mailserver
virtualmin_mailserver_maincf
virtualmin_mailserver_smtpd_tls_key_file
virtualmin_mailserver_smtpd_tls_cert_file
virtualmin_mailserver_dkimkey
virtualmin_mailserver_mastercf
virtualmin_mailserver_ratelimitconfig
virtualmin_mailserver_greyrecipients
virtualmin_mailserver_greyclients

So, you’ll need to enable and configure them manually in this case.

Alternatively, you could switch the source system to use the lmdb map type before creating a backup.

@Jamie, could you share your thoughts on it? I suggest we read the Postfix config file and selectively pick the options we want to migrate, rather than copying the whole file over!

10

I have been using this:

virtualmin restore-domain --source /root/backups/virtualmin.tar.gz --all-virtualmin
11

In this case you should use all features except mailserver, e.g.:

virtualmin restore-domain --source /root/backups/virtualmin.tar.gz --virtualmin config --virtualmin templates --virtualmin resellers --virtualmin email --virtualmin custom --virtualmin scripts --virtualmin scheds
12

It complained that there isn’t a section called resellers, though I can see it in the tar.gz
Not a problem for me as I don’t have resellers.

Just realised, it’s because I am using GPL for testing. Hence no resellers.

13

Yep. Resellers are clearly a feature used either by large organizations or by people making money with Virtualmin. So, that’s a feature unlikely to ever make it to GPL (though we’re considering a user model refactor that would make regular domain owner users more like resellers).

14

Yeah we could do that but it’s tricky to know which settings we should copy in that case. Maybe better to specifically exclude the problem settings?

15

Yes, like I mentioned we should set back the following Postfix options after copying config over:

sender_dependent_default_transport_maps , smtp_tls_security_level , smtp_dns_support_level , smtp_host_lookup , alias_maps , alias_database , virtual_alias_maps , sender_bcc_maps and tls_server_sni_maps.

16

Nice idea, I’ll look into adding this..

1 Like
Restore old server config to new server
17

At least the ones set in the GUI

18

If I run an EL9 based system will virtualmin always want to use postmap :hash?

Or can I migrate to lmdb and virtualmin be “aware” of it?

I think I should stay on legacy hash as virtualmin expects it? at least on a 9.7 install

19

Virtualmin does not “want” hash. OP restored their old configuration which used hash.

Virtualmin does not expect hash. If you don’t want to use hash maps, don’t restore a Postfix configuration that includes hash maps.

20

Virtualmin 8.1.0 should handle that correctly automatically.

1 Like