CentOS 7 上给 /srv/share 设了 setfacl -d -m u:dev01:rwx，用 dev01 新建文件却没有任何权限，getfacl 该目录能看到 default 条目。
一开始怀疑是「用 mv 把外部目录移进来，目标目录自带的 ACL 会跟着一起搬入」，查了一圈，方向不对。
排查方向其实有限，先把可能性排一排。默认 ACL 只对设置它的那一层目录生效，子目录要单独设置才继承。另一种情况是cp 与 rsync 覆盖目录时会重建属性，把之前设好的 default 条目冲掉。
还有一种情况，应用创建目录时显式 chmod，把继承来的 ACL 覆盖成基础权限位。
上来先确认目录上的 default 条目
getfacl -p /srv/share | grep -i default递归补齐所有子目录的默认 ACL
find /srv/share -type d -exec setfacl -d -m u:dev01:rwx {} \;接着验证新建文件的继承结果
su - dev01 -c 'touch /srv/share/t.txt' && getfacl /srv/share/t.txt末了把设置写进部署脚本避免被覆盖
printf 'setfacl -R -d -m u:dev01:rwx /srv/share\n' >> /opt/init-share.sh别只看报错消失，验证要多做一步。新建文件的 getfacl 输出里出现 user:dev01:rwx 且 effective 为 rwx，dev01 无需额外授权即可读写，子目录同样带 default 条目。
默认 ACL 不会递归生效，这是最常见的误解；rsync 同步后要重新补一次，或者加 -A 保留属性，否则每次发布都会丢。线上能稳定复现的问题都不算难，难的是只在大流量下才出现的那种。