Thank you for both mails, and for the pointer to the 2018 thread, which I have now read through.
I had first tried an aclmode=ignore, and that turned out to be the ignored no-op the thread warns about. I then rewrote it the way the thread describes as aclmode=decoupled, but I have not tested that yet, and I have come to wonder whether it is a good direction. With it the mode no longer matches the ACL, and POSIX (XBD 4.7) and RFC 8881 section 6.4 both ask that the two be kept in step, so it could be a hard one to get accepted. Before going further I would like to see how far the existing aclmode=passthrough can go. It keeps ACEs for named users and groups across chmod and only rewrites owner@, group@ and everyone@, so a share whose rights are all in named groups may behave well already, although everyone@ needs some care. I will try this and write again with what I find. -- zakinko 2026年11月4日(水) 19:52 <[email protected]>: > > On Mon, Nov 02, 2026 at 01:49:23PM +0100, [email protected] wrote: > > This issue has been discussed on the zfs-devel mailing list at least once > > (in July 2018) > > https://zfsonlinux.topicbox.com/groups/zfs-devel/T82e4ca6ba5be23dd/zfs-devel-acls-usability-was-re-native-zfs-nfs4-acl-support-issue-4966 > > Please check the system administrator view there. Otherwise it looks > like the worlds of zfs-developers and system administrators had been > isolated from each other. > > The zfs acl functionality has remained woefully inadequate for decades, on > all platforms. NetBSD has a chance to do it right (and fully compatible, > if the other aclmodes are made available). The "aclmode=decoupled" > is presumably also the easiest mode to implement and debug first. > > The interaction between acls and "owner"/"group"-based rights evaluation > is in the platform-specific ZFS code. This presents an opportunity to > avoid importing the enforced conflation from Linux and FreeBSD. > > /od2uvb
