あれから6年。いまどきのSamba 4.8.7/FreeBSD11.2で確認してみたところ、概ね期待通りに動作するようになっているっぽいです。但し幾つか注意点は有るようで。
POSIX準拠パーミッションのみは使用しない
NFSv4ACLが指定されておらず、従来のPOSIX準拠パーミッション（以下パーミッション）しかないファイルをそのまま使うと、下記のようなことが起こります。
FreeBSD(Samba4)でファイルサーバを構築で、Windows側のパーミッションがおかしい
原因は、パーミッションのACLへの変換がいけてないため。
パーミッションしか無いファイルに対してACL取得要求が有ると、パーミッションをACLの形に変換するわけですが、Write属性はこんな風に変換されます。
from POSIX permission
-w-p--a-R-c--s:-------
一方で、WindowsからACLで書込みのみ可と設定すると、こんな感じに。
from Windows ACL
-w-p---A-W----:-------
パーミッションから変換されたACLは、Windowsから書込んだACLと比較すると、A[write_attributes]とW[write_xattr]が足りない。
すると、Windowsから見て「書込みに必要な権限が足りない＝書込み出来ない」という解釈になるわけです。
つまり、パーミッションから変換されたACLがおかしい…と。しかし困ったことに、このACL変換ルールは、zfsの仕様みたいなんですよね。
FreeBSDはzfsの仕様通りにパーミッションをACLに変換し、sambaは仕様通りOSから取得したACLをそのまま返し、Windowsは受け取ったACLを正しく解釈して「書込み不可」と。どないせぇっちゅうねんw
ま、とりあえずは、Samba共有で使用するファイルに、全てWindowsが期待するACLを付与しておけば回避出来るんじゃ無いかと思います。継承はちゃんと動作しているっぽいんで。
macOSから使えない
所有者以外の書込み権限が付与されたファイルに対し、Microsoft officeで上書きすると書込み権限が無くなったり、ACLがおかしくなります。
macOSのcifsクライアントがACL理解しないため、書込み時にパーミッションとして書込み可を指定するため、先のいけてない変換ルールが逆にACLとして書込まれてしまいます。
netatalkで代用しようにも、zfsacl扱えない為、論外。
AppleはAFP捨ててCIFS推しみたいですが、ならもう少しきちんと実装してくれよ…と。
ピンバック: いまどきのSamba/freebsd/zfsacl事情（2021版） – 人生という名の酷道で遭難中