755不行是因为组无写权限，web进程属组用户无法写入；应设775并启用setgid、检查selinux。
chmod 命令改权限时，为什么 755 不行，非得 775 或 777？
PHP 写入失败，多数不是代码问题，而是 Web 服务器（如 Apache、Nginx）运行用户没权限往目标文件夹里写。Linux 下文件夹权限是三位八进制数，755 表示「所有者可读写执行，组和其他人只可读和执行」——但 Web 进程往往不属于文件夹所有者，而是属于 www-data（Ubuntu/Debian）或 apache（CentOS）这类组。如果文件夹组权限没开写（即第二位不是 7），就卡住。
-
755→ 组无写权 → PHP 写入失败（常见报错：failed to open stream: Permission denied） -
775→ 组有写权 → 更安全，推荐先试这个 -
777→ 所有人可写 → 临时调试可用，生产环境别留着 - 确认 Web 进程所属组：命令
ps aux | grep apache或ps aux | grep www-data，再用groups www-data查它在哪些组
PHP 里用 chmod() 改不了权限？可能是 SELinux 或挂载选项拦住了
chmod() 函数在 PHP 脚本里调用，看似方便，其实经常静默失败。不是函数写错了，而是底层限制：比如系统启用了 SELinux（常见于 CentOS/RHEL），或者文件系统以 noexec、nosuid、noatime 等选项挂载，会禁止运行时修改权限；更常见的是，PHP 进程用户根本没权限去改那个目录的权限（只有所有者才能 chmod）。
- 检查是否 SELinux 启用：
sestatus；若为enabled，临时放行试试：setsebool -P httpd_write_content 1 -
chmod()返回true不代表成功，务必加判断：if (!chmod('/path/to/dir', 0775)) { echo 'chmod failed'; } - 绝大多数情况下，应该用 shell 命令一次性设好，而不是靠 PHP 每次去改
- 注意：FTP 用户上传的目录，默认属主常是 FTP 用户，Web 进程无法直接
chmod它
Apache 和 Nginx 的用户不一致，导致同一套权限配置在不同环境失效
开发机上用 XAMPP 或 MAMP 可能一切正常，一上服务器就报错，大概率是因为 Web 服务用户变了。Apache 默认用 www-data（Debian系）或 daemon（某些旧版），Nginx 默认也是 www-data，但有些定制镜像或手动编译的会改成 nginx 或 http。权限得跟着实际运行用户走，不能凭经验硬套。
- 查 Apache 当前用户：
grep '^User\|^Group' /etc/apache2/apache2.conf（Ubuntu）或/etc/httpd/conf/httpd.conf（CentOS） - 查 Nginx 当前用户：
grep '^user' /etc/nginx/nginx.conf - 把目标文件夹所属组设成 Web 用户所在组：
sudo chgrp -R www-data /var/www/html/uploads - 再补上组写权限：
sudo chmod -R g+w /var/www/html/uploads
用 chown 把文件夹 owner 设成 Web 用户？小心覆盖部署流程
有人图省事，直接 chown -R www-data:www-data /path，让 Web 用户完全接管。短期有效，但埋雷：如果后续用 Git 部署、rsync 同步或 Composer 安装，新文件默认归属部署用户（如 deploy），权限又断了；更糟的是，某些框架（如 Laravel）的 storage 和 bootstrap/cache 目录需要 Web 用户写，但源码本身不该被 Web 用户修改——混用 owner 容易引发安全或更新冲突。
立即学习“PHP免费学习笔记（深入）”；
- 正确做法是「分权」：目录 owner 保持部署用户，group 设为 Web 组，权限设
775，并确保setgid位开启（chmod g+s），让新建文件自动继承组 - 启用 setgid：
chmod g+s /var/www/html/storage，这样子目录和文件新建后 group 不会丢 - 避免
chown -R www-data，除非你明确接受每次部署后手动重设权限
