对于我们正在设置的服务，我们的一台 Linux 服务器使用专用于此目的的特定服务帐户将 CIFS 挂载到我们的一台中央存储服务器。远程目录挂载到/mnt/server。中央存储服务器是 Windows。
该应用程序使用两个主要目录。第一个目录/mnt/server/data具有来自 Windows 的特定 DACL 设置，它为管理员提供完全控制权、对服务帐户的读/写访问权限以及为授权用户提供只读访问权限。
第二个是一个名为：的特殊子目录 /mnt/server/data/tmp，它具有特殊的 DACL：与另一个相同，除了用户无权读取、管理员具有完全控制权、服务帐户具有读写权，仅此而已。
文件由目录中的应用程序创建tmp，并在某个时候移出tmp到用户可读取的子目录中。由于位于mv同一卷上，即使文件很大，操作也非常快，这正是我们想要的。
问题在于，文件在创建时继承的 ACL 会随文件一起移动，因此用户无法访问新生成的文件，这不是我们想要的。
对每个移动的文件都使用它并不实际setcifsacl：（1）它无法工作，因为服务用户只有修改权限，而不是完全控制权限（因此它以 终止main: setxattr error: Permission denied），（2）这似乎过于复杂和不可靠（想象一下，如果由于一组新用户需要访问权限而导致 ACL 发生变化：应用程序需要相应地更新，而不仅仅是依靠继承，所以这是不可取的）。
此行为是由 Windows 服务器引起的，因此不是 的特例mount.cifs。在 Windows 上，显然可以调整 Explorer 以不移动 ACL：
由于客户端运行的是 Linux，因此这没有帮助，它甚至似乎特定于 Explorer，而不是文件访问本身。
相关内容：
我们唯一想到的办法就是从tmp目录中删除特殊 ACL 并将其隐藏，以防止用户随意浏览。文件进入可读部分时，里面没有任何敏感信息。这是为了让一切保持“干净”。
我怀疑答案是“否”。有没有办法指定 ACL 不应随文件一起“移动”，而不必诉诸可能需要更多时间的复制和删除操作？我们无法修复存储服务器上权限的缺陷设计，但可以根据需要在客户端上更新 ACL 和挂载选项。