• We value your experience with Plesk during 2025
    Plesk strives to perform even better in 2026. To help us improve further, please answer a few questions about your experience with Plesk Obsidian 2025.
    Please take this short survey:

    https://survey.webpros.com/
  • On Plesk for Linux mod_status is disabled on upgrades to improve Apache security.
    This is a one-time operation that occurs during an upgrade. You can manually enable mod_status later if needed.

Issue Webmail (Roundcube) returns 500 error due to forced OS PHP 7.4 FastCGI instead of Plesk PHP handler

voelu28

New Pleskian
Server operating system version
Ubuntu 20.04.6 LTS
Plesk version and microupdate number
Plesk Obsidian 18.0.74 Update 3
I am running Plesk Obsidian 18.0.74 on Ubuntu 20.04.
Multiple domains show 500 Internal Server Error in Webmail (Roundcube).

Root cause analysis so far:

Webmail virtual hosts generated by Plesk use mod_fcgid and set:
• PP_CUSTOM_PHP_CGI_INDEX = “fastcgi”
• PP_CUSTOM_PHP_INI = “/etc/php/7.4/apache2/php.ini”

This forces Webmail to use OS PHP 7.4 FastCGI with the Apache2 php.ini profile.

However:
• PHP 7.4 CGI actually runs with /etc/php/7.4/cgi/php.ini
• Forcing the apache2 php.ini in FastCGI causes instability
• php-cgi outputs warning: Module 'kolabformat' already loaded
• Apache error log shows: Connection reset by peer
• Result: Webmail returns HTTP 500

Important details:
• OS PHP 7.4 is installed and working (php-cgi 7.4.3, php-cgi7.4)
• PHP 7.4 is NOT registered as a Plesk PHP handler
• Only Plesk PHP versions (8.3 / 8.4 / 8.5) are available as handlers
• When Webmail is forced to plesk-php83-fastcgi with /etc/psa-webmail/roundcube/php.ini, Webmail works perfectly

Problem:
Plesk regenerates Webmail configs on httpdmng --reconfigure-all and always falls back to:
• generic "fastcgi"
• /etc/php/7.4/apache2/php.ini

This breaks Webmail repeatedly.

Questions:
1. What is the official Plesk-supported way to fully stop using OS PHP 7.4 for Webmail?
2. Should Webmail always use Plesk PHP handlers instead of system PHP?
3. Is Ubuntu 20.04 + OS PHP 7.4 an unsupported / legacy setup for Webmail?
4. How can the Webmail PHP handler be fixed permanently without custom sed/overrides?

Current workaround:
• Manually rewriting Webmail vhosts to use plesk-php83-fastcgi
• Works, but is overwritten by Plesk regeneration

Any official guidance would be appreciated.
 
Thanks for the clarification.

I followed the guide “How to change PHP version for webmail in Plesk for Linux” step by step and implemented the solution using custom templates as described.

I created a custom Roundcube webmail template and explicitly set the PHP handler to a supported Plesk PHP FastCGI handler (for example plesk-php83-fastcgi). After that, I reconfigured all webmail vhosts using httpdmng –reconfigure-all and reloaded Apache. Apache configuration tests are clean and there are no syntax errors.

However, even after applying the custom template, the generated webmail virtual host configurations under /etc/apache2/plesk.conf.d/webmails/ still contain FastCGI environment variables pointing to system PHP 7.4, such as PP_CUSTOM_PHP_INI pointing to /etc/php/7.4/apache2/php.ini and PP_CUSTOM_PHP_CGI_INDEX set to “fastcgi”.

This results in webmail (Roundcube) still being executed with system PHP 7.4 instead of the configured Plesk PHP 8.3 handler, which leads to 500 Internal Server Errors.

Important detail: PHP 7.4 is still installed on the system and php-cgi 7.4 is present and functional, but PHP 7.4 is NOT registered as a Plesk PHP handler. Only Plesk PHP 8.3, 8.4 and 8.5 handlers are enabled and available in plesk bin php_handler –list.

So the issue is not missing PHP 7.4, but that webmail vhost generation still references system PHP paths instead of the selected Plesk PHP handler, even after applying the official custom template method.

Could you please clarify why Plesk still injects system PHP 7.4 paths into webmail vhosts after following the documented procedure, and how to ensure that webmail consistently uses the selected Plesk PHP 8.3 handler across all reconfigurations?
 
Thank you for the update. Plesk expects Roundcube to use a Plesk-managed PHP versions, which is why it doesn't work with the 7.4 OS PHP package. Could you please try installing it from Plesk > Tools & Settings > Updates? As for why the configuration is overridden, unfortunately, I am not quite sure.
 
Interesting, I've just notice this strange behaviour too.

I had PHP 8.1, 8.2, 8.3 and 8.4 installed on my server.

I had previously followed this guide (https://support.plesk.com/hc/en-us/...ge-PHP-version-for-webmail-in-Plesk-for-Linux) to change Roundcube to use PHP 8.4. I followed the instructions, ran "plesk repair web -server -y" at the end of it and thought nothing more of it.

Today, I removed the deprecated PHP 8.1 from my server as it's EoL, after removing PHP 8.1 Roundcube gave 500 errors, despite me creating a custom config many months ago and telling it to use 8.4.

If I reinstall PHP 8.1 Roundcube magically comes back to life without any errors despite me still having a custom /usr/local/psa/admin/conf/templates/custom/webmail/roundcube.php file with the "FcgidInitialEnv PP_CUSTOM_PHP_CGI_INDEX plesk-php84-fastcgi" in the config.

Checking the headers returned from Roundcube I get "X-POWERED-BY PHP/8.1.34", so I wonder why my /usr/local/psa/admin/conf/templates/custom/webmail/roundcube.php file specifying plesk-php84-fastcgi is ignored.
 
Hi, @Richard18 . I am not quite sure why would Roundcube ignore the custom template. I will try to replicate the behavior on a test environment and further discuss the case with our team. Just for the record, are you also on Ubuntu 20.04?
 
Back
Top