/shared/vms目录ACL配置异常：qemu对最新VM无有效权限求助

这个问题挺有意思的——毕竟umask最多是限制默认权限，不会直接把某个用户的权限砍成完全拒绝。咱们一步步拆解可能的原因：

1. 父目录存在拒绝型ACL条目 #

最可能的原因是/shared/vms或者它的父目录/shared设置了拒绝qemu用户访问的ACL规则。拒绝条目在ACL里的优先级是高于允许条目的，哪怕你后续给文件加了允许权限，也会被这条拒绝规则覆盖。

你可以用这两个命令查看详细ACL配置：

getfacl /shared/vms
getfacl /shared/vms/[你的新VM文件名]

重点看输出里有没有deny user:qemu rwx这类带deny的行，如果有，那就是它在搞鬼。

2. 父目录的默认ACL没有包含qemu权限 #

如果父目录的默认ACL（default ACL）里没有给qemu用户分配任何权限，再结合你桌面用户的umask 0007（会限制其他用户的所有权限），新创建的文件可能完全不对qemu开放权限。

用getfacl /shared/vms查看输出里的default:开头的条目，比如如果默认ACL只有针对owner和group的规则，没有default:user:qemu:rwx这类条目，那新文件继承的ACL就不会给qemu留权限。

3. virt-manager的存储池权限配置问题 #

你用virt-manager创建VM时，对应的存储池可能没配置qemu的访问权限。有些存储池类型（比如dir类型）会根据virt-manager的设置自动给新创建的磁盘文件设置权限，如果存储池的配置里没把qemu加入允许列表，就会出现这种完全拒绝的情况。

你可以打开virt-manager，找到对应的存储池，查看它的“权限”设置；或者查看libvirt的日志（比如/var/log/libvirt/qemu/*.log），看看有没有关于权限拒绝的报错信息。

4. SELinux/AppArmor等强制访问控制的限制 #

别忽略系统的MAC（强制访问控制）模块！比如SELinux如果处于enforcing模式，哪怕文件的DAC（自主访问控制）权限看起来没问题，也会阻止qemu访问文件。

你可以先临时关闭SELinux测试：

getenforce  # 先看当前状态
setenforce 0  # 临时切换到permissive模式

如果这时候qemu能访问文件了，那就是SELinux上下文的问题，需要给VM文件设置正确的标签：

chcon -t virt_image_t /shared/vms/[你的新VM文件名]

要是用的是AppArmor，就检查对应的配置文件是否允许qemu访问/shared/vms目录。

5. 创建工具的权限逻辑问题 #

如果你是用qemu-img这类工具直接创建磁盘文件，它可能有自己的权限设置逻辑，会忽略umask或者父目录的ACL。比如qemu-img create默认会创建权限为600的文件，要是文件的属主是你的桌面用户，属组也不包含qemu，那qemu自然完全没权限访问。

你可以用ls -l /shared/vms/[你的新VM文件名]查看文件的属主属组和权限，如果是-rw-------这种权限，那问题就出在这了——要么调整qemu-img的创建参数，要么创建后修改文件权限/属组。

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