Directadmin Docs

Webmail

One-Click login to RoundCube

With the release of DirectAdmin 1.59.0, we now support one-click logins for both RoundCube (and phpMyAdmin). This is often called Single SignOn, or SSO logins. No password is needed to login to these accounts.

  • To enable one-click login for RoundCube
da config-set one_click_webmail_login 1
systemctl restart directadmin
da build dovecot_conf
da build exim_conf
da build roundcube
  • To use the feature, go to User Level -> E-Mail Accounts and the 2nd "Login" Column will have a list of URLs which can be clicked to log in as this E-Mail account.
    Note, it does not apply to the system account (DA Login), only virtual email accounts.

Related release logopen in new window

How to configure webmail.domain.com ?

Depending on currently used webserver:

For Apache.

For Nginx.

For Nginx-Apache proxy - implement for both Nginx and Apache.

For OpenLitespeed.

The single sign-on tool for the URL path /roundcube now has a directadmin.conf option which can be changed.
The internal default is:

one_click_webmail_link=/roundcube

So if you've got your /roundcube setup with /webmail, this lets you have the click within DA to redirect this value.

How can I change where the webmail button goes to?

The direction where webmail goes is configured with DirectAdmin config value, nowadays two options are supported: squirrelmail and roundcube.

SquirrelMail is outdated. The new installations are using RoundCube webmail. The link in use can be checked with:

da config-get webmail_link

The link could be hidden with another option:

da config-set hide_webmail_links 1
systemctl restart directadmin

Note, this guide is about the Enhanced skin since evolution is slightly different and could be customized differently.

I want to redirect port 2096 to client /webmail

If imported cPanel Users are trying to go to theirdomain.com:2096 to access webmail, you can set up Apache to redirect that back to https://theirdomain.com/webmail .

We'll assume you're running plain Apache for this example. Other webservers can use this strategy/template system, but are not covered here.

  1. Tell Apache to listen on this port. Edit the /etc/httpd/conf/extra/httpd-includes.conf file and add one line of code:
Listen 2096

DirectAdmin will not overwrite this file, so changes in there are safe.

  1. Add a https:2096 VirtualHost to each domain. For this we make use of the Global pre-post CUSTOM token templatesopen in new window. Create the file /usr/local/directadmin/data/templates/custom/virtual_host2_secure.conf.CUSTOM.4.post and insert the following code:
    </VirtualHost>
    <VirtualHost |IP|:2096>
           SSLEngine on
           SSLCertificateFile |CERT|
           SSLCertificateKeyFile |KEY|
           |CAROOT|
           ServerName www.|DOMAIN|
           ServerAlias www.|DOMAIN| |DOMAIN|
           Redirect 301 / https://|DOMAIN|/webmail

You might notice the VirtualHost tags seem out of order, but this is correct. We're inserting it into the the end of the CUSTOM4 token in virtual_host2_secure.conf, which is within the 443 VirtualHost, hence we end it first and start a new one, and finally let the virtual_host2_secure.conf close our new VirtualHost.

  1. Then rewrite the configs to push the change to all domains:
da build rewrite_confs

Port forwarding over CSF

Method 2 is to configure port forwarding by firewall, open the /etc/csf/csf.redirect file, and add a line:

*|2096|*|443|tcp

Next apply changes by restarting CSF:

csf -r

How to customize the configuration for RoundCube or Squirrelmail

If you've got custom options enabled for SquirrelMail or Roundcube, then you'll need a way to maintain those customizations between updates by CustomBuild.

To do that, you'd simply copy your custom config to the relevant path. The paths are as follows:

#SquirrelMail
/usr/local/directadmin/custombuild/custom/squirrelmail/config.php

#Roundcube >= 1.0.0
/usr/local/directadmin/custombuild/custom/roundcube/config.inc.php
#Roundcube <= 0.9.5
/usr/local/directadmin/custombuild/custom/roundcube/main.inc.php
/usr/local/directadmin/custombuild/custom/roundcube/db.inc.php
#RoundCube && CustomBuild 2.0
/usr/local/directadmin/custombuild/custom/roundcube/.htaccess

If the relevant config exists, then the CustomBuild script will copy it to the relevant path of the newly installed script, somewhere in /var/www/html/*.

Also, regarding the following directory,:

/usr/local/directadmin/custombuild/custom/roundcube/plugins

if it exists, will have its contents copied into:

/var/www/html/roundcube/plugins/

overwriting any duplicates. This can be used to copy specific files, configs, or directories for customized plugins over to the new version.

Similarly, if this exists:

/usr/local/directadmin/custombuild/custom/roundcube/skins

its contents will be copied into:

/var/www/html/roundcube/skins/

overwriting any duplicates.

How to enforce RoundCube to use secure https / SSL

Requiring websites to use SSL is very common these days, and forcing RoundCube to use https should be no exception.

This can be done with one of 2 different methods.

  1. .htaccess method

An .htaccess can be used, but because any RoundCube update from CB2 will overwrite the .htaccess file, there are a few exact steps to ensure it's safe.

cd /usr/local/directadmin/custombuild
mkdir -p custom/roundcube
cp /var/www/html/roundcube/.htaccess custom/roundcube/.htaccess

Then edit the custom/roundcube/.htaccess, and at the top add the following code, before the existing code:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

And lastly, rebuild:

da build roundcube

which should copy it back over to RC to enforce https with the same host.

Note, some services like CloudFlare may require different code in the .htaccess :

RewriteCond %{HTTPS} off
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R,L]
  1. RoundCube config:

Using the custom/roundcube/config.inc.php method, the following setting can be added in, to have RoundCube itself force https:

    $config['force_https'] = true;

RoundCube: update the database, doing each query line by line

Usually, you can update your RoundCube database by running:

da build roundcube

which lets RoundCube do its own thing, deciding what update queries to run.

It's possible that things get out sync, and the update order is changed (possibly going backwards, or manually restoring an older DB, etc).

RoundCube stores its current version in value:

da_roundcube.system.roundcube-version = XXXXX

I believe this is what it uses to determine which SQL update files to run from /var/www/html/roundcube/SQL/mysql/*.sql .

If the update process fails, you might see something similar to:

Executing database schema update.
Updating database schema (2013011000)... [FAILED]

There could be a few possibilities, each with a different possible solution.

You're typically going to only want to do these as a last resort.

If you have backups, be sure they're safe and prepare for a restore, as it's possible you might not be able to save the current data if the tables have been corrupted (#1). If it's just sync issues, then options #2 and #3 have a chance of saving the current data.

This is not an official guide from RoundCube, but has worked for us in some cases in the past. #3 is the most thorough and often required, but is also very time consuming.

1. Empty Database

This scenario is simplest. Grab the da_admin user/pass from /usr/local/directadmin/conf/mysql.conf and login to /phpMyAdmin.

Check for the da_roundcube database. If it has 0 tables, then it's empty and the solution is to drop the whole database.

If there are tables there, DO NOT DROP THE DATABASE, but instead click the "users" and "contacts" tables to confirm you can see those tables and whether or not they have data in them. If they do, skip to #2. If you get table read errors, then you could attempt to repair them, but that's often unsuccessful. If that's the case, then continue to DROP and re-install RoundCube.

To do that, go to your SQL tab, and run:

DROP DATABASE da_roundcube

If you have backups, then you might be able to restore them after you re-run the reinstall with:

da build roundcube

2. Version out of Sync

This possibility means the version in the roundcube-version row (above) was wrong, so the update was done for the wrong version. In this case, you'd need to go backwards to the correct version file (if unsure, go back a bit further). For each version .sql file, you'd run

cd /var/www/html/roundcube/SQL/mysql
mysql -uda_admin -pdaadminpass da_roundcube < 201XXXXXXX.sql

going from the oldest to newest. Follow it up with a :

da build roundcube

3. Version out of Sync with manual line-by-line queries required

If the above failed, which is probable, you might need to run each query from those .sql files, one at a time. This is very tedious, but useful as a last resort. The reason is that if any query in an .sql file fails, future queries are not run.

If the DB is out of sync enough, it's possible queries further in a given file are needed, even if earlier ones have already been run.

To do this, similar to before, you'd figure out which .sql file to start with (I believe they're dated) and start oldest to newest, but instead of running the mysql command, in /phpMyAdmin as da_admin (or da_roundcube if you want to grab that from the roundcube/config/config.inc.php file), you'd go to the SQL tab in phpMyAdmin, and for each file, run each query from the start of the file to the end of the file, one at a time.

A query will be a line that start with ALTER, DROP, UPDATE, INSERT,CREATE which might span multiple lines, but each query will end with a colon ; character. Be sure to copy/paste the entire query, from the start of the line to the end of the query, including the colon.

When running each query, you may hit errors if that task has already been run. Don't worry, just keep running them, each query, each file (from where you decided to start from), until you're all the way to the end of the last file.

After all queries are fully done, then be sure to finish up with a normal RC update

da build roundcube

to ensure the roundcube version gets correctly updated to the current script version.

Error connecting to IMAP server: localhost

If you get the following error:

Error connecting to IMAP server: localhost.
0 : php_network_getaddresses: getaddrinfo failed: Name or service not  known

It usually means that the server cannot resolve localhost . Check the /etc/hosts file if it has a localhost definition:

127.0.0.1       localhost       localhost.localdomain localhost4 localhost4.localdomain4
::1     localhost       localhost.localdomain localhost6 localhost6.localdomain6

And try pinging it:

ping localhost

ERROR: Connection dropped by imap server: Query: SELECT "INBOX"

If you get the following error when trying to connect to your webmail client:

ERROR: Connection dropped by imap server
Query: SELECT "INBOX"

Check your /var/log/maillog for any Dovecot errors or clues.

It may be that the Dovecot indexes are corrupted (sometimes happens between Dovecot versions), so the fix is to simply purge the indexes, e.g.,

cd /home/username/imap/domain.com/user/Maildir
rm -f dovecot*

When you log in to Dovecot (either via webmail or email client) the index will be re-created, and you should be good to go.

RoundCube: your session is invalid or expired

If you get the following error when logging into RoundCube:

your session is invalid or expired

The first thing to check is that your /tmp folder exists, then permissions (chmod to 1777 (drwxrwxrwt)), and lastly that your drive isn't full.

However, it's also been noted that the timezone setting in the php.ini can affect this value. Edit the php.ini and change:

date.timezone = "UTC"

to the local value you're using, or comment out that field.

RoundCube: Connection to storage server failed

  1. If you've recently updated your version of Dovecot, and if you get this error in RoundCube:
connection to storage server failed

it may be that the Dovecot index files are for an older version of Dovecot, and don't fully work with the new version. To resolve that issue, simply delete all Dovecot index files, and Dovecot will re-create them when it notices they're missing.

You should test this on one User first, before doing it on all Users.

Also, backup the dovecot* files of the test User first (shouldn't be required, but not a bad thing to do):

cd /home
service dovecot stop
rm -f */imap/*/*/Maildir/dovecot*
rm -f */imap/*/*/Maildir/.*/dovecot*
rm -f */Maildir/dovecot*
rm -f */Maildir/.*/dovecot*
systemctl restart dovecot

Dovecot will recreate the dovecot* files once the User logs in.

  1. If Dovecot has hit the per-IP limit, you'd see something like this in your /var/log/maillog:
imap-login: Maximum number of connections from user+IP exceeded (mail_max_userip_connections=10)

The solution for that is to add the following to the very bottom of your /etc/dovecot/dovecot.conf file:

mail_max_userip_connections = 15
remote 127.0.0.1 {
       mail_max_userip_connections = 40
}

where the "remote 127.0.0.1" refers to the local limit (connections from roundcube and squirrelmail), and the limit of 15, just above it, is the per-IP limit for external IP addresses. There are a couple other ways of going about it (can be done in the "protocol imap" section), but the method mentioned here also covers pop without any extra code.

  1. Another error:
master: Warning: service(imap-login): process_limit (100) reached, client connections are being dropped

The solution for this is to increase the process_limit for imap. Edit the /etc/dovecot.conf, find the "service imap-login {" section, and set a higher limit, e.g.,

service imap-login {
       process_limit = 800
       process_min_avail = 16
       user = dovecot
}
  1. Beyond that, check your Apache logs for possible clues:
cd /var/log/httpd
tail -n 20 error_log
tail -n 20 domains/domain.com.log
tail -n 20 domains/domain.com.error.log

and the Dovecot and RoundCube logs:

tail -n 20 /var/log/maillog
tail -n 20 /var/www/html/roundcube/logs/errors
  1. Check the /etc/hosts file to ensure you see:
127.0.0.1   localhost

and that localhost does not exist under other IPs.

RoundCube: SMTP Error (-1): Connection to server failed

If you're getting the following error when sending an email in RoundCube:

SMTP Error (-1): Connection to server failed.

possible causes include:

  1. Your disable_functions list in your php.ini is too strict. Try removing some functions, or use CustomBuild function:
da build secure_php

Known errors caused by a disable_functions list which is too strict:

Invalid request! No data was saved

  1. Perhaps Exim is not running. Check to ensure that it's running, and that port 587 is open.

  2. Check your /etc/hosts file to ensure you see:

127.0.0.1    localhost

as the config connects to "localhost", so if that is missing, RoundCube may end up connecting to other IPs, depending on what the nameserver returns.

  1. One report of CSF requiring the setting has been seen:
SMTP_BLOCK = 1
SMTP_ALLOWLOCAL = 1

RoundCube: SMTP Error (220): Authentication failed

If you see the following error when trying to send mail through RoundCube after you've already successfully logged in, follow this guide:

SMTP Error (220): Authentication failed.

Because you were able to login, which uses Dovecot, then the issue focuses on Exim.

  1. Check /var/log/exim/mainlog to see if there are any message relating to the rejection.

  2. If you cannot see any entries at all, it could be a certificate issue if RC is setup to use TLS for sending. Edit the /var/www/html/roundcube/config/config.inc.php and if you have TLS, change:

    $config['smtp_server'] = 'tls://localhost;

to be your hostname:

    $config['smtp_server'] = 'tls://server.hostname.com';

Such that is matches the SSL host value in your /etc/exim.cert file.

RoundCube: The "Date" column is blank or incorrect

If your "Date" column is blank, or if it's showing incorrect values, then check your php.ini file, and set the correct timezone for your server.

A sample timezone setting would be:

date.timezone = "UTC"

but can be set to other values. See PHP.netopen in new window for a list of all valid PHP timezones.

It seems the date is based on the mtime (last modified) time of the file in question.

If you do an "ls -la" on the file in your Maildir, then that will likely match up with the time shown in the list.

As for "why" the file was modified at a different time than when it was created, that's a different story. Perhaps when it's moved from new to cur once it's seen, that "touches" the timestamp to the newer value (not confirmed).

RoundCube: Failed to send UID SEARCH command

RoundCube has the ability to do searches using IMAP, but for some larger accounts, this could be slow. This error can pop up if the search takes too long:

Failed to send UID SEARCH command

To resolve this, we simply need to give PHP more time before giving up on the request. This is done by increasing the following setting in your php.ini:

default_socket_timeout = 180

which defaults to 60.

The higher value of 180 may help. If you can count it waiting for the full 3 minutes and then throwing the error again, increase it to an even higher value.

Last Updated: