PHP进程用户无读权限报Permission denied，根源是系统用户（如www-data）对文件或路径缺少r/x权限、open_basedir限制或SELinux拦截；需逐级检查属主、目录执行权、open_basedir配置及SELinux上下文。
PHP 进程用户没权限读文件
报 Permission denied 时，不是 PHP 代码错了，而是运行它的系统用户（比如 www-data 或 www）对那个文件没有 r（读）权限。哪怕你用 root 写的文件，只要属主不是 PHP 进程用户，且其他用户没读权限，就会失败。
- 先查 PHP 实际用户：
ps aux | grep -E '(php-fpm|apache|nginx)'，或在脚本里加echo posix_getpwuid(posix_geteuid())['name']; - 再看文件权限：
ls -l /path/to/file.php，确认输出中对应用户那一列有r - 别只改
chmod 644就完事——如果文件属主是root，而 PHP 是www-data，那“其他用户”的r得开着才行；更稳妥的是chown www-data:www-data file.php
目录路径上缺 x 权限（最常被忽略）
想打开 /var/www/app/config.php，但 /var、/var/www 或 /var/www/app 中任意一层没 x 权限，fopen() 就直接跪。对目录来说，x = 能进入，没它连路径都走不通。
- 逐级检查：
ls -ld /var /var/www /var/www/app，每层都得有r-x（即至少755） - 常见坑：上传后手动
mkdir uploads，忘了chmod 755 uploads，结果file_put_contents('uploads/log.txt', ...)报错 - 容器环境里，宿主机挂载目录若用
noexec或nosuid，也会干扰，得看mount输出
open_basedir 或 SELinux 在背后拦着
权限全开、属主也对，还是 failed to open stream: Permission denied？大概率是 open_basedir 或 SELinux 拦截了，错误表现一模一样，但根源完全不同。
- 查
open_basedir：echo ini_get('open_basedir');，输出非空就说明启用了；宝塔默认开，路径必须精确包含实际访问路径（如/www/wwwroot/site/:/tmp/） - 查 SELinux：
ls -Z /path/to/file，Web 文件应为httpd_sys_content_t，可写目录需httpd_rw_content_t；临时验证可setenforce 0，但别长期关 -
error_get_last()捕获不到这两类错误——它们不是系统权限拒绝，而是 PHP 或内核策略拒绝，日志里才见真章
is_writable() 不能信，尤其在 NFS 和容器里
is_writable('/path') 返回 true 不代表真能写。NFS 共享、Docker 卷、某些云存储挂载点会欺骗这个函数，导致部署后突然失效。
立即学习“PHP免费学习笔记（深入）”；
- 真要验证，得动手试：
$f = fopen('/path/test.tmp', 'w'); if (!$f) { /* 处理失败 */ } - 配合
error_get_last()提取错误信息，比单纯依赖返回值靠谱得多 - 容器中更麻烦：宿主机 chown 有效，但容器内
chown常无效；得靠docker run --user www:www或构建镜像时预设 UID/GID
事情说清了就结束。权限问题从来不是单点故障，而是路径链、用户归属、安全模块三者咬合的结果——断掉任何一环，fopen() 都不会告诉你哪一环断了。
