根本原因是PHP进程用户对$cfg['TempDir']路径无写执行权限，需设绝对路径、匹配属主、避开noexec挂载；验证is_writable()返回true是关键。
phpMyAdmin $cfg['TempDir'] 必须是绝对路径且属主匹配 PHP 进程用户
报错 tmp directory is not writable 的根本原因不是“没权限”，而是 php 进程（不是 apache/nginx 用户）无法在该路径下写入并执行缓存文件。常见错误是把 $cfg['tempdir'] 设成 /tmp 或相对路径，或只 chmod 777 却没改属主。
- 先确认 PHP 进程真实用户：
ps aux | grep 'php\|www-data\|apache'（Linux）或看phpinfo()输出的User/Group - 选一个持久、非 tmpfs 的绝对路径，例如
/var/lib/phpmyadmin/tmp（不推荐/tmp，systemd-tmpfiles 或 SELinux 可能清理或限制） - 创建目录并严格赋权：
sudo mkdir -p /var/lib/phpmyadmin/tmp && sudo chown www-data:www-data /var/lib/phpmyadmin/tmp（Debian/Ubuntu）或chown apache:apache（RHEL/CentOS） - 在
config.inc.php中添加：$cfg['TempDir'] = '/var/lib/phpmyadmin/tmp';（结尾不加斜杠）
挂载选项和文件系统限制会让 is_writable() 返回 false
is_writable() 不仅检查权限位，还检测挂载参数（如 noexec、nosuid）。即使 touch 成功，PHP 仍可能拒绝写入模板缓存，因为缓存文件需被 require_once 执行。
- 运行
php -r "var_dump(is_writable('/var/lib/phpmyadmin/tmp'));"验证 PHP 层面是否认可可写 - 若返回
false，查挂载参数：mount | grep $(df . | tail -1 | awk '{print $1}')，避开含noexec的挂载点 - NFS 或容器卷也常触发此问题；容器中必须挂载为读写卷，且以对应用户 UID 运行（如
-u 33对应 www-data）
TempDir 不可写不会导致登录失败，但会显著拖慢页面加载
模板缓存失效后，phpMyAdmin 每次请求都重新解析 PHP 模板文件（如 tbl_structure.lib.php.cache），尤其在库多、表多时，CPU 和 I/O 压力明显上升。这不是安全漏洞，但暴露了配置疏漏——攻击者可借此识别环境松散。
- 缓存文件由 PHP 进程直接写入，权限继承自进程 UID/GID，不是 web server 创建后再改属主
-
$cfg['blowfish_secret']和$cfg['TempDir']无关；前者控制加密会话，填错会导致登录态异常，但不会触发 tmp 报错 - 禁用 opcache 或强制
opcache.enable=0是无效缓解——它只让 PHP 解析更慢，不解决TempDir不可用问题
Docker 环境下 TempDir 必须挂载为持久卷且 UID 匹配
官方镜像默认未设 $cfg['TempDir']，且容器内 /tmp 是 tmpfs，重启即丢。phpMyAdmin 启动时若发现 TempDir 不可用，会静默降级，但日志里无明确提示，容易被忽略。
- 启动容器时挂载专用卷：
-v /host/path/phpmyadmin-tmp:/var/lib/phpmyadmin/tmp - 确保容器以正确 UID 运行：
--user 33:33（www-data）或--user 48:48（apache） - 在
config.user.inc.php（或挂载进容器的配置）中显式设置：$cfg['TempDir'] = '/var/lib/phpmyadmin/tmp'; - 不要依赖
docker exec -it ... chmod临时修复——容器重启后失效，且属主可能错乱
is_writable() 返回 true。少一个环节，缓存就掉回解释模式，性能滑坡，运维痕迹也更易被横向扫描捕捉。 
