「メンバーの誰もが書き込めて、メンバーの誰もが読み出せて、しかしフォルダやファイルの削除だけは作成者本人しか出来ない領域」

を作ろうとしてもなかなか上手く行かない。

ああそうだ、こういう場合はディレクトリにsticky bitを立てるんだったなと思ってchmod 1777 sharedとかやっても、やっぱり他人にもファイルを削除できてしまう。

最初はsamba側の設定がおかしい(force user=誰々とかね）のかと思っていたけど、そうでもない。散々試行錯誤していたところ、zfsのACLの問題じゃないかと思い至った。

https://lists.freebsd.org/pipermail/freebsd-stable/2014-July/079340.html

ｷﾀ――(ﾟ∀ﾟ)――!!　まさにこれですよ！

…なるほどね。従来のchmodじゃあダメなのね。(でも/tmp/はsticky bitが上手く動いてる気もするんだけどまあ気にしない）

という訳で、samba共有フォルダに対して↑のようにaclを設定してあげたら希望通りの動作になったような気がしています。(後方互換的にsticky bitが動作するようにしといて欲しいけどまあその辺りは色々と事情があるんでしょう)

以上、個人的( ..)φメモメモ

さて、最近何故か某所から某所へのsambaアクセスが繋がったり繋がらなかったりする事例が発生していました。VPN越しなのでVPNの問題か？と思いpingやtracerouteをしても、経路は問題無さそう。サーバ側からトレースすると到達するけどsamba歯繋がらなかったりと、訳の分からない挙動にしばらく悩まされていました。

で、先程原因が分かってようやく解決に至りました。原因は、パケットフィルタリングで

pass in quick on $int_if proto tcp from <lan> port 1024:65535 to $samba_ip port {20,21,110,139,445,49152:65535}

というルールを定めていたのが理由でしたわ。これまでは、Windowsファイル共有サービスのアクセス元ポートが1024～65535を使ってくれていたのが、最近特権ポートを使ってくれていて、それが元で切られていたという。

うーん。こういうWindows側の仕様変更？ってあるんですかね。良く分からん。