最典型原因是PHP以www用户运行而宝塔文件管理用root用户操作，需确认PHP运行用户为www、目录权限为755（含x和w位）、open_basedir包含实际写入路径且防跨站设置不冲突。
PHP 脚本写入失败但宝塔文件管理能创建文件
这是最典型的权限混淆：你在宝塔「文件管理」里点新建，实际是用你的 SSH 登录用户（比如 root）操作的；而 PHP 进程是以 www 用户身份运行的，两者权限不共享。
验证方式很简单：在网站根目录放个 test.php，内容为 <?php echo exec('whoami'); ?>，访问后看输出是不是 www。如果不是，说明 PHP 没跑在预期用户下。
- 检查站点配置里的「运行用户」：宝塔「网站」→ 站点 → 「配置文件」→ 查
user行，必须是www - 确认 PHP-FPM 设置：「PHP 管理」→ 对应版本 → 「服务」→ 「PHP-FPM 设置」→ 「运行用户」字段也得是
www - 别信面板界面“能点就代表能写”，它只是前端代理你自己的用户权限
目录所有者是 www 但 still Permission denied
所有者对了还不够——www 用户得有「进入目录」和「在目录里新建文件」的权限，也就是目录必须同时有 x（执行，即进入权限）和 w（写）位。
运行 ls -ld /www/wwwroot/your-site.com/runtime，输出类似 drwxr-xr-x 3 www www 4096 Apr 20 10:22 runtime 才算合格。如果第二列是 www，但权限是 drw-r--r--（即 644），那就缺 x，www 根本进不去这个目录。
- 修复命令：
chmod 755 /www/wwwroot/your-site.com/runtime（注意不用-R，只设目录本身） - 子目录若也要写入（比如
cache/、log/），再单独跑一次：chmod 755 /www/wwwroot/your-site.com/runtime/cache - 已有文件不用给
x，保持644更安全；chmod -R 644会把目录也变成不可进入，反而更糟
open_basedir 限制导致 file_put_contents 失败
错误信息长这样：Warning: file_put_contents(): open_basedir restriction in effect. File(/www/wwwroot/your-site.com/cache/data.txt) is not within the allowed path(s)。这不是权限问题，是 PHP 主动拦的。
宝塔默认只把当前站点路径加进 open_basedir，比如 /www/wwwroot/your-site.com。但如果你的缓存目录是软链接到 /data/cache，或日志写到了 /www/wwwroot/your-site.com/../logs，就会被拒绝。
- 查当前设置：宝塔「PHP 管理」→ 对应版本 → 「配置修改」→ 搜索
open_basedir - 临时放开调试：改成
/www/wwwroot/your-site.com:/tmp:/data（把真实路径都加进去，用英文冒号分隔） - 改完必须重启 PHP-FPM，否则不生效；改错会导致整个站点 502
- 别留空或填
none，那等于彻底关闭限制，生产环境极不推荐
防跨站设置（enable_pathinfo）与目录写入冲突
宝塔「网站」→ 站点 → 「配置文件」里如果启用了防跨站（即开启了 enable_pathinfo 或加了 fastcgi_param PHP_ADMIN_VALUE "open_basedir=..."），它可能覆盖你在 PHP 配置里设的 open_basedir，造成双重限制。
更隐蔽的是：有些框架（如 Laravel）依赖 public/ 目录外的写入能力，但防跨站规则硬编码只允许 public/ 下路径，结果 storage/logs 就写不进去。
- 先关掉站点配置里的「防跨站」开关，测试是否恢复写入
- 若必须开启防跨站，就得把需要写入的路径显式加进该站点的
open_basedir值里，而不是依赖全局 PHP 设置 - 注意：防跨站开关和 PHP 配置里的
open_basedir是两套机制，优先级不同，容易互相打架
真正卡住人的地方往往不是权限数字没调对，而是 open_basedir 和防跨站设置叠在一起，报错还显示成 “Permission denied”，让人反复折腾 chown 和 chmod 却毫无进展。
