• 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?
 
Back
Top