ZFS ACL inheritance results in automatically adding NFSv4 special entries (owner@, group@, everyone@) to inherited ACLs which is confusing to Windows users maintaing ACLs via Windows tools and expecting Windows semantics. ZFS will automatically add these these entries when calculating the inherited ACL of new files if the ACL of the parent directory lacks an inheriting special entry. This may result in user confusion and unexpected change in permissions of files and directories as the inherited ACL is generated. Blocking this behavior is achieved by setting an inheriting everyone@ that grants no permissions and not adding the entry to the file's Security Descriptor when the client queries the SD.
This bug was referenced in samba master: f763b1e43640082af80c855a4a519f7747a6c87c c10ae30c1185463eb937f69c1fc9914558087167
Created attachment 16300 [details] Patch for 4.12 backported from master
Created attachment 16301 [details] Patch for 4.13 cherry-picked from master
Re-assigning to Karolin for inclusion in 4.13.next, 4.12.next.
(In reply to Jeremy Allison from comment #4) Pushed to autobuild-v4-{13,12}-test.
This bug was referenced in samba v4-13-test: 1b03a34523110abbc7478d4633d37994fca760fa 50bb50341dfc268248cc22b7b1820f6278d82f06
This bug was referenced in samba v4-12-test: 78d843f43626a876557d3c6738329282adeb4dab 1bf997aa2443248b07933dfc2dc5d9f3cadeef4b
Closing out bug report. Thanks!
This bug was referenced in samba v4-13-stable (Release samba-4.13.2): 1b03a34523110abbc7478d4633d37994fca760fa 50bb50341dfc268248cc22b7b1820f6278d82f06
This bug was referenced in samba v4-12-stable (Release samba-4.12.10): 78d843f43626a876557d3c6738329282adeb4dab 1bf997aa2443248b07933dfc2dc5d9f3cadeef4b
I think this is a problem that should not be handled in the zfsacl module but at the generic nfs4_acl layer as it affects all nfs4 implementations. The root issue is that Samba does not use windows-style permission semantics, see related bug 8963 and bug 6877.
There's a related discussion in bug 13809 as well