Search K
Appearance
Appearance
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.
da config-set one_click_webmail_login 1
systemctl restart directadmin
da build roundcubeRelated release log
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=/roundcubeSo if you've got your /roundcube setup with /webmail, this lets you have the click within DA to redirect this value.
With DirectAdmin 1.688, you can now optionally set it to:
da config-set one_click_webmail_link 'https://webmail.domain.com'
systemctl restart directadminwhere the webmail subdomain points to RoundCube. The value must start with http:// or https://, else DirectAdmin will append this value to the end of the current host, rather than using this new host value.
If you want to revert the configuration back to the default one, please use these commands:
da config-set one_click_webmail_link '/roundcube'
systemctl restart directadminThe 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_linkThe link could be hidden with another option:
da config-set hide_webmail_links 1
systemctl restart directadminNote, this guide is about the Enhanced skin since evolution is slightly different and could be customized differently.
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.
/etc/httpd/conf/extra/httpd-includes.conf file and add one line of code:Listen 2096DirectAdmin will not overwrite this file, so changes in there are safe.
/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|/webmailYou 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.
da build rewrite_confsMethod 2 is to configure port forwarding by firewall, open the /etc/csf/csf.redirect file, and add a line:
*|2096|*|443|tcpNext apply changes by restarting CSF:
csf -raIf 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/.htaccessIf 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/pluginsif 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/skinsits contents will be copied into:
/var/www/html/roundcube/skins/overwriting any duplicates.
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.
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/.htaccessThen 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 roundcubewhich 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]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;Usually, you can update your RoundCube database by running:
da build roundcubewhich 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 = XXXXXI 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.
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_roundcubeIf you have backups, then you might be able to restore them after you re-run the reinstall with:
da build roundcubeThis 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.sqlgoing from the oldest to newest. Follow it up with a :
da build roundcubeIf 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 roundcubeto ensure the roundcube version gets correctly updated to the current script version.
If you get the following error:
Error connecting to IMAP server: localhost.
0 : php_network_getaddresses: getaddrinfo failed: Name or service not knownIt 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.localdomain6And try pinging it:
ping localhostIf 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.
If you get the following error when logging into RoundCube:
your session is invalid or expiredThe 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.
connection to storage server failedit 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
systemctl restart dovecot
rm -f */imap/*/*/Maildir/dovecot*
rm -f */imap/*/*/Maildir/.*/dovecot*
rm -f */Maildir/dovecot*
rm -f */Maildir/.*/dovecot*
systemctl restart dovecotDovecot will recreate the dovecot* files once the User logs in.
/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.
master: Warning: service(imap-login): process_limit (100) reached, client connections are being droppedThe 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
}cd /var/log/httpd
tail -n 20 error_log
tail -n 20 domains/domain.com.log
tail -n 20 domains/domain.com.error.logand the Dovecot and RoundCube logs:
tail -n 20 /var/log/maillog
tail -n 20 /var/www/html/roundcube/logs/errors/etc/hosts file to ensure you see:127.0.0.1 localhostand that localhost does not exist under other IPs.
If you're getting the following error when sending an email in RoundCube:
SMTP Error (-1): Connection to server failed.possible causes include:
php.ini is too strict. Try removing some functions, or use CustomBuild function:da build secure_phpKnown errors caused by a disable_functions list which is too strict:
Invalid request! No data was savedPerhaps Exim is not running. Check to ensure that it's running, and that port 587 is open.
Check your /etc/hosts file to ensure you see:
127.0.0.1 localhostas the config connects to "localhost", so if that is missing, RoundCube may end up connecting to other IPs, depending on what the nameserver returns.
SMTP_BLOCK = 1
SMTP_ALLOWLOCAL = 1If 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.
Check /var/log/exim/mainlog to see if there are any message relating to the rejection.
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.
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.net 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 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 commandTo 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 = 180which 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.