PHP图像处理报“Permission denied”核心是Web服务器用户（如www-data）无权写入目标路径，需确认实际运行用户、逐级检查父目录x权限、修复SELinux上下文，并用is_writable()提前校验。
PHP图像处理报“Permission denied”不是代码写错了，而是系统不让它碰那个目录——核心是Web服务器用户（比如www-data）没被授权写入目标路径。
确认PHP实际运行用户是谁
脚本里exec('whoami')或posix_getpwuid(posix_geteuid())['name']返回的不一定是真实执行者。Apache、Nginx + PHP-FPM 的用户可能不同，尤其用php-fpm池配置了user/group时，得看对应pool的配置文件（如/etc/php/*/fpm/pool.d/www.conf里的user = www-data）。
验证方式：
- 在目标服务器上执行
ps aux | grep php-fpm，找worker进程的USER列 - 或临时建一个
whoami.php：<?php echo exec('id -u -n'); ?>，用浏览器访问 - 别依赖
get_current_user()，它返回的是文件所有者，不是执行者
目录权限必须满足“可进入 + 可写”两个条件
PHP要在/var/www/html/uploads里保存缩略图，光给uploads设chmod 775不够——它上面每一级父目录（/var、/var/www、/var/www/html）都必须对www-data有x（执行）权限，否则连目录都进不去。
立即学习“PHP免费学习笔记（深入）”；
检查命令：ls -ld /var /var/www /var/www/html /var/www/html/uploads
常见错误：
-
/var/www/html属主是root:root且权限是755→www-data能进能读，但不能在下面创建子目录 - 修复建议：把
uploads目录属组设为www-data，再chmod g+ws uploads（s保证新文件继承组） - 避免直接
chmod 777，生产环境会触发安全扫描告警
SELinux上下文不匹配是CentOS/RHEL系的隐藏杀手
即使ls -l显示权限全开、chown也做了，fwrite仍报错，先跑getenforce。如果是Enforcing模式，再看目录上下文：ls -Z /var/www/html/uploads。
典型问题：
- 上下文是
system_u:object_r:httpd_sys_content_t:s0→ 默认只读，不许写 - 正确应为
httpd_sys_rw_content_t，修复命令：sudo semanage fcontext -a -t httpd_sys_rw_content_t "/var/www/html/uploads(/.*)?"，然后sudo restorecon -Rv /var/www/html/uploads - 临时测试可用
setenforce 0，但上线前必须配好策略，不能留着禁用状态
PHP代码里别硬扛权限失败，要提前拦截并报具体原因
靠is_writable()判断比等fopen()失败后再查error_get_last()更主动。注意：is_writable()对目录只检测“是否允许创建文件”，不保证磁盘有空间或inode够用。
实用检查逻辑：
if (!is_dir($dir)) {
die("目录不存在：$dir");
}
if (!is_writable($dir)) {
$perms = substr(sprintf('%o', fileperms($dir)), -4);
die("目录不可写（当前权限：$perms），请检查属主/组及SELinux上下文");
}
关键点：
- 别在
mkdir()后立刻chmod()，因为umask可能覆盖你设的权限；建议mkdir($dir, 0775, true)+chgrp('www-data', $dir) -
open_basedir限制路径时，is_writable()可能返回false但不报错，得结合ini_get('open_basedir')一起判断 - GD库处理图片时若需临时写入缓存（比如
imagejpeg()到文件），同样受该目录权限约束——不是只读操作
最常被忽略的是：上传目录的父路径权限链和SELinux上下文，这两处一漏，调半天chmod都没用。
