PHP的chmod()在Linux下失败的根本原因是调用者（如www-data）既非文件所有者也非root，无权修改权限位；必须用0755等八进制字面量传参，验证需decoct(fileperms()&0777)，且需排查SELinux、容器挂载等隐蔽拦截。
PHP 的 chmod() 在 Linux 下失败，根本不是“不能用”，而是调用者没资格
Linux 下 chmod() 函数返回 false 或报 Operation not permitted，99% 的情况不是函数失效，而是当前 PHP 进程用户（比如 www-data、nginx）既不是文件所有者，也不是 root。系统强制规定：只有文件属主或特权用户才能修改其权限位。
- 用
ls -l /path/to/file看第三列（属主），确认是否等于ps aux | grep php-fpm查到的运行用户 - 父目录必须对 PHP 用户可写（
w位），否则连 inode 元数据都改不了 —— 这和文件本身读写权限无关 -
@chmod()会吞掉错误，掩盖问题；应显式判断：if (!chmod($file, 0644)) { error_log("chmod failed on $file"); } -
is_writable($file)返回true≠ 能chmod()；前者只测内容写入能力，后者是所有权操作
chmod() 参数传错导致“设了但没生效”
传参格式错，结果就不可控：传字符串 "0755" 或十进制 755 都会出问题。PHP 把 "0755" 当作整数 0 处理，把 755 当作十进制数（八进制约等于 1363），最终常被截成 0777。
- 必须用带前缀
0的八进制整数字面量：chmod($file, 0755) - 验证是否真生效：
decoct(fileperms($file) & 0777)，输出如"755"才算对 - 注意
umask干扰：如果脚本里调过umask(0002)，chmod(0777, $f)实际可能只落到0775
Web 环境下真正该管的不是单个文件，而是路径结构和属组
硬在 PHP 里调 chmod() 改权限，往往是设计反模式。生产环境应靠部署阶段统一控制归属与默认权限，而非运行时修补。
- 把需写入的目录（如
runtime/、uploads/）属组设为 Web 用户组：chown -R :www-data /var/www/html/runtime - 目录设
775（drwxrwxr-x），文件设664（-rw-rw-r--），并确保父目录都有x权限（否则连路径都遍历不了） - 在 PHP-FPM pool 配置中加
process.umask = 0002，让 PHP 创建的所有新文件自动继承合理权限 - 避免递归
chmod -R 755整个项目目录——它会把.env、composer.lock等文件也设成可执行，引发安全或兼容问题
别忽略更隐蔽的拦截层：SELinux、容器挂载、NFS
即使所有权和 umask 都对，chmod() 仍可能静默失败。这些环境因素常被跳过排查：
立即学习“PHP免费学习笔记（深入）”；
- SELinux 启用时（
getenforce返回Enforcing），即使传统权限全开也会拦截chmod系统调用；临时测试可用setenforce 0 - Docker 容器挂载宿主机目录时，若未指定
uid/gid，文件在容器内显示为root所有，PHP 进程无法修改 - NFS 挂载若带
noacl或root_squash，chmod()直接无效，返回false - 某些文件带不可修改属性（
lsattr filename输出含i），得先chattr -i filename（需 root）
sudo -u www-data ls -l /path/to/file 和 namei -l /path/to/file 逐级看权限链。很多 “Permission denied” 根本不是目标文件的问题，而是中间某层目录缺 x —— 连进去都做不到，更别说改权限。 
