PHP写文件Permission denied的直接原因是PHP进程用户对目录缺少w和x权限，解决方法首选chown设属主为www-data并配合理权限，次选ACL授权，同时应采用原子写入避免并发问题。
PHP fopen() 或 file_put_contents() 报错 Permission denied
直接原因是 PHP 进程运行用户（如 www-data、apache 或 nginx）对目标文件或其所在目录没有写权限。不是文件“只读”属性问题，而是系统级用户权限控制生效了。
常见现象包括：file_put_contents(): failed to open stream: Permission denied、fopen(): unable to open file for writing，尤其在替换已有文件（如覆盖 config.php）时高频出现。
- 先确认 PHP 进程用户：
ps aux | grep -E '(apache|httpd|nginx|php-fpm)'，看实际 worker 用户名（比如www-data） - 检查目标路径的属主和权限：
ls -ld /path/to/dir和ls -l /path/to/file - 目录必须对 PHP 用户有
w（写）和x（执行，即进入权限），缺一不可；文件本身是否可写，取决于目录权限是否允许创建/删除/重命名 - 不要用
chmod 777临时解决——这会绕过安全边界，且在多数生产环境被 SELinux 或容器限制直接拦截
用 chown 把目录属主设为 PHP 运行用户
这是最干净、最推荐的做法，尤其适用于独立部署的项目目录（如 /var/www/myapp）。
操作前确保 PHP 用户已存在（如 www-data），再执行：
立即学习“PHP免费学习笔记（深入）”；
sudo chown -R www-data:www-data /var/www/myapp sudo chmod -R u+rwX,g+rwX,o-rwx /var/www/myapp
说明：
-
-R递归设置子目录与文件 -
u+rwX：属主读写执行（X表示“仅对目录或已有执行位的文件加 x”，更安全） -
g+rwX：同组用户读写执行（便于开发协作） -
o-rwx：其他用户彻底无权限，避免信息泄露
Linux 下启用 ACL 支持细粒度授权（适合多用户共管场景）
当不能把整个目录属主改成 www-data（比如开发用户也要直接编辑文件），ACL 是比改属主更灵活的选择。
确认文件系统支持 ACL（通常 ext4 默认开启），然后启用并授予权限：
sudo setfacl -R -m u:www-data:rwx /var/www/myapp sudo setfacl -R -d -m u:www-data:rwx /var/www/myapp
第二条中的 -d 表示“默认 ACL”，确保新创建的文件/目录自动继承该权限。注意：setfacl 在某些容器环境（如 Alpine）需额外安装 acl 包。
验证是否生效：getfacl /var/www/myapp，应看到类似 user:www-data:rwx 的行。
PHP 中避免直接替换文件，改用原子写入（file_put_contents(..., LOCK_EX)）
即使权限正确，直接 unlink() + fopen() 替换文件，在并发请求下可能引发“文件不存在”或“部分写入”问题。更健壮的做法是用原子写入 + 重命名：
$temp = tempnam(sys_get_temp_dir(), 'php_write_');
if (file_put_contents($temp, $content, LOCK_EX) !== false && rename($temp, $target)) {
// 成功
} else {
unlink($temp);
throw new RuntimeException('Failed to write file atomically');
}
关键点：
-
tempnam()确保临时文件路径安全（不在 web 可访问目录下） -
LOCK_EX防止多进程同时写同一临时文件 -
rename()在 Linux 下是原子操作，替换瞬间完成，不会出现“中间态” - 务必检查
rename()返回值，失败时清理临时文件
这个模式不解决权限问题本身，但能大幅降低因权限边界模糊（如 umask、父目录 sticky bit）导致的偶发失败概率。真正卡住的地方，往往还是目录的 x 权限没给到位——很多人只记得加 w，却忘了进不去目录就什么都干不了。
