phpMyAdmin 'Session Expired' Loop — 3 Fixes That Work

1. PHP Session Save Path Is Missing or Not Writable

This is the number one cause. I'd say nine out of ten times I've seen this, the PHP session directory either doesn't exist or the web server can't write to it. Had a client last month running XAMPP on Windows — their whole phpMyAdmin was useless because the session.save_path pointed to a folder that got deleted during a cleanup.

Here's the fix:

1. Find your php.ini file. On Linux it's usually /etc/php/7.x/apache2/php.ini (or /etc/php/7.x/cli/php.ini). On XAMPP, it's C:\xampp\php\php.ini. On WAMP, look in C:\wamp64\bin\php\php7.x\.
2. Search for the line session.save_path. It might be commented out with a semicolon or set to something like "" (empty).
3. Set it to an absolute path that exists. On Linux, I use /var/lib/php/sessions. On Windows, something like C:\xampp\tmp or C:\Windows\Temp works.
4. Make sure the directory exists and is writable by the web server user (www-data on Ubuntu, SYSTEM on Windows for Apache).

; In php.ini
session.save_path = "/var/lib/php/sessions"

After changing this, restart Apache or your web server. If you can't restart, you can test by creating a simple PHP file with phpinfo(); and checking the session.save_path value there. I've seen hosts where they set this to /tmp but that gets cleaned out — use a dedicated sessions folder instead.

2. Cookie Settings Are Blocking the Session

If the session path is fine, next suspect is the cookie. phpMyAdmin uses a cookie named phpMyAdmin to track your login. If that cookie can't be set or read, you're toast. This happens when:

• Cookie domain or path is wrong. If you're accessing phpMyAdmin from http://localhost/phpmyadmin but the cookie is set for / only, it might not match. Check the config.inc.php file (usually in /etc/phpmyadmin/ or alongside phpMyAdmin files).
• Cookie is set to HTTPS only but you're on HTTP. Look for $cfg['ForceSSL'] = true; — if you're not using HTTPS, change it to false or comment it out.
• Cookie lifetime too short. In config.inc.php, you'll see $cfg['LoginCookieValidity'] which defaults to 1440 seconds (24 minutes). I've bumped it to 3600 for some clients who work slowly.

// In config.inc.php
$cfg['ForceSSL'] = false;  // If not using HTTPS
$cfg['LoginCookieValidity'] = 3600; // 1 hour
$cfg['SessionSavePath'] = ''; // Leave blank to use php.ini setting

I remember a case where someone used a subdirectory like /mysite/phpmyadmin and forgot to set $cfg['PmaAbsoluteUri'] — that causes cookie path mismatches. Set it to the full URL: $cfg['PmaAbsoluteUri'] = 'http://localhost/mysite/phpmyadmin/';

3. PHP Session Garbage Collection Clearing Sessions Too Fast

Less common, but I've seen it bite people on shared hosting. PHP has a garbage collection mechanism that deletes old session files. If it's set too aggressively, it can wipe your session before you finish logging in.

In php.ini, look for these:

• session.gc_probability — defaults to 1 (means 1% chance per request)
• session.gc_divisor — defaults to 100
• session.gc_maxlifetime — defaults to 1440 seconds (24 minutes)

If the probability is high (say 50) and maxlifetime is low (like 300), sessions get wiped fast. I had a client who was using a managed WordPress host that set gc_probability to 100 — basically every request cleared old sessions. They couldn't stay logged in for more than a few clicks.

The fix: set gc_probability to 1 and gc_maxlifetime to at least 1440 (or higher, like 3600). Then set session.gc_divisor to 1000 to reduce the chance even more.

; In php.ini
session.gc_probability = 1
session.gc_divisor = 1000
session.gc_maxlifetime = 3600

If you can't touch php.ini (shared hosting), you can sometimes override it in .htaccess or a .user.ini file. But honestly, if the host is that locked down, you might be better off switching to a different phpMyAdmin setup, like using Docker or a local install.

Quick-Reference Summary Table