• Our team is looking to connect with folks who use email services provided by Plesk, or a premium service. If you'd like to be part of the discovery process and share your experiences, we invite you to complete this short screening survey. If your responses match the persona we are looking for, you'll receive a link to schedule a call at your convenience. We look forward to hearing from you!
  • We are looking for U.S.-based freelancer or agency working with SEO or WordPress for a quick 30-min interviews to gather feedback on XOVI, a successful German SEO tool we’re looking to launch in the U.S.
    If you qualify and participate, you’ll receive a $30 Amazon gift card as a thank-you. Please apply here. Thanks for helping shape a better SEO product for agencies!
  • The BIND DNS server has already been deprecated and removed from Plesk for Windows.
    If a Plesk for Windows server is still using BIND, the upgrade to Plesk Obsidian 18.0.70 will be unavailable until the administrator switches the DNS server to Microsoft DNS. We strongly recommend transitioning to Microsoft DNS within the next 6 weeks, before the Plesk 18.0.70 release.
  • The Horde component is removed from Plesk Installer. We recommend switching to another webmail software supported in Plesk.

Issue Roundcube permission denied caused by SELinux

Visnet

Basic Pleskian
Server operating system version
AlmaLinux 9.5
Plesk version and microupdate number
18.0.67.2
I found that after having updated to Plesk Obsidian 18.0.67 (and now to the latest 67 Update 2 as well), Roundcube webmail is showing:

Oops... something went wrong!​


An internal error has occurred. Your request cannot be processed at this time.

For administrators: Please check the application and/or server error logs for more information.

When looking at the Roundcube logs, I noticed:
Code:
tail -n1 -f /var/log/plesk-roundcube/errors
[18-Feb-2025 08:51:42 +0000]: <ed2i91dg> DB Error: SQLSTATE[HY000] [2002] Permission denied in /usr/share/psa-roundcube/program/lib/Roundcube/rcube_db.php on line 201 (GET /)

After diagnosing any password issues, I was able to connect from the command line without issues:
Code:
# mariadb -h localhost -u roundcube roundcubemail -p
Enter password:
#

Finally, I found that disabling SELinux temporarily resolved the issue:
Code:
# setenforce 0

From a discussion with ChatGPT, I found that the SELinux bool for `httpd_can_connect_mysql` is missing:
Code:
# getsebool -a | grep httpd | grep 'httpd_can_network_connect_db'
httpd_can_network_connect_db --> on
# getsebool -a | grep httpd | grep 'httpd_can_connect_mysql'
#

This implies an issue with SELinux rules bundled with Roundcube for Plesk, right?

Software used:
Product version: Plesk Obsidian 18.0.67.2
OS version: AlmaLinux 9.5 x86_64
Build date: 2025/02/05 19:00
Revision: f88f36449702f778b1cf43d8886ff00b56f2a1e5

With:
- plesk-roundcube-1.6.9-2.redhat.9+p18.0.67.0+t250115.1634.noarch
- Drop-in MariaDB-server-11.4.5-1.el9.x86_64
 
The issue seems to be related to using a socket connection, because changing the following line fixes the issue in /usr/share/psa-roundcube/config/config.inc.php (real password redacted):
Code:
$config['db_dsnw'] = 'mysql://roundcube:PASSWORD@localhost/roundcubemail';

Changing it as follows supposedly causes it to use a TCP connection:
Code:
$config['db_dsnw'] = 'mysql://roundcube:[email protected]/roundcubemail';

This fixes the issue, but will probably get overwritten by a Roudcube update.
 
Hi @Sebahat.hadzhi , yes:
Code:
2025-02-05T03:28:27+0100 SUBDEBUG Upgrade: MariaDB-shared-11.4.5-1.el9.x86_64
2025-02-05T03:28:27+0100 DEBUG Upgrading: MariaDB-shared-11.4.5-1.el9.x86_64
2025-02-05T03:28:27+0100 SUBDEBUG Upgrade: MariaDB-common-11.4.5-1.el9.x86_64
2025-02-05T03:28:27+0100 DEBUG Upgrading: MariaDB-common-11.4.5-1.el9.x86_64
2025-02-05T03:28:28+0100 SUBDEBUG Upgrade: MariaDB-client-11.4.5-1.el9.x86_64
2025-02-05T03:28:28+0100 DEBUG Upgrading: MariaDB-client-11.4.5-1.el9.x86_64
2025-02-05T03:28:28+0100 SUBDEBUG Upgrade: MariaDB-server-11.4.5-1.el9.x86_64
2025-02-05T03:28:28+0100 DEBUG Upgrading: MariaDB-server-11.4.5-1.el9.x86_64
2025-02-05T03:28:50+0100 SUBDEBUG Upgrade: MariaDB-backup-11.4.5-1.el9.x86_64
2025-02-05T03:28:50+0100 DEBUG Upgrading: MariaDB-backup-11.4.5-1.el9.x86_64
2025-02-05T03:28:50+0100 SUBDEBUG Upgraded: MariaDB-server-11.4.4-1.el9.x86_64
2025-02-05T03:28:50+0100 DEBUG Cleanup: MariaDB-server-11.4.4-1.el9.x86_64
2025-02-05T03:28:50+0100 SUBDEBUG Upgraded: MariaDB-client-11.4.4-1.el9.x86_64
2025-02-05T03:28:50+0100 DEBUG Cleanup: MariaDB-client-11.4.4-1.el9.x86_64
2025-02-05T03:28:50+0100 SUBDEBUG Upgraded: MariaDB-backup-11.4.4-1.el9.x86_64
2025-02-05T03:28:50+0100 DEBUG Cleanup: MariaDB-backup-11.4.4-1.el9.x86_64
2025-02-05T03:28:50+0100 SUBDEBUG Upgraded: MariaDB-common-11.4.4-1.el9.x86_64
2025-02-05T03:28:50+0100 DEBUG Cleanup: MariaDB-common-11.4.4-1.el9.x86_64
2025-02-05T03:28:50+0100 SUBDEBUG Upgraded: MariaDB-shared-11.4.4-1.el9.x86_64
2025-02-05T03:28:50+0100 DEBUG Cleanup: MariaDB-shared-11.4.4-1.el9.x86_64
2025-02-08T03:34:24+0100 SUBDEBUG Upgrade: mysql-selinux-1.0.13-1.el9_5.noarch
2025-02-08T03:34:24+0100 DEBUG Upgrading: mysql-selinux-1.0.13-1.el9_5.noarch
2025-02-08T03:34:38+0100 SUBDEBUG Upgraded: mysql-selinux-1.0.10-1.el9.noarch
2025-02-08T03:34:38+0100 DEBUG Cleanup: mysql-selinux-1.0.10-1.el9.noarch

Most likely it is related to the upgraded mysql-selinux package.

Any ideas?
 
There's an existing bug, which results in SELinux context not being properly updated for MariaDB binary after an upgrade through the GUI. Please try adjusting the SELinux context:

chcon system_u:object_r:mysqld_exec_t:s0 /usr/sbin/mariadbd systemctl restart mariadb.service
 
The MariaDB binary was not upgraded through the GUI.
Nevertheless, your suggestion does seem to solve the issue. Thanks!

I have made the SELinux context update permanent (instead of temporary with chcon), using:
Bash:
semanage fcontext -a -t mysqld_exec_t /usr/sbin/mariadbd
restorecon -v /usr/sbin/mariadbd
systemctl restart mariadb.service

Do you have a link to a bug report or the known issue?
And if not, where to report this to?
 
Thank you for the update, @Visnet The root cause for the issue is identified with PPP-67607 and the fix should be introduced in the upcoming Plesk release (18.0.68).
 
That issue should be fixed. I will need to double-check with our team why there is no indication for that particular fix in the Change log and get back to you.
 
Back
Top