Login Credentials incorrect, please try again after 8.81 upgrade

I’ve seen the a few times in the forum but I don’t see a solution.

I upgraded to 8.8.1 from 8.8.0

Myself as admin and and EXISTING users CAN log in.

New users I create cannot and get Login Credentials incorrect, please try again,

I have tried many times changing password, making sure it was correct etc

Is this a permission issue? I’m stil quite confused in permission setting.
As stated, we can still login, just not new users.

This is prod.log if it helps

2025-08-13 19:45:25] php.WARNING: Notice: SessionHandler::gc(): ps_files_cleanup_dir: opendir(/var/cpanel/php/sessions/ea-php83) failed: Permission denied (13) {“exception”:“[object] (ErrorException(code: 0): Notice: SessionHandler::gc(): ps_files_cleanup_dir: opendir(/var/cpanel/php/sessions/ea-php83) failed: Permission denied (13) at /vendor/symfony/http-foundation/Session/Storage/Handler/StrictSessionHandler.php:87)”}
[2025-08-13 19:45:35] php.WARNING: Notice: SessionHandler::gc(): ps_files_cleanup_dir: opendir(/var/cpanel/php/sessions/ea-php83) failed: Permission denied (13) {“exception”:“[object] (ErrorException(code: 0): Notice: SessionHandler::gc(): ps_files_cleanup_dir: opendir(/var/cpanel/php/sessions/ea-php83) failed: Permission denied (13) at /vendor/symfony/http-foundation/Session/Storage/Handler/StrictSessionHandler.php:87)”}
[2025-08-13 20:00:33] php.WARNING: Notice: SessionHandler::gc(): ps_files_cleanup_dir: opendir(/var/cpanel/php/sessions/ea-php83) failed: Permission denied (13) {“exception”:“[object] (ErrorException(code: 0): Notice: SessionHandler::gc(): ps_files_cleanup_dir: opendir(/var/cpanel/php/sessions/ea-php83) failed: Permission denied (13) at /vendor/symfony/http-foundation/Session/Storage/Handler/StrictSessionHandler.php:87)”}
[2025-08-13 20:06:03] php.WARNING: Notice: SessionHandler::gc(): ps_files_cleanup_dir: opendir(/var/cpanel/php/sessions/ea-php83) failed: Permission denied (13) {“exception”:“[object] (ErrorException(code: 0): Notice: SessionHandler::gc(): ps_files_cleanup_dir: opendir(/var/cpanel/php/sessions/ea-php83) failed: Permission denied (13) at /vendor/symfony/http-foundation/Session/Storage/Handler/StrictSessionHandler.php:87)”}
[2025-08-13 20:07:54] php.WARNING: Notice: SessionHandler::gc(): ps_files_cleanup_dir: opendir(/var/cpanel/php/sessions/ea-php83) failed: Permission denied (13) {“exception”:“[object] (ErrorException(code: 0): Notice: SessionHandler::gc(): ps_files_cleanup_dir: opendir(/var/cpanel/php/sessions/ea-php83) failed: Permission denied (13) at /vendor/symfony/http-foundation/Session/Storage/Handler/StrictSessionHandler.php:87)”}
[2025-08-13 20:08:58] request.ERROR: Uncaught PHP Exception Symfony\Component\HttpKernel\Exception\BadRequestHttpException: “There is currently no session available.” at HttpKernel.php line 83 {“exception”:“[object] (Symfony\Component\HttpKernel\Exception\BadRequestHttpException(code: 0): There is currently no session available. at /vendor/symfony/http-kernel/HttpKernel.php:83, Symfony\Component\HttpFoundation\Exception\SessionNotFoundException(code: 0): There is currently no session available. at /vendor/symfony/http-foundation/RequestStack.php:107)”}

Help!

Hello Vincent,

I can’t replicate the issue - here, it’s working just fine.

Recently, there has been another issue with sessions and CPanel as well - but without a solution:

Overall, permission denied is clear in your log messages.
Look into PHP config, session path, directory permissions on your server side.
It doesn’t sound as if those errors have anything to do with SuiteCRM.

(One tip: If you throw those error into an AI, it usually can help)

1 Like

Stuff is way over my head. But this is what Chatgpt returned. How does this point to new users logging in though?

Got it — since this is SuiteCRM and not WordPress, the warning is still about PHP session garbage collection, but the fix shifts to SuiteCRM’s environment setup.

SuiteCRM doesn’t manage sessions itself — it uses PHP’s built-in session handling — so the solution is to point SuiteCRM to a session directory it can write to instead of /var/cpanel/php/sessions/ea-php83 (which is a global cPanel folder your PHP process can’t access).


How to fix in SuiteCRM

You can override PHP’s session save path for SuiteCRM only.

Option 1 — In php.ini or .user.ini

Inside SuiteCRM’s root folder, create or edit .user.ini:

session.save_path="/home/YOURCPANELUSER/tmp"

Replace YOURCPANELUSER with your cPanel username.
Make sure the folder exists and is writable:

mkdir -p /home/YOURCPANELUSER/tmp
chmod 700 /home/YOURCPANELUSER/tmp

cPanel will respect .user.ini for PHP 8.3.


Option 2 — Inside config_override.php

SuiteCRM loads config_override.php after its main config.
Add:

<?php
ini_set('session.save_path', '/home/YOURCPANELUSER/tmp');

This forces SuiteCRM to store sessions in your own directory, bypassing the system one.


Option 3 — Ask host to fix permissions

If you must use /var/cpanel/php/sessions/ea-php83, your hosting provider will need to adjust the permissions so the PHP handler user can read/write it — though on shared hosting they often won’t, for security.


Why this happens:
When SuiteCRM calls session_start(), PHP’s gc() may run and try to clean expired sessions from the configured save path. On cPanel shared hosting, the global /var/cpanel/php/sessions paths are often restricted to the server’s session cleanup service, not individual users.


If you want, I can show you the safest config_override.php code that will also set PHP’s garbage collection probability to 0 so SuiteCRM doesn’t try cleaning that directory at all — letting your host’s cron do it instead. That removes the warning entirely.

You said:

Yes

ChatGPT said:

Here’s the safest config_override.php setup for SuiteCRM to avoid that SessionHandler::gc() permission denied warning entirely.

It does two things:

  1. Changes the session save path to a folder in your account that SuiteCRM can write to.
  2. Disables PHP’s own garbage collection (so it won’t try cleaning /var/cpanel/php/sessions/...).

config_override.php

Place this in your SuiteCRM root (or edit the existing one):

<?php
// Force sessions into your own writable directory
ini_set('session.save_path', '/home/YOURCPANELUSER/tmp/suitecrm_sessions');

// Make sure the folder exists and is secure
if (!is_dir('/home/YOURCPANELUSER/tmp/suitecrm_sessions')) {
    mkdir('/home/YOURCPANELUSER/tmp/suitecrm_sessions', 0700, true);
}

// Disable PHP's built-in session garbage collection
// (Your host's cron will clean up old sessions)
ini_set('session.gc_probability', 0);
ini_set('session.gc_divisor', 1000);

Steps

  1. Replace YOURCPANELUSER with your actual cPanel username.
  2. Upload this file to the root SuiteCRM folder (where config.php lives).
  3. Make the folder:
mkdir -p /home/YOURCPANELUSER/tmp/suitecrm_sessions
chmod 700 /home/YOURCPANELUSER/tmp/suitecrm_sessions
  1. Clear SuiteCRM’s cache:
rm -rf cache/*
  1. Log back in and check that the warning is gone.

This approach is safe because:

  • It keeps sessions out of the system folder you can’t access.
  • It avoids interfering with cPanel’s own session cleanup schedule.
  • It works even if SuiteCRM is upgraded.

You’re seeing opendir(/var/cpanel/php/sessions/ea-php83) failed. because unless you’re running CloudLinux, that folder contains session data for everyone using PHP 8.3 (each user owns their own session files, so there’s no cross-account communication). Nevertheless only root has read access to the folder and Apache isn’t running as root.

It’s a little odd that SuiteCRM is taking on the job of session cleanup since PHP should be doing that anyway. Nevertheless the fix for this is to set your own folder for session storage. See Session Directory configuration :: SuiteCRM Documentation for a guide on doing that.

Unfortunately, this might just move you forward to having the same problem I have, which is what BastianHammer quoted. If that’s the case, please reply to that thread. It would be good to know if this is cPanel related or something else. Actually, if you don’t have my problem, please let me know too. I’m grasping at straws here and every bit of information helps!

1 Like

I made the suggested changes. The errors are acutally gone but does nothing for the login issue

I also follwed another post about removing special characters from mysql db username. Now NOT EVEN I CAN LOGIN. Username, Db, and password are correct in config.php. I tried clearing cache with no luck.

I’m on the verge of moving to another platform

[2025-08-14 11:07:57] request.CRITICAL: Uncaught PHP Exception Doctrine\DBAL\Exception\ConnectionException: “An exception occurred in the driver: SQLSTATE[HY000] [1045] Access denied for user ‘MYDBUSERNAME’@‘localhost’ (using password: YES)” at ExceptionConverter.php line 101 {“exception”:“[object] (Doctrine\DBAL\Exception\ConnectionException(code: 1045): An exception occurred in the driver: SQLSTATE[HY000] [1045] Access denied for user ‘MYDBUSERNAME’@‘localhost’ (using password: YES) at /home2/wizard22/crm.musicbraintraining.com/vendor/doctrine/dbal/src/Driver/API/MySQL/ExceptionConverter.php:101, Doctrine\DBAL\Driver\PDO\Exception(code: 1045): SQLSTATE[HY000] [1045] Access denied for user ‘MYDBUSERNAME’@‘localhost’ (using password: YES) at /vendor/doctrine/dbal/src/Driver/PDO/Exception.php:28, PDOException(code: 1045): SQLSTATE[HY000] [1045] Access denied for user ‘MYDBUSERNAME’@‘localhost’ (using password: YES) at /vendor/doctrine/dbal/src/Driver/PDO/MySQL/Driver.php:33)”}

Did you check / change the DB connection string in:

.env.local

as well?

Overall, it’s clear - the username or password (or connection string somewhere) is just wrong.
That’s not an issue of SuiteCRM. You need to give the webapp the correct info about the DB. Same for WordPress, NextCloud and all other DB based applications.

i follwed chatgpt to try and fix and now I can’t even get in . internal error

https://crm.musicbraintraining.com/public/index.php#/home

At this point I’m just thinking of uninstalling and starting from scratch

Warning: include(/vendor/composer/…/doctrine/cache/lib/Doctrine/Common/Cache/Psr6/DoctrineProvider.php): Failed to open stream: No such file or directory in /vendor/composer/ClassLoader.php on line 576

Warning: include(): Failed opening ‘/vendor/composer/…/doctrine/cache/lib/Doctrine/Common/Cache/Psr6/DoctrineProvider.php’ for inclusion (include_path=‘/public/legacy/include/…:.:/opt/cpanel/ea-php83/root/usr/share/pear’) in /vendor/composer/ClassLoader.php on line 576

Fatal error: Uncaught Error: Class “Doctrine\Common\Cache\Psr6\DoctrineProvider” not found in /vendor/doctrine/orm/src/Configuration.php:497 Stack trace: #0 /cache/prod/ContainerPxDLuKR/App_KernelProdContainer.php(691): Doctrine\ORM\Configuration->setMetadataCache(Object(Symfony\Component\Cache\Adapter\PhpArrayAdapter)) #1 /cache/prod/ContainerPxDLuKR/App_KernelProdContainer.php(655): ContainerPxDLuKR\App_KernelProdContainer::getDoctrine_Orm_DefaultEntityManagerService(Object(ContainerPxDLuKR\App_KernelProdContainer), Object(ContainerPxDLuKR\EntityManagerGhost6410e2e)) #2 /vendor/symfony/var-exporter/Internal/LazyObjectState.php(100): ContainerPxDLuKR\App_KernelProdContainer::ContainerPxDLuKR{closure}(Object(ContainerPxDLuKR\EntityManagerGhost6410e2e)) #3 /vendor/symfony/var-exporter/LazyGhostTrait.php(178): Symfony\Component\VarExporter\Internal\LazyObjectState->initialize(Object(ContainerPxDLuKR\EntityManagerGhost6410e2e), ‘metadataFactory’, ‘Doctrine\ORM\En…’) #4 /vendor/doctrine/orm/src/EntityManager.php(318): ContainerPxDLuKR\EntityManagerGhost6410e2e->__get(‘metadataFactory’) #5 /vendor/symfony/doctrine-bridge/PropertyInfo/DoctrineExtractor.php(221): Doctrine\ORM\EntityManager->getClassMetadata(‘ApiPlatform\Sta…’) #6 /vendor/symfony/doctrine-bridge/PropertyInfo/DoctrineExtractor.php(61): Symfony\Bridge\Doctrine\PropertyInfo\DoctrineExtractor->getMetadata(‘ApiPlatform\Sta…’) #7 /vendor/symfony/property-info/PropertyInfoExtractor.php(83): Symfony\Bridge\Doctrine\PropertyInfo\DoctrineExtractor->getTypes(‘ApiPlatform\Sta…’, ‘title’, Array) #8 /vendor/symfony/property-info/PropertyInfoExtractor.php(56): Symfony\Component\PropertyInfo\PropertyInfoExtractor->extract(Object(Symfony\Component\DependencyInjection\Argument\RewindableGenerator), ‘getTypes’, Array) #9

You can get rid off warning by changing it in the php.ini file.


Please check your .env.local file and your DB configuration.


To overcome the error you need to clear symfony cache by running next command on your SuiteCRM 8 instance root:

./bin/console cache:clear

I only turned it on to see the errors. I now get a 500 error

That’s weird! What all things did you change in your system?

I give up lol I’m just going to reinstall it. I can’t be sure but i think there is a problem with the password engine and special characters

Please follows these docs:


1 Like

I deleted the whole thing and reinstalled 8.81 from scratch. Working fine now, just going to take a couple of hours to recreate my data

Thanks for the help. I’ll see you when I mess up upgrade to 8.8,2

1 Like