MariaDB 11.8.9 breaks DB authentication

📦 Install & Upgrade Help
1

SuiteCRM 8.9.2
Rocky Linux 8.10
PHP 8.3.33

After upgrading to MariaDB 11.8.9 from 11.8.8 the suitecrm login page returned a 500 error and the following was recorded in the php-fpm error log:

[26-Aug-2026 10:37:15 Europe/London] PHP Fatal error: Uncaught mysqli_sql_exception: Permission denied in /opt/suitecrm/public/legacy/include/database/MysqliManager.php:321
Stack trace:
#0 /opt/suitecrm/public/legacy/include/database/MysqliManager.php(321): mysqli_connect()
#1 /opt/suitecrm/public/legacy/include/database/DBManagerFactory.php(157): MysqliManager->connect()
#2 /opt/suitecrm/public/legacy/include/entryPoint.php(210): DBManagerFactory::getInstance()
#3 /opt/suitecrm/config/bootstrap.php(71): require_once(‘/opt/suitecrm/p…’)
#4 /opt/suitecrm/vendor/autoload_runtime.php(12): require(‘/opt/suitecrm/c…’)
#5 /opt/suitecrm/public/index.php(5): require_once(‘/opt/suitecrm/v…’)
#6 {main}
thrown in /opt/suitecrm/public/legacy/include/database/MysqliManager.php on line 321

I could log in to the DB directly fine using a local mariadb client with the same host/username/pwd details as configured in config.php
The suitecrm schedulers also appeared to be working normally, it was just the WebUI that couldn’t auth

After downgrading MariaDB server to 11.8.8 the system works normally again.

Just heads up for anyone patching MariaDB 11.8

M

2

Thank you for sharing that.

As per the compatibility matrix, it should work. :face_with_peeking_eye:

3

Ok, finally got round to looking deeper at this and the issue was caused by using localhost to connect to the Local MariaDB DB rather than 127.0.0.1

Why 11.8.8 → 11.8.9 needed that changing I have no idea.

The reason it took me so longer to find is that the DB conenction string is stored in two places.
The original suitecrm/public/legacy/config.php
AND
suitecrm/.env.local

The 2nd one being a ‘.’ prefixed hidden file took me ages to find.

Once both of the DB strings in those two files were changed from localhost to 127.0.0.1 everything started working again. I suspect changing them to localhost4 would have worked as well as I’m guessing the connections were being attempted on the IPv6 localhost interface in preference.

Mark.