Persistent Configuration Issues with Virtualmin-Managed Email, User Quotas, and DNS Records Causing Intermittent Failures and Inconsistencies Across Multiple Services Despite Correct Initial Setup

I am experiencing a persistent and perplexing issue with my Virtualmin-managed server that seems to affect multiple core services, primarily email delivery, DNS management, and user quotas. The setup initially appears correct: all virtual servers are created, email domains are configured, Postfix and Dovecot show active status, and DNS records appear correct according to the Virtualmin interface. However, after some hours or days, I notice that email delivery starts failing intermittently, user quotas are reported incorrectly, or certain DNS records are missing or reverted to defaults without any manual intervention. This inconsistency is extremely frustrating because it undermines the reliability of the server and creates unpredictable behavior for users relying on email and other services.

One of the most confusing aspects is that the system logs do not provide a clear indication of why these failures are happening. Postfix logs sometimes show temporary failures with no clear reason, while Dovecot reports user quota limits that do not match the configured values in Virtualmin. Additionally, DNS queries occasionally fail or return outdated information even though the BIND service shows normal operational status. The discrepancy between what Virtualmin displays and what the services are actually doing makes troubleshooting very challenging, as it is unclear whether the issue is with Virtualmin’s internal configuration database, the underlying service daemons, or some interaction between them.

I have verified file permissions, ownership, and configuration files for Postfix, Dovecot, and BIND, and all seem consistent with Virtualmin’s expected structure. The email mailbox directories exist, DNS zone files are present, and service configuration files have not been manually modified. Despite this, quota reporting and delivery behavior remain inconsistent, suggesting that Virtualmin might not be correctly synchronizing its internal state with the system services. I have also attempted to force re-apply configurations using the “Re-Check Configuration” feature in Virtualmin, but the problem only temporarily resolves and then reappears without any apparent trigger.

Another concern is the behavior of Virtualmin’s scheduled tasks and automated maintenance scripts. Cron jobs that are supposed to update quotas, rebuild mailboxes, or reapply DNS templates sometimes appear to run successfully according to logs but do not actually make the expected changes. This makes me wonder if there is an underlying database corruption, race condition, or synchronization issue between Webmin, Virtualmin, and the system services. Additionally, I have noticed that creating new virtual servers or email users sometimes triggers these inconsistencies for existing servers, suggesting that Virtualmin might not be fully isolating configuration changes between accounts.

I have also tested server restarts, service reloads, and even Virtualmin upgrades, but the issue persists. The fact that these failures occur intermittently and without any clear pattern makes it extremely difficult to reproduce in a controlled way, which further complicates troubleshooting. Some users have reported similar issues on forums, but most examples relate to website hosting, whereas my problem seems entirely related to backend services like email, DNS, and user management. It is especially concerning in a production environment where reliable email delivery and accurate quota enforcement are critical for day-to-day operations.

please supply all the required information to your post. so we do not have to guess (OS, Vmin version, e.c.t) it is the best way to obtaining a result.

1 Like

That sounds like three different problems. I can’t imagine how they could be related (well, email could be quota-related, but that’ll be clear if you look at the errors in the logs), since they are all independent services/components. Virtualmin certainly isn’t automatically changing random things behind your back.

So, please focus on one specific problem per topic, provide your OS and version information, and the exact error and/or a few log entries relevant to that problem. Trying to solve several different problems is hunting ghosts. Get specific, and give us the information we need to help you troubleshoot it, and we’ll knock them all out real quick.

https://forum.virtualmin.com/guidelines

We have several troubleshooting guides telling where to find logs (often the journal on modern Linux systems) and errors, among other simple tests.

e.g. for mail:

Or web:

Or DNS:

With specific information about your system and the actual errors, I’m pretty confident all problems are simple to solve.

@joepollard6543 As @Stegan points out, we really do need this information. Best way is to use the icon at the top right of the dashboard. For all we know you are terribly out of date with you OS or WM/VM version or have whacked on a non Grade A supported distro until it appeared to work.

You should end up with something like this:

SYSTEM INFORMATION
OS type and version Debian Linux 11
Webmin version 2.610
Usermin version 2.510
Virtualmin version 7.50.2 GPL
Theme version 26.20
Apache version 2.4.66
Package updates 1 package update is available
1 Like

A bit off-topic and would understand if this reply is deleted, but I need to know:
Is the title of this post LLM generated?

I guess we’ll find out on follow-ups. Sometimes folks use LLMs for translation from their native tongue, which is fine and not a violation of our guidelines, so I don’t want to assume ill intent. But talking about a bunch of different problems in one topic is a problem and needs to be addressed before we can do anything to help. There’s no way I can follow a thread with literally countless vague problems with no errors, no log entries, and no specific details about anything.

I understand your point about treating these as separate issues rather than trying to connect everything into one root cause. I’ll narrow this down and open a follow-up focusing on a single, concrete problem (starting with the mail delivery failures), and include OS/version details along with relevant Postfix and Dovecot log entries from the journal. I’ll also go through the troubleshooting guides you linked to make sure I’m checking the right places before posting. Appreciate the direction on how to approach this more effectively. :slightly_smiling_face:

2 Likes