困った。使い物にならないっぽい。サーバーリプレースにあたり，zfsaclで綺麗にWindowsのACL対応できるぜっ！って思ったら甘かったでござる。そもそもsambaのvfs_zfsaclの情報が少なすぎるもんで，とりあえずメモとして。
まずzfsacl(FreeBSD側)の基本から。SolarisではchmodでACL操作することになっているけれど，FreeBSDではsetfacl/getfaclがzfsacl…というかNFSv4ACLに対応している。（ちなみに，いつのまにかUFSでもNFSv4ACLが使える模様）POSIX古来のパーミッションは以下のようにマッピングされる。各文字の属性はsetfaclのmanか，Solarisのページに詳しく載ってる。
-w- > -w-p--a-R-c--s --x > --x---a-R-c--s --- > ------a-R-c--s
そして，オーナーには自動的に以下のACLが付いてくる。
--- > ------aARWcCos
d(delete_child)/D(delete)が付かないけれど，zfsaclにはwxの付いたフォルダはDと同等と見なされるというルールがあるので，ファイル削除は問題なく動作する（このあたりもSolarisのZFSACL解説ページに詳しく載ってる）。
うちはACLについては基本的に，上位フォルダから全て継承(inherit)させる運用なんで，zfsのほうもそれに併せてプロパティの設定を行う。以降，このzfs設定についての動作結果。ほかの設定は知らん。
aclmode passthrough local aclinherit passthrough local
FreeBSD自体の継承動作
FreeBSD側の振る舞いとしては，owner@/group@/everyone@の基本3エントリに継承フラグが一切無かったら，POSIXのパーミッションと同じよう扱われ，umaskの結果が反映される。
一方，基本3エントリのどれか一つでも継承フラグが立っていると，継承フラグに沿って新規ディレクトリ／ファイルにACLが継承される。
このとき，たとえばgroup@にしか継承フラグが無かったりすると，group@のみが継承された，owner@もeveryone@もACEに存在しないACLが設定されたりする。
パーミッションが設定されていないとかでは無く，ACEがそもそもリストに存在しない。最初みたとき何だこれ？って思ったけど，こういう物なんだろうか…。
Samba経由Windowsアクセス時の継承動作
で，次はsamba側の設定。OSSTechの文章に詳しく載っている。
ドキュメント内でも述べられているけれど，sambaが本来持っているアクセス権の継承機能を全て止めなければならない。でないと，基本3エントリがPOSIX古来のパーミッションで上書きされてしまい，元々のACL情報を失ってしまう。
基本3エントリ以外に追加したACEは，そのまま継承フラグに沿って継承されるっぽい。
OSSTech Samba 3.2 インストールガイド 第 3.6 版
で，実際にsambaからアクセスしてみるとどうにも思った通り動いてくれない。たとえば，下記のようなACLを持ったディレクトリ内で，新規ディレクトリを作ってみる。
親ディレクトリ
# file: dir
# owner: watanki
# group: nobody
group:cas:rwxpDdaARWc--s:fd----:allow
owner@:rwxp--aARWcCos:fd----:allow
group@:rwxpDdaARWc--s:fd----:allow
everyone@:------a-R-c--s:fd----:allow
新規ディレクトリ作成
# file: dir/新しいフォルダー/
# owner: watanki
# group: nobody
group:cas:rwxpDdaARWc--s:fd----:allow
owner@:rwxp--aARWcCos:fd----:allow
group@:rwxpDdaARWc--s:fd----:allow
everyone@:------a-R-c--s:fd----:allow
エクスプローラーからファイル名を変えてみる（基本3エントリ崩壊）
# file: dir/新しいフォルダ
# owner: watanki
# group: nobody
group:cas:rwxpDdaARWc--s:fd----:allow
owner@:rwxp--aARWcCos:------:allow
group@:rwxp--a-R-c--s:------:allow
everyone@:--x---a-R-c--s:------:allow
新規ファイルを作ってみる
# file: dir/新規 Microsoft Excel ワークシート.xlsx（基本3エントリ継承されず）
# owner: watanki
# group: nobody
group:cas:rwxpDdaARWc--s:------:allow
owner@:rwxp--aARWcCos:------:allow
group@:rwxp--a-R-c--s:------:allow
everyone@:------a-R-c--s:------:allow
新規ディレクトリ作成まではいいんだけど，エクスプローラー上でリネームするだけでACL崩壊。
基本3エントリがPOSIXパーミッションで上書きされてしまう。なんじゃこりゃ？ファイル名変えるだけでアクセス権書き換えられるとか，前代未聞。
新規ファイル作成に至っては，最初から基本3エントリにはACEが継承されない。それでもまぁ，POSIXパーミッションとしては継承されているので，100歩譲って，基本3エントリはowner@以外アクセス不能なパーミッションにしておいて，追加のACLで運用するっていう苦肉の策は取れなくも無い。
しかしここで致命的な問題発生。MS Officeである。
どういう訳か，MS Officeってファイル保存時には，単に上書きせずに，新規ファイル作成したりACLを弄くり回す，sambaから見ると困った仕様になっている。
下記の例ではwatanokiはcasグループに属している状態。編集ファイルはeveryone@は一切許可が無く，グループcasのACEによってのみ，書き込み可能な状態。
親ディレクトリ
# file: dir
# owner: watanki
# group: nobody
group:cas:rwxpDdaARWc--s:fd----:allow
owner@:rwxp--aARWcCos:fd----:allow
group@:rwxpDdaARWc--s:fd----:allow
everyone@:------a-R-c--s:fd----:allow
編集対象のファイル
# file: dir/新規 Microsoft Excel 97-2003 ワークシート.xls
# owner: nobody
# group: nobody
group:cas:rwxpDdaARWc--s:------:allow
owner@:rwxp--aARWcCos:------:allow
group@:rwxp--a-R-c--s:------:allow
everyone@:------a-R-c--s:------:allow
Excel2010で保存（owner@エントリが消失）
# file: dir/新規 Microsoft Excel 97-2003 ワークシート.xls
# owner: watanoki
# group: nobody
group:cas:rwxpDdaARWc---:------:allow
user:nobody:rwxp--aARWcCo-:------:allow
group@:rwxp--a-R-c---:------:allow
everyone@:------a-R-c---:------:allow
Excel2000で保存（owner@に謎のdenyエントリが追加）
# file: dir/新規 Microsoft Excel 97-2003 ワークシート.xls
# owner: watanoki
# group: nobody
owner@:r-------------:------:deny
group:cas:rwxpDdaARWc---:------:allow
user:nobody:rwxp--aARWcCo-:------:allow
owner@:--x---aARWcCos:------:allow
group@:r-x---a-R-c--s:------:allow
everyone@:------a-R-c--s:------:allow
あーもぅ！酷いもんだ。
Excel2000に至っては保存時にエラーまで出た上に，owner@に読み取り属性deny立っているもんだから，見かけの上ではファイル消失。これってFreeBSD側の問題というより，先のフォルダ名リネームといい，samba側でクライアントからのACE操作要求を正しく処理できていない臭いような…。
Solarisでは本当にちゃんと運用できているんだろうか。
結局，ACLのいらないディレクトリは，vfs_zfsaclなしでPOSIXパーミッションだけで運用。ACLが必要なディレクトリは，禁じ手？のzvolデバイスをUFS2フォーマットしてPOSIX ACLとか。
うわぁ，ひでぇ運用だ。
