Test system: ============ FreeBSD bsdrookie.norma.com. 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r297415: Fri Apr 1 10:16:09 YEKT 2016 emz@bsdrookie.norma.com.:/usr/obj/usr/src/sys/BSDROOKIE amd64 zfs - most recent version: # zpool upgrade -v This system supports ZFS pool feature flags. The following features are supported: FEAT DESCRIPTION ------------------------------------------------------------- async_destroy (read-only compatible) Destroy filesystems asynchronously. empty_bpobj (read-only compatible) Snapshots use less space. lz4_compress LZ4 compression algorithm support. multi_vdev_crash_dump Crash dumps to multiple vdev pools. spacemap_histogram (read-only compatible) Spacemaps maintain space histograms. enabled_txg (read-only compatible) Record txg at which a feature is enabled hole_birth Retain hole birth txg for more precise zfs send extensible_dataset Enhanced dataset functionality, used by other features. embedded_data Blocks which compress very well use even less space. bookmarks (read-only compatible) "zfs bookmark" command filesystem_limits (read-only compatible) Filesystem and snapshot limits. large_blocks Support for blocks larger than 128KB. The following legacy versions are also supported: VER DESCRIPTION --- -------------------------------------------------------- 1 Initial ZFS version 2 Ditto blocks (replicated metadata) 3 Hot spares and double parity RAID-Z 4 zpool history 5 Compression using the gzip algorithm 6 bootfs pool property 7 Separate intent log devices 8 Delegated administration 9 refquota and refreservation properties 10 Cache devices 11 Improved scrub performance 12 Snapshot properties 13 snapused property 14 passthrough-x aclinherit 15 user/group space accounting 16 stmf property support 17 Triple-parity RAID-Z 18 Snapshot user holds 19 Log device removal 20 Compression using zle (zero-length encoding) 21 Deduplication 22 Received properties 23 Slim ZIL 24 System attributes 25 Improved scrub stats 26 Improved snapshot deletion performance 27 Improved snapshot creation performance 28 Multiple vdev replacements For more information on a particular version, including supported releases, see the ZFS Administration Guide. Issue: ====== either setfacl or some internal subsystem treats NFSv4 ACLs with disregard to the inheritance flags, i.e. different NFSv4 ACLs are treated as one. A self-explanatory example: I want to set different inherited ACLs for files and directories, in a way when directories don't inherit 'x' permission (I am aware about 'passthrough-x' option for ZFS, but this is different thing): [root@bsdrookie:local/public]# mkdir 1 [root@bsdrookie:local/public]# getfacl 1 # file: 1 # owner: root # group: wheel owner@:rwxp--aARWcCos:-------:allow group@:r-x---a-R-c--s:-------:allow everyone@:r-x---a-R-c--s:-------:allow [root@bsdrookie:local/public]# setfacl -m user:emz:rwpDdaARWcCos:f:allow 1 [root@bsdrookie:local/public]# getfacl 1 # file: 1 # owner: root # group: wheel user:emz:rw-pDdaARWcCos:f------:allow owner@:rwxp--aARWcCos:-------:allow group@:r-x---a-R-c--s:-------:allow everyone@:r-x---a-R-c--s:-------:allow [root@bsdrookie:local/public]# setfacl -m user:emz:rwxpDdaARWcCos:d:allow 1 [root@bsdrookie:local/public]# getfacl 1 # file: 1 # owner: root # group: wheel user:emz:rwxpDdaARWcCos:-d-----:allow owner@:rwxp--aARWcCos:-------:allow group@:r-x---a-R-c--s:-------:allow everyone@:r-x---a-R-c--s:-------:allow Actual result: either setfacl or some other subsystem treats this NFSv4 ACL as one, while it should treat this as different ACLs. It's impossible to set ACLs for one user on one file/directory with different inheritance, at least for files/directories. Some may still insist that this behavior is consistent with the design, and I should still use 'passthrough-x' zfs inheritance mode. So let's look at a reference ZFS implementation, an actual Solaris system (or may be two): Solaris 10 (SunOS 5.10 Generic_142910-17 i86pc i386 i86pc): [root@atlas /var/www]# mkdir 1 [root@atlas /var/www]# ls -Vd 1 drwxr-xr-x+ 2 root root 2 апр. 12 08:02 1 user:git:rw-pdDaARWcCos:f-i---:allow user:git:rwxpdDaARWcCos:-di---:allow user:git:rwxpdDaARWcCos:------:allow owner@:--------------:------:deny owner@:rwxp---A-W-Co-:------:allow group@:-w-p----------:------:deny group@:r-x-----------:------:allow everyone@:-w-p---A-W-Co-:------:deny everyone@:r-x---a-R-c--s:------:allow [root@atlas /var/www]# chmod A+user:emz:rwxp:f:allow 1 [root@atlas /var/www]# chmod A+user:emz:rwp:d:allow 1 [root@atlas /var/www]# ls -Vd 1 drwxr-xr-x+ 2 root root 2 апр. 12 08:02 1 user:emz:rw-p----------:-d----:allow user:emz:rwxp----------:f-----:allow user:git:rw-pdDaARWcCos:f-i---:allow user:git:rwxpdDaARWcCos:-di---:allow user:git:rwxpdDaARWcCos:------:allow owner@:--------------:------:deny owner@:rwxp---A-W-Co-:------:allow group@:-w-p----------:------:deny group@:r-x-----------:------:allow everyone@:-w-p---A-W-Co-:------:deny everyone@:r-x---a-R-c--s:------:allow Solaris 11 (SunOS 5.11 11.2 i86pc i386 i86pc): [root@hyperion emz]# mkdir 1 [root@hyperion emz]# ls -Vd 1 drwxr-xr-x 2 root root 2 апр. 12 08:16 1 owner@:rwxp-DaARWcCos:-------:allow group@:r-x---a-R-c--s:-------:allow everyone@:r-x---a-R-c--s:-------:allow [root@hyperion emz]# chmod A+user:emz:rwpd:f:allow 1 [root@hyperion emz]# ls -Vd 1 drwxr-xr-x+ 2 root root 2 апр. 12 08:16 1 user:emz:rw-pd---------:f------:allow owner@:rwxp-DaARWcCos:-------:allow group@:r-x---a-R-c--s:-------:allow everyone@:r-x---a-R-c--s:-------:allow [root@hyperion emz]# chmod A+user:emz:rwxpd:d:allow 1 [root@hyperion emz]# ls -Vd 1 drwxr-xr-x+ 2 root root 2 апр. 12 08:16 1 user:emz:rwxpd---------:-d-----:allow user:emz:rw-pd---------:f------:allow owner@:rwxp-DaARWcCos:-------:allow group@:r-x---a-R-c--s:-------:allow everyone@:r-x---a-R-c--s:-------:allow Both reference ZFS systems behave as expected.
"setfacl -m" merges the entry into ACL - it doesn't append it, it replaces an entry with the same tag and id. You want to use "setfacl -a0" instead.
So, does this work for you? If so, I'll close it as "works as intended".
Yup, it does indeed. But since the '-m' article fragment was mentioning "modify", I was thinking it modified ACL entries, not merges.
Well, it _did_ modify the entry, replacing the old one ('user:emz:rw-pDdaARWcCos:f------:allow') with the new one ('user:emz:rwxpDdaARWcCos:-d-----:allow') :-)