chmod() 返回 false 且报 Operation not permitted，根本原因是文件所有者非 Web 进程用户或 root，即使有写权限也无法调用 chmod()，需检查文件属主、Web 进程用户身份、SELinux/SIP、容器挂载权限及 umask 设置。
chmod() 返回 false 且报 Operation not permitted
PHP 脚本执行 chmod() 失败，错误提示类似 Operation not permitted，本质不是 PHP 语法或函数调用问题，而是底层系统权限限制。Linux/macOS 下，只有文件所有者（或 root）才能修改该文件的权限；即使 Web 服务器进程（如 www-data、nginx、_www）对文件有写权限，也不等于它能调用 chmod() —— 这需要对文件 inode 的所有权或 CAP_FOWNER 能力。
- 检查文件当前所有者：
ls -l /path/to/file，确认是否属于 Web 进程用户（如www-data） - Web 进程通常无权修改非自己创建的文件权限，哪怕它有写权限（例如通过 FTP 上传的文件，属主是 ftp 用户）
- SELinux 或 macOS 的 sandbox（如 SIP）也可能拦截 chmod 系统调用，需单独排查
- 容器环境（Docker）中，若挂载卷时未指定 uid/gid，宿主机文件在容器内可能显示为 root 所有，导致 PHP 进程无法 chmod
chown() 和 chmod() 都被拒绝？先确认运行用户身份
很多开发者直接改代码加 chown()，却忽略 Web 服务实际以哪个用户身份运行。PHP 中调用 posix_getpwuid(posix_geteuid()) 可查当前有效用户，但更可靠的是在终端里查：
ps aux | grep -E '(apache|httpd|nginx|php-fpm)' | head -n1
常见情况：
- Apache + prefork：常为
www-data（Debian/Ubuntu）或daemon（CentOS） - Nginx + PHP-FPM：FPM pool 配置中的
user和group（如/etc/php/*/fpm/pool.d/www.conf）才决定 PHP 实际身份 - 本地开发（MAMP/XAMPP）：macOS 上可能是
_www，Windows 上则无此限制（但 NTFS 权限仍可能干扰）
绕过 chmod() 的实用替代方案
如果只是想让文件可读/可写（比如日志、缓存、上传目录），与其硬刚 chmod()，不如从源头控制权限：
立即学习“PHP免费学习笔记（深入）”；
- 上传文件后立即用
fopen(..., 'c')或file_put_contents(..., ..., LOCK_EX)写入内容，新文件自动继承父目录的 umask 设置（推荐设 umask 0002） - 在 PHP-FPM pool 配置中添加：
process.umask = 0002，这样所有由 PHP 创建的文件默认权限为 664/775 - 将 Web 进程用户加入目标目录所属组，并确保目录权限含 g+w（如
chmod 775 /var/www/uploads），再用chgrp uploads /var/www/uploads - 避免在运行时调用
chmod()修改单个文件权限 —— 这几乎总是设计缺陷，应交由部署脚本或 CI/CD 统一处理
调试时临时提权？不建议，但可快速验证
仅限开发环境排查，切勿用于生产：
- 临时把 PHP-FPM pool 的
user改成root（危险！会引发严重安全漏洞） - 给 PHP-FPM 二进制文件加 capability：
sudo setcap cap_fowner+ep /usr/sbin/php-fpm8.2（仅 Linux，且需内核支持） - 更稳妥的做法：用
sudo -u www-data php -r "var_dump(chmod('/tmp/test', 0644));"在命令行复现，排除 Web 服务器层干扰
真正卡住的地方往往不在 PHP 函数本身，而在文件归属链和 umask 遗留行为。一个被 root 解压的 vendor 目录，即使 chmod 777 也救不了 PHP 的写入失败 —— 因为它缺的是“所有权”，不是“权限数字”。
