This document has been replaced by better organized and categorized documentation found at the following locations:
Installation Troubleshooting - Troubleshooting common installation problems.
Email Troubleshooting - Troubleshooting common email problems.
Website Troubleshooting - Troubleshooting common problems with web service.
Domain Name Server Troubleshooting - Troubleshooting common problems with domain name service.
Database troubleshooting - Troubleshooting common problems with databases in Virtualmin
Legacy Troubleshooting Common Problems
Virtualmin is a complex system, configuring dozens of unrelated services in order to provide a comprehensive web hosting experience, including web, mail, databases, multiple file transfer mechanisms, web applications, and an easy to use management interface for users of all levels and privileges. Sometimes things go wrong. This guide will try to help us help you figure out what.
Checking this guide before filing a new customer support issue in the bug tracker, or posting a question to the forums, can help get your problem resolved faster (or possibly help you resolve it without waiting for a reply). Even if the solution isn't contained within this document, you'll learn how to provide the information others will need to provide solutions.
Mail is perhaps the most complex component in a Virtualmin system, combining a mail transfer agent (usually Postfix, but optionally Sendmail or qmail), a mail delivery agent (usually procmail), POP3/IMAP retrieval (usually Dovecot), anti-virus (ClamAV), anti-spam (SpamAssassin), and mail log analysis (Virtualmin's built-in mail log analysis tools, and optionally logwatch and others). If any one of these components fails, mail may be completely broken for some or all tasks.
The first place to look for information about a mail problem is the relevant logs. On Red Hat, Fedora, CentOS, SUSE, and Mandriva systems, the majority of mail related logging is directed to
/var/log/maillog. Thus, you should check the contents of this log while attempting whatever action is giving you trouble. Most failed actions will result in a log action, possibly a very helpful one. The log
/var/log/secure may also contain information about failed login attempts, possibly including a reason.
On Debian and Ubuntu systems the mail log is called
/var/log/mail.log and will contain similar information as that found in the
/var/log/maillog mentioned previously. Debian/Ubuntu also has a
/var/log/mail.info which may or may not contain information, depending on the MTA in use and the configuration of
Many issues with mail can be traced back to incorrect DNS configuration. Check to be sure DNS works for the problem domain, and returns valid records. In particular, check the MX record and the name it points to to be sure other hosts can correctly look up the address of your server.
To test DNS resolution you can use the
For example, here's and example interaction checking the MX record for virtualmin.com:
# host -t mx virtualmin.com virtualmin.com mail is handled by 5 mail.virtualmin.com. # host mail.virtualmin.com mail.virtualmin.com has address 126.96.36.199
This first checks for a MX (mail exchange) record, and then checks to see what address that name resolves to. Mail servers must also reverse resolve in order to be able to deliver to a large number of mail servers on the Internet, as reverse resolution is used as a simple tool to reduce spam by ruling out many classes of dynamic address (like some dialup accounts). Reverse resolution can also be tested with host:
# host 188.8.131.52 184.108.40.206.in-addr.arpa domain name pointer e2.4.5646.static.theplanet.com.
Note that it doesn't matter what the server reverse resolves to. It just matters that it does resolve.
Note also that if you run these commands on your Virtualmin server, you aren't necessarily getting a complete picture of DNS. If your glue records at your registrar are incorrect, hosts other than the Virtualmin server will get completely different results from these commands (and they will also be unable to talk to your server, since they're looking for name information in the wrong place). You can use
whois to check your glue records, but that's beyond the scope of simple email troubleshooting. See the Webmin BIND documentation, particularly the BIND Troubleshooting Tools section.
Sometimes it can seem like you've hooked right into the firehose that is the Internet and spam is spewing directly into your mailbox without any limit. It may be, if SpamAssassin isn't configured correctly or procmail is broken in some way. To find out if your mail is being processed by the spam filter, look in the headers of a message received on your server. In Usermin or the Webmin Read Mail module, you can see the headers on a message by clicking the View Full Headers link in the upper right corner of the email. Most mail clients have some sort of option to allow you to see the raw message or the full headers.
If spam filtering is happening correctly, there will be one or more X-Spam-* headers within the header. If no such message appears, procmail or SpamAssassin may be disabled for domain or the user, or mis-configured.
This one is even easier to test. Write yourself an email with an attachment containing the EICAR test string. If it makes it to your mailbox, then AV scanning isn't working. If it doesn't, things are working fine.
The EICAR test string and information about it, can be found on the EICAR home page.
Many mail servers in the wild will reject email from a server without correct reverse resolution.
Reverse is different than forward resolution. The authoritative server is defined by the owner of the IP address (i.e. your hosting provider or network service provider). Usually, this is just setup to whatever the provider likes, and that's fine. It doesn't matter what name it resolves to, as long as it resolves to something.
Webmin handles reverse DNS zones--but it's out of the scope of Virtualmin, because Virtualmin would end up assigning a new name every time you created a new virtual server on a shared IP. By that, I mean that you create one reverse entry for every IP address--not one for every virtual host that lives on it. It's also not something we can automate away--it requires cooperation from your hosting or network provider, or whoever is authoritative for your IP addresses.
So, to add reverse DNS, you'll first have to figure out who is authoritative for your IP address(es), and ask them to do one of the following:
1. Provide a reverse entry for all of your IPs in their DNS servers.
2. Delegate the zone to your DNS servers. everydns.net probably does not provide reverse resolution services, so you'll need to point them to your Virtualmin server, fire up BIND, and create those entries.
You definitely want reverse lookups on your IP to work, as it's considered "spammy" by most spam filters and mail servers when it doesn't.
You can find out what name servers are currently responsible for a zone with:
Replacing 192.168.1.1 with your servers IP address, it will list lots of details about the IP, including the servers for the PTR records.
In most cases, if Usermin webmail does not include the correct From: address, it is incorrectly configured. The default was not being set correctly in our automated installer until recently due to a bug.
The old default would default to a From: address of the form "email@example.com", when it should instead be "firstname.lastname@example.org".
To correct this problem:
Browse to Webmin:Usermin Configuration:Usermin Module Configuration:Read Mail page
Locate the option labeled From: address mapping file, and set it to
Locate the option labeled Address mapping file format, and set it to
Address to username (virtusertable)
Problems with the web server are usually relatively easy to troubleshoot, but some common problems are tricky, because they aren't usually errors of configuration and so might not show up as reasonable errors in the
The first place to look for clues in any webserver problem is in the logs. Every virtual server or sub-server in Virtualmin has its own webserver log files. You can find them in the
logs directory in the virtual servers home directory. The
error_log is usually the most useful when troubleshooting, but the
access_log can contain clues
If you browse to one of your virtual server domain names and see the wrong site content, there is a mismatch between the NameVirtualHost and VirtualHost sections of your Apache configuration. This can happen if you've modified the Apache configuration file manually or using other tools, or used Webmin to make changes. Other sources of trouble are misconfiguring Virtualmin to use
* for the IP address (this can never work, as it will also break the DNS records, among other things).
Correcting this problem is as simple as making the IP address in the NameVirtualHost directives match the right VirtualHost directives.
There are several possible causes of this problem, and once corrected in the Apache configuration, you should also find the source of the incorrect configuration. It is likely to be found in the Virtualmin Module Configuration under the Other Server Settings category. Specifically, the following options could lead to incorrect IP addresses, or
* being used in the VirtualHost sections of your Apache configuration. Incorrect settings here could also lead to invalid or incorrect DNS records being generated.
The options to check are:
Network interface for virtual addresses - This is automatically detected by Virtualmin during the configuration check, but could be detected incorrectly, if you have multiple physical interfaces, or your system is some virtualized system like a vserver or Zone or OpenVZ instance.
Default virtual server IP address - If you've manually configured this to
*, for ease of moving a virtual server later, you'll need to instead set it to one of the IP addresses on your system. Moving Virtualmin virtual servers from one IP to another is easy, but getting virtual servers configured correctly with
* in place of an IP can be challenging (also note that if you use
*, the behavior of other virtual hosts that have explicit IPs set may become unpredictable, if extreme caution isn't used). We strongly recommend you never use
* in a virtual hosting environment. But, if you do, you must configure the next option.
Default IP address for DNS records - This option is generally only needed in two circumstances: Your server is behind a NAT router or firewall, and you need the address in DNS records to be a public IP, while the Apache configuration needs to get the private IP; or, you really want to use
* based VirtualHost sections in Apache.
* is not a valid address for a DNS record, and so you must set an address here. As mentioned above, using
* in a virtual hosting environment is not recommended.
This error is the bane of every Apache administrator's existence, as it rarely results in a useful error message in the
error_log. And, to compound matters, permission problems show up in the
suexec_log, which users don't have access to.
A common problem in an environment using
suexec is that permissions on the executable files are too loose. There is a lot of bad advice on the web about setting permissions to 777 for testing, and then figuring out the tighter security later. If group or other users can write your scripts in a
suexec environment, they will not execute. Correct permissions for scripts in a
suexec equipped system are 750 or less. The script will be executed as the owner of the domain, so as long as the owner has appropriate permissions the script will be executable by the Apache
Scripts may have errors in syntax, or be incompatible with the default version of PHP. You may be able to check the syntax from the command line by explicitly calling PHP and the script, like so:
php -l scriptname.php
If you think it might be a version mismatch you could see if the script runs with each of the available versions (Virtualmin provides both PHP4 and PHP5 on most supported platforms).
Scripts may also not have the correct permissions for the files it needs to access. A common problem is unzipping or untarring a script archive as root for use by a domain account user. This will result in files that may not be readable or writable by the domain owner, and thus unreadable or unwritable by the
suexec process. Check to be sure the files are all owned by the owner of the domain using
ls -l. If they aren't, you can use:
chown -R domainname:domainname scriptdirectory
Dedicated servers at RackSpace have Webmin pre-installed, which is awesome...however, the Webmin package they provide is stripped of many modules that are vital for Virtualmin operation, and because the package is still named "webmin", even though it is an incomplete version, this causes hard to diagnose issues during and after installation of Virtualmin.
To correct this problem, you'll need to install a full version of Webmin from us, and also configure up2date/yum not to install the RackSpace Webmin package again. This is simpler if you've not yet begun using Virtualmin (or found this due to problems during installation, and thus haven't even finished installing Virtualmin). See additional notes below, if you have already begun to use Virtualmin, as you cannot safely uninstall Webmin in that case--it will erase your Virtualmin meta-data, such as virtual server definitions and user information.
First, if, you have up2date, configure it to exclude the Webmin package:
Find the number for the
pkgSkipList option, and add
webmin to the list. Note that you should explicitly include any existing packages in the list, and separate them with
;. For example, if the list was [
kernel] to start with, you'd enter
kernel;webmin and hit enter.
If you have only yum with the yum-rhn-plugin, you will need to make sure you have the latest version, as there were bugs in versions prior to 0.5.3-30.el5 that prevented "exclude" rules from working for any RHN repositories. Then, edit
/etc/yum/pluginconf.d/rhnplugin.conf and add a new section for the RackSpace repository containing an exclude rule for webmin. For example, on an x86_64 RHEL 5 Server system, I would add a section like this:
[rackspace-rhel-x86_64-server-5-common] enabled=1 exclude=webmin*
Once that's done, remove the existing Webmin package:
rpm -e webmin
Then, you should be able to use our install script successfully.
If you have already managed to install Virtualmin, either manually, or by finding workarounds to the various issues that occur if trying to install with this minimal Webmin package, you cannot remove Webmin first. You'll need to download the latest version of Webmin, in RPM format, from Webmin.com, and install it manually. You may need to use the
--old-package option, like so:
rpm -Uvh --oldpackage webmin-1.441.noarch.rpm
There may also be other yum repositories enabled, which can cause installation to fail or cause mysterious and hard to diagnose problems after installation. In particular, the RPMForge yum repository for CentOS/RHEL is incompatible with our Fedora-based packages, and should be disabled before installation.