phpMyAdmin会话失败的根本原因是PHP的session.save_path目录不存在、权限不足或被SELinux/AppArmor拦截，需检查并修复目录、属主、权限及安全策略。

session.save_path 指向的目录不存在或不可写

phpmyadmin 启动时提示 session save path not writable 或直接报错 failed to initialize storage module，本质是 php 尝试往 session.save_path 配置的路径写文件失败。不是 phpmyadmin 本身的问题，而是 php 的 session 存储层卡住了。

常见操作误区：只改了 php.ini 里的 session.save_path，却没同步创建对应目录、设对权限，或者用了 root 创建但 web 进程（如 www-data、apache、nginx）无权访问。

• 确认当前生效的 session.save_path：在 phpMyAdmin 根目录放一个 info.php，内容为 <?php phpinfo(); ?>，浏览器打开后搜 session.save_path 值
• 检查该路径是否存在：ls -ld /var/lib/php/sessions（典型路径，以实际值为准）
• 若目录不存在，手动创建：sudo mkdir -p /var/lib/php/sessions
• 设对属主和权限：sudo chown www-data:www-data /var/lib/php/sessions（Debian/Ubuntu）或 sudo chown apache:apache /var/lib/php/sessions（CentOS/RHEL）；权限建议 sudo chmod 1733 /var/lib/php/sessions（保证 sticky bit + 写入权限）

SELinux 或 AppArmor 阻止 Apache/Nginx 写入 session 目录

Linux 发行版启用强制访问控制（SELinux on CentOS/RHEL，AppArmor on Ubuntu）时，即使目录权限全开，web 进程仍可能被策略拦截写入。错误不直接报权限，而是静默失败或日志里出现 avc: denied 类似记录。

典型现象：ls -ld 看权限没问题，chown 也做了，但 session_start() 仍失败；tail -f /var/log/audit/audit.log | grep avc（SELinux）或 sudo dmesg | grep apparmor 能看到拒绝日志。

• 临时验证是否是 SELinux 导致：运行 sudo setenforce 0，再试 phpMyAdmin；若恢复正常，说明是它挡的
• 永久放行（推荐）：sudo semanage fcontext -a -t httpd_var_run_t "/var/lib/php/sessions(/.*)?"，然后 sudo restorecon -Rv /var/lib/php/sessions
• Ubuntu 上 AppArmor：编辑 /etc/apparmor.d/local/usr.sbin.apache2，加一行 /var/lib/php/sessions/** rwk,，再执行 sudo systemctl reload apparmor

PHP-FPM 场景下，pool 配置覆盖了全局 session.save_path

用 Nginx + PHP-FPM 部署时，php.ini 里设的 session.save_path 可能被某个 FPM pool 的 php_admin_value[session.save_path] 覆盖。这时改 php.ini 没用，得去 FPM 配置里找。

立即学习“PHP免费学习笔记（深入）”；

表现是：phpinfo() 显示的 session.save_path 和 php.ini 不一致；或者改完 php.ini 重启 PHP-FPM 也没效果。

• 查所有 pool 配置：grep -r "session.save_path\|php_admin_value.*session" /etc/php/*/fpm/pool.d/
• 若发现类似 php_admin_value[session.save_path] = /var/lib/php/fpm/sessions，那就得确保这个路径存在且权限正确（同第一部分）
• 也可统一在 pool 里注释掉这行，让其回落到 php.ini 全局配置，更易维护

session.save_path 设成 tmpfs（内存盘）后忘记持久化或容量不足

有人为提升性能把 session.save_path 改成 /dev/shm 或 /run/shm 这类内存文件系统。好处是快，坏处是重启丢失、且默认空间小（常为 64MB），大流量下容易写满。

现象是：phpMyAdmin 偶发性登录失败、会话中断，dmesg 或 journalctl -u php*-fpm 里能看到 No space left on device 提示，但磁盘明明充足。

• 检查 tmpfs 使用率：df -h /dev/shm
• 扩容（临时）：sudo mount -o remount,size=256M /dev/shm
• 永久扩容：修改 /etc/fstab 对应行，例如 tmpfs /dev/shm tmpfs defaults,size=256M 0 0
• 注意：/dev/shm 是易失的，服务器重启后 session 全丢，不适合需要长期保持登录态的场景

最麻烦的其实是多级覆盖——比如 .htaccess 里用 php_value session.save_path、Nginx fastcgi_param、FPM pool、php.ini 四层都可能设值，优先级有差异，调试时得一层层确认生效的是哪一层。别只盯着 phpMyAdmin 配置。