文件权限继承错乱源于目录树某级权限或属主设置不当，需通过setgid位、umask和默认acl协同实现可控继承，定位需对比不同用户创建文件的权限差异，修复需三步组合配置并批量修正旧文件。
文件权限继承错乱不是“脚本没加x”这种单点问题，而是目录树里某一级权限或属主设置不当，导致新创建的文件、子目录自动获得错误权限，进而引发部署时写入失败、服务无法读取配置、Git 拒绝提交等连锁报错。核心在于：Linux 本身不自动继承父目录权限，但可通过 setgid 位 + umask + 默认 ACL 三者协同实现可控继承。下面分三块讲清怎么定位、修复和长期防复发。
先确认是不是真由继承机制失效引起
别一看到“Permission denied”就改 chmod。先做两件事：
- 在目标部署目录（如 /opt/myapp）下手动创建一个测试文件：
touch testfile && ls -l testfile，看它的属主、属组、权限是否符合预期（比如应属 deploy 用户、deploy 组、权限 644） - 再用部署用户（如 www-data）尝试创建：
sudo -u www-data touch /opt/myapp/test-by-www，对比权限差异。如果两次结果不一致，说明继承逻辑已断
修复目录级继承：setgid + 组权限 + 默认 ACL
仅靠 chmod 775 或 chown root:deploy 不够。要让新文件自动归属 deploy 组，且组可读写，必须组合三步：
-
启用 setgid 位：对父目录执行
chmod g+s /opt/myapp。这样所有在该目录下新建的子目录/文件，其所属组自动继承为 myapp 目录的组（而不是创建者的主组） -
确保组有合理权限：运行
chmod 2775 /opt/myapp（开头的 2 表示 setgid）。此时目录权限显示为 drwxrwsr-x，中间那个 s 就是生效标志 -
设默认 ACL（推荐）：比 umask 更精准。例如让 deploy 组对所有新文件默认可读写：
setfacl -d -m g:deploy:rw /opt/myapp；对新目录还加执行权：setfacl -d -m g:deploy:rwx /opt/myapp
检查并统一 umask 和用户主组配置
即使目录设好了，若部署用户登录时 umask 是 0077（只给自己权限），或主组不是 deploy，新文件仍可能权限过严：
- 查当前 umask：
umask。生产环境建议设为 0002（对应文件 664、目录 775），可在 /etc/profile.d/umask.sh 中全局设置 - 确认部署用户主组是否为 deploy：
id deploy-user。如果不是，用usermod -g deploy deploy-user修改主组（注意：-g 改主组，-G 加附加组） - 若用 systemd 服务部署，还要检查 service 文件里的 UMask=0002 和 Group=deploy 是否配置
批量修复已有错乱文件
继承规则只管新文件。旧文件得手动清理：
- 递归修正属组：
chgrp -R deploy /opt/myapp - 重设目录权限（带 setgid）：
find /opt/myapp -type d -exec chmod 2775 {} \; - 重设文件权限（去 x，保 rw）：
find /opt/myapp -type f -exec chmod 664 {} \; - 补上默认 ACL 到所有子目录：
setfacl -R -d -m g:deploy:rw /opt/myapp
