我来帮你拆解这个问题——你遇到的现象其实是默认ACL、rwX权限位的解析逻辑，以及umask、mask条目三者交互的细节导致的：

先明确rwX的真实行为 #

首先再把手册里的规则用更直白的方式理清楚：

rwX中的X不是固定的执行权限，它是一个条件触发的权限位：

• 如果新建的是目录：X直接等价于x（毕竟目录需要执行位才能进入）；
• 如果新建的是文件：只有当文件的初始权限（即0666经过umask过滤后的权限）中，已经存在任意用户（所有者、组、其他）的执行位时，X才会被解析为x；否则X就相当于不存在，只有rw权限生效。

为什么你会看到“系统尝试赋予执行权限” #

当你执行setfacl -d -m u:daemon:rwX /your/dir时，setfacl会自动帮你调整默认mask条目为rwX（如果你没手动指定mask的话）。这是因为mask需要覆盖所有默认用户/组条目的权限集合，确保后续应用ACL时不会超出范围。

这个rwX的mask会被存在目录的默认ACL配置里，所以你查看目录的ACL时会看到rwX的写法——这很容易让你误以为系统要给新建文件加执行位，但实际上：

1. 新建文件的基础权限是0666，经过umask过滤后（比如umask022的话就是0644），没有任何用户的执行位；
2. 此时rwX中的X对文件不生效，daemon用户实际获得的权限是rw-；
3. 你看到的“被文件掩码阻止”，其实是X权限位因为条件不满足而没有被激活，并非系统真的尝试加执行位然后被umask干掉。

为什么会造成相关问题 #

大概率是某些程序在处理权限时，没有正确解析ACL中的X条件位：

• 有些工具可能直接读取目录的默认ACL配置，看到rwX就误认为执行位是允许的，从而触发异常逻辑；
• 少数场景下，mask条目的rwX写法会被误判，导致权限检查逻辑出错。

验证与解决办法 #

1. 验证实际权限：在目录下新建一个文件，用getfacl your-file查看，你会看到daemon用户的权限是rw-（有效权限也是rw-），说明X确实没有生效；
2. 优化ACL配置：如果你想确保万无一失，可以手动明确默认mask（其实setfacl会自动处理，但手动设置更清晰）：

   # 设置默认ACL让daemon对目录有rwx，对文件有rw-
   setfacl -d -m u:daemon:rwX /your/dir
   # 手动设置默认mask为rwX（适配目录的执行位需求）
   setfacl -d -m mask::rwX /your/dir
   

3. 针对异常程序调整：如果是特定程序出问题，可能需要排查该程序的权限检查逻辑，确保它能正确解析ACL中的条件权限位X。

内容的提问来源于stack exchange，提问作者JW.