Plesk Roundcube Webmail: Fixing “Connection to Storage Server Failed”

If your users suddenly can't log into Roundcube webmail on a Plesk server and instead see the dreaded message "Connection to storage server failed", you are not looking at a broken password or a browser glitch. This error means Roundcube successfully loaded, but it could not establish an IMAP connection to the mail storage backend — almost always Dovecot. For a business running its own mail on Plesk, this is not a cosmetic bug. It is a full webmail outage that stops staff from reading or sending email through the browser, and it often coincides with IMAP/SMTP client failures too.

This guide walks through exactly why this error happens on Plesk servers in 2025/2026, how to diagnose the real root cause instead of guessing, and the step-by-step fixes that resolve it permanently rather than temporarily.

What "Connection to Storage Server Failed" Actually Means

Roundcube is only a web front end. When you log in, it hands your credentials to an IMAP backend defined in its configuration — on Plesk this is Dovecot, listening locally on port 143 (STARTTLS) or 993 (SSL/TLS). The "storage server" in the error message is that IMAP service. When Roundcube cannot open a socket to it, authenticate against it, or complete a TLS handshake with it, this generic error is thrown instead of a specific one, which is why it confuses so many administrators.

In practice, this error shows up after one of these events on a Plesk box:

• A Plesk or OS security update restarted or reconfigured Dovecot
• Dovecot crashed or was killed due to memory pressure
• A firewall rule (iptables, CSF, or a cloud security group) started blocking port 143/993 internally
• An SSL certificate used by Dovecot expired or was replaced with a broken chain
• The Plesk Premium Email extension went out of sync with Roundcube's configuration
• Dovecot is listening on a non-standard port after a manual config change

Step 1: Confirm Dovecot Is Actually Running

Before touching Roundcube's configuration, verify the IMAP service itself is alive. SSH into the server and run:

systemctl status dovecot

If it shows inactive or failed, that is your root cause. Check why it died before simply restarting it:

journalctl -u dovecot --since "1 hour ago" | tail -100

Common findings here are out-of-memory kills (look for oom-killer entries in dmesg), a corrupted configuration file after a manual edit, or a certificate path that no longer exists. Once the cause is identified and corrected, restart the service:

systemctl restart dovecot
systemctl status dovecot

netstat -tulnp | grep dovecot

openssl s_client -connect localhost:993 -crlf

iptables -L -n | grep -E '143|993'
csf -l | grep -E '143|993'

doveconf -n | grep -i ssl_cert
openssl x509 -in /path/to/cert.pem -noout -dates

When the Fix Isn't in Dovecot: Roundcube Database and Extension Issues

If Dovecot is confirmed healthy and reachable, but the error persists, the problem sometimes lies in Roundcube's own database (the roundcube or psa_roundcube database) becoming corrupted after a crash or interrupted update. In this scenario, reinstalling the Roundcube component through Plesk resolves it cleanly:

• Go to Tools & Settings > Updates and Upgrades > Add/Remove Components
• Locate Roundcube under Mail Hosting components
• Remove it, then reinstall it to force a clean configuration and database rebuild

Also check whether the Plesk Premium Email extension (if installed) is out of date, since version mismatches between it and Roundcube are a documented cause of this exact error after Plesk auto-updates.

Preventing This Error From Coming Back

Once resolved, a few standing practices prevent recurrence:

• Monitor Dovecot and Postfix service uptime with alerting, not just cron-based restarts that mask recurring crashes
• Set memory limits and swap correctly so Dovecot isn't the first process the OOM killer targets under load
• Track SSL certificate expiry for the mail server independently from your website certificates, since Plesk sometimes manages them separately
• Test webmail login after every Plesk update or OS patch cycle, not just website functionality
• Keep the Plesk Premium Email extension and Roundcube component versions in sync

When to Bring In Managed Support

A single "storage server" failure is usually fixable in minutes once you know where to look. But recurring failures, silent Dovecot crashes, or certificate chains that keep breaking after renewal are signs of a deeper server health or configuration issue that will keep resurfacing under different symptoms. If your team is already spending hours chasing intermittent webmail outages, it is often more cost-effective to have a managed server management service monitor Dovecot, Postfix, and certificate health proactively, rather than firefighting each incident as it happens.

CloudHouse Technologies' server management service includes mail stack monitoring, proactive certificate renewal checks, and 24/7 incident response for exactly this class of Plesk email issue, so your team gets alerted and the fix applied before staff notice a webmail outage.

Diagnosing Client-Side vs Server-Side Causes

Because the same Dovecot backend serves both Roundcube and desktop/mobile mail clients over IMAP, one of the fastest triage steps is checking whether the problem is isolated to webmail or affects every mail client on the domain. If Outlook, Apple Mail, or a mobile client can still connect and pull mail while Roundcube fails, the issue is more likely in Roundcube's own configuration, its PHP process, or its database rather than Dovecot itself. If every client is failing simultaneously, including IMAP connections from outside the server, you are dealing with a genuine Dovecot or network-level outage.

A quick way to separate the two is to test IMAP from a completely different machine using a simple telnet or openssl probe against the public hostname rather than localhost:

openssl s_client -connect mail.yourdomain.com:993 -crlf

If this fails from outside the server but the localhost test earlier succeeded, the problem is almost certainly a firewall or security group rule blocking external access to port 993, not Dovecot itself. This distinction matters because the fix is completely different: a local firewall table edit versus a Dovecot service repair.

Checking PHP-FPM and Roundcube's Own Logs

Roundcube keeps its own error log independent of Dovecot's logs, and this is often the fastest place to find the specific underlying reason rather than guessing from the generic on-screen message. On most Plesk installations the Roundcube error log lives under:

tail -100 /var/log/plesk-roundcube/errors.log

Look for lines mentioning IMAP Error, Login failed, or explicit socket errors such as Connection refused or Connection timed out. A "Connection refused" message almost always confirms nothing is listening on the expected port, pointing you back to the Dovecot service or port mismatch checks above. A "Connection timed out" message more often points to a firewall silently dropping packets rather than actively rejecting them, which is a useful distinction when deciding whether to focus on iptables/CSF rules or the Dovecot process itself.

It is also worth checking that PHP-FPM for the Roundcube pool is healthy, since a starved or crashed PHP-FPM worker can sometimes present as a generic storage connection error rather than a clear PHP fatal error:

systemctl status plesk-php* 2>/dev/null | grep -A2 roundcube

Handling This on Multi-Server or Clustered Mail Setups

On larger Plesk environments where mail is offloaded to a dedicated mail node separate from the web/application node, the "storage server" in the error message refers to that remote Dovecot host, not localhost. In this configuration, network-level issues become far more likely than local misconfiguration:

• Confirm DNS or internal hostnames used for the mail node have not changed after a migration or IP reassignment
• Verify security group or VPC firewall rules between the web node and the mail node explicitly allow IMAP ports
• Check that any load balancer or reverse proxy in front of the mail node passes IMAP traffic correctly and hasn't silently dropped a backend node from its pool
• Confirm system clocks between nodes are in sync, since large clock drift can break TLS certificate validation between the two servers

These distributed setups are also where monitoring pays off the most, since a single node failing silently in a cluster is much harder to notice from the Plesk UI alone than a single-server outage that immediately affects every user.

A Repeatable Troubleshooting Checklist

To avoid re-diagnosing this from scratch every time it recurs, keep this order of checks documented for your team or your hosting provider:

• Confirm Dovecot service status and recent crash logs
• Confirm Dovecot is listening on the expected ports
• Confirm Roundcube's IMAP host/port configuration matches Dovecot's actual listener
• Test the IMAP port manually with OpenSSL, both locally and from an external host
• Check firewall/security group rules for the relevant ports
• Validate the SSL certificate Dovecot is presenting
• Review Roundcube's own error log for a more specific underlying message
• Reinstall the Roundcube component only after the above steps rule out an infrastructure cause

Following this order prevents the common mistake of reinstalling Roundcube first, which wastes time when the actual cause is a stopped Dovecot service or an expired certificate that reinstalling Roundcube will never fix.

Conclusion

"Connection to storage server failed" in Roundcube on Plesk is an IMAP connectivity problem in disguise, almost always traced back to Dovecot being down, misconfigured, blocked by a firewall rule, or serving a broken SSL certificate. Working through Dovecot's status, listening ports, firewall rules, and certificate validity in that order resolves the vast majority of cases without needing to touch Roundcube's own database. For servers where this keeps recurring, proactive mail stack monitoring is the more durable fix than repeated manual troubleshooting.