php执行permission denied是因php进程运行用户对文件或目录无对应权限，需确认该用户（如www-data）是否具备读/写/执行权限，并检查open_basedir限制、属组继承及父目录执行位。
PHP 执行时提示 Permission denied 是谁的权限没配对？
不是文件没给 755 就万事大吉。关键看 PHP 进程以哪个用户身份运行，再看该用户对目标文件或目录有没有对应权限。比如 Apache 通常用 www-data（Debian/Ubuntu）或 apache（CentOS/RHEL），而 Nginx + PHP-FPM 则取决于 www.conf 里 user 和 group 的配置。用 ps aux | grep php-fpm 或 ps aux | grep apache2 确认实际运行用户。
常见错误现象：file_put_contents(): failed to open stream: Permission denied、require(): Failed opening required，往往不是代码问题，而是 PHP 进程用户根本读不了那个文件，或者写不了那个目录。
- 先查 PHP 进程用户：
ps aux | grep -E '(php-fpm|apache|httpd)' - 再查文件属主和权限：
ls -l /path/to/your/file.php - 确保该用户至少有读权限（文件）或读+执行（目录）；写操作还需写权限
用 chmod 改权限但没用？检查是否忽略了用户组继承
chmod 只改「权限位」，不改「归属用户/组」。如果文件属组不是 PHP 进程用户所在的组，光设 g+r 也没用。更常见的是：你把文件 chown 给了 deploy:www-data，又给了 664，但 PHP 进程用户是 www-data，它能读——可一旦你用 FTP 或 sudo -u deploy 上传新文件，新文件默认属组还是 deploy，www-data 就读不了了。
- 设置目录的 setgid 位，让新文件自动继承父目录属组：
chmod g+s /var/www/html - 确保 PHP 进程用户在目标组里（如
www-data用户必须属于www-data组） - 上传后手动修复属组：
chgrp -R www-data /var/www/html，再补权限：chmod -R g+rX /var/www/html（X表示仅对目录和已有执行位的文件加执行）
PHP-FPM 下 open_basedir 和权限是两回事，别混淆
即使文件权限全开、属主正确，PHP 仍可能报 file not found 或 failed to open stream——这时很可能是 open_basedir 在拦截。它和系统权限无关，是 PHP 自己的路径白名单限制。
检查方式：phpinfo() 搜索 open_basedir，或看 php-fpm.d/www.conf 中是否有 php_admin_value[open_basedir] 配置项。
- 临时关闭测试（仅开发环境）：
php_admin_value[open_basedir] = none - 生产环境应精确配置路径，例如：
/var/www/html:/tmp - 注意：哪怕
/var/www/html/uploads权限 777，只要不在open_basedir列表里，file_get_contents()依然失败
写日志或上传目录为什么非得 775 而不是 755？
因为 755 表示「组用户只有执行权（进目录），没有写权」，而上传或日志追加需要组有写权限。但直接 777 太危险，尤其当 Web 目录可被外部访问时。
- 安全做法：上传目录单独剥离出 Web 根目录（如
/var/www/uploads不在/var/www/html下），再通过符号链接或 Nginx alias 暴露 - 若必须同目录，用
775+ 正确属组（如chown -R deploy:www-data uploads/），并禁用该目录下 PHP 执行（Nginx/Apache 配置中拒绝.php解析） - 避免用
umask全局调成002，它会影响所有进程创建的文件，容易埋雷
最易被忽略的一点：权限问题常跨层出现——你改了文件权限，却忘了父目录缺少执行位（x），导致 PHP 根本进不去那层路径。排查时从根目录一级级 ls -ld 看过去，比瞎猜快得多。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
