PHP文件报“Permission denied”通常因路径权限链断裂或误加执行权限；Web环境应设目录755、文件644，避免chmod -R误改目录权限；SELinux/AppArmor启用时需用chcon调整上下文。
PHP 文件执行时报 “Permission denied” 错误
Linux 服务器上直接执行 php script.php 却提示权限不足，通常不是 PHP 解释器没权限，而是 shell 尝试以可执行方式运行该文件（即当成二进制或脚本直接调用），而文件缺少 x（执行）权限。但绝大多数 PHP 场景下，你根本不需要给 .php 文件加执行权限——PHP 是被解释器读取执行的，只要 Web 服务器（如 Apache/Nginx）或 CLI 用户有读权限即可。
常见误操作：看到报错就盲目 chmod +x script.php，结果反而埋下安全隐患（比如上传的 PHP 文件被意外执行）。
- Web 环境中，PHP 文件只需
644（所有者可读写，组/其他仅读） - CLI 手动运行时，用
php script.php，不依赖文件本身是否可执行；只有写成#!/usr/bin/env php开头并chmod +x后才能直接./script.php - 若真要设为可执行脚本，确保开头有正确的 shebang 行，且路径准确（如
#!/usr/bin/php或#!/usr/bin/env php）
Web 服务器访问 PHP 文件显示 500 或空白页，检查文件与目录权限组合
Apache/Nginx 报 500 错误，日志里出现 Failed to open stream: Permission denied，大概率是权限链断裂：Web 服务进程（如 www-data、nginx 或 apache 用户）无法逐级进入目录、读取文件。
关键点不在单个 PHP 文件，而在整个路径：/var/www/example.com/index.php 要求 /var、/var/www、/var/www/example.com 每一级都对 Web 用户有执行（x）权限（即能 cd 进入），且最终文件有读（r）权限。
立即学习“PHP免费学习笔记（深入）”；
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 推荐目录权限：
755（所有者 rwx，组/其他 rx）——保证 Web 进程可进入 - 推荐文件权限：
644（所有者 rw，组/其他 r）——保证 Web 进程可读 - 避免
777或666：开放组/其他写权限极易被恶意篡改 - 注意用户归属：若文件属主是
ftpuser，但 Web 进程是www-data，则必须靠组权限或读权限兜底，不能依赖属主权限
用 chmod 修改权限时，为什么数字模式比符号模式更稳妥？
新手常用 chmod u+x 或 chmod a+r，看似直观，但容易遗漏隐含状态。比如 chmod u+x file.php 只添加执行位，但若原权限是 600（-rw-------），执行后变成 700（-rwx------），反而把原本开放给组/其他的读权限关掉了，导致 Web 进程（非属主）无法读取。
显式指定八进制更可控，也方便复现和审计：
-
chmod 644 *.php—— 统一设为安全可读的 PHP 文件权限 -
chmod 755 uploads/ logs/—— 允许 Web 进程写入的目录需额外确认是否真需要写权限（如日志目录常需755+ 属组为www-data） - 慎用递归：
chmod -R 644 .会把目录也设成644，导致无法cd—— 应先find . -type d -exec chmod 755 {} \;，再find . -type f -name "*.php" -exec chmod 644 {} \;
SELinux 或 AppArmor 启用时，chmod 无效怎么办？
CentOS/RHEL 默认启用 SELinux，Ubuntu/Debian 可能启用了 AppArmor。此时即使 chmod 和属主都正确，PHP 仍可能因安全模块拦截而报权限错误，典型现象是：错误日志里没有明确路径拒绝信息，ls -l 看权限完全正常，但就是打不开。
快速验证是否是它在作祟：
- 临时禁用（仅测试）：
sudo setenforce 0（SELinux）或sudo systemctl stop apparmor（AppArmor），再试访问 - 查看拒绝记录：
sudo ausearch -m avc -ts recent（SELinux）或sudo dmesg | grep -i avc - 修复方案不是关 SELinux，而是用
chcon设置正确上下文，例如：chcon -t httpd_sys_content_t /var/www/example.com/（Apache 场景）
这类策略限制比文件权限更底层，也更容易被忽略——尤其当服务器刚重装或迁移过应用时。
