人生という名の酷道で遭難中

「令和の！」って言ってみたかったけど、検索キー汚すだけなんでやめました。確認したのはFreeBSD 14.3&Samba 4.22.6とmacOS 26.2

わっかんないよ！

Web記事で言ってることはひとつもわかんないよ！

Web記事でいいって言ってるもの、何がいいのかわかんないよ！

わかんない！　私にはわかんないの！

いやまじで。

FreeBSDとLinuxじゃ事情が違うんだよ。みんな安易にFinderから読み書きできて「これでOK」なんて言うけど、特定アプリからアクセスしたら不具合いっぱいとかあるんだよ。macOSをガチで使ってるユーザー少ないから、Sambaのアップデートでfruit周りにエンバグ出ても誰も気づいてくれないんだよ。

マジでもうわっかんないんだよ（ぉ。

まぁそんな感じなんですが、Appleが公式にafp捨てるって言い出したんで、そろそろまじめにSambaでmacOS向けのファイル共有に取り組もうかと。

そんな感じで現状の設定がこちら。なんとなく動いてる気がするけど、あってるかどうかもうよくわかんない。「FreeBSD&ZFS&netatalkのmetadata/resouceを引き継ぐ」って組み合わせのサンプルが少なすぎて…。

[global]
    dos filetimes = Yes
    dos filemode = Yes
    inherit permissions = Yes
    inherit acls = Yes
    map acl inherit = Yes
    acl group control = Yes

    ea support = yes           #4.9以降はdefault yes
    vfs object = zfsacl catia fruit streams_xattr
        
    fruit:encoding = native     #default: private
    fruit:metadata = netatalk   #default
    fruit:resource = file       #default

    fruit:veto_appledouble = no #default: yes

    streams_xattr:prefix = user.
    streams_xattr:store_stream_type = no

    nfs4:mode = simple
    nfs4:acedup = merge
    nfs4:chown = yes

ZFSACLまわりの設定は、このあたりをよくみてください。基本的にACLはldapとかでユーザー同期してないと意味ないんで「とりあず不都合ないように」程度の設定です。

ファイル名のエスケープ

    vfs object = zfsacl catia fruit streams_xattr
    fruit:encoding = native     #default: private

これのためにvfs_catiaが必要。macOSの特有の文字コードのエスケープ方法の指定で、netatalk互換が不要なら初期値のprivateのままでいい。副作用として、nativeではfruit:metadata=streamやruit:resource=streamと組み合わせた場合に完全に動作しないらしい。

MetadataとResource forkの保存場所

    fruit:metadata = netatalk   #default
    fruit:resource = file       #default

“fruit:metadata = netatalk”の場合、vfs_fruitが直接拡張属性へアクセスに行きます。なので、streams_xattr関連の設定は、このfruitの設定なら要らないような気がします。過去の試行錯誤の名残なんですが、検証するのが面倒だったのでそのまま残っています。

“fruit:metadata = stream”にしてvfs_streams_xattr経由で拡張属性に保存することもできますが、netatalkと微妙に保存方法が違い、互換性がありません。

fruit:resourceについては、近頃はfruit:resource=streamの設定例が出回っていますが、個人的には非推奨です。あれは「自分の運用ではリソースフォークを使わない」という確信がある場合の設定です。

macOS向けファイルサーバーの面倒なところは、メインのファイルストリームの他に、属性情報のためのMetadataとmacOS独特のリソースフォークという情報があることです。Sambaのデフォルトでは、metadataはUNIXの拡張属性に、リソースフォークは”._”で始まる隠しファイルに保存されます。

一部のファイルシステムでは拡張属性のサイズに上限がありません（確かNTFSも）。なんで”._”で始まる隠しファイル（通称ゴミファイル）を作るよりも、同じく拡張属性に保存した方がスマートなのはその通り。

一方でFreeBSDをはじめとした多くのOSでは拡張属性にはサイズ制限があって、ぶっちゃけサイズの大きいリソースフォークを保存すると破綻します。というのも、まずUFSだと拡張属性が64kB以上扱えません。Metadataくらいなら問題ありませんが、リソースフォークに64kBを超えるカスタムアイコンかいたりするとぶっ壊れます。

一方でZFSの場合は容量制限は無いのですが、サイズが増える(数十kB以上から)と加速度的にアクセス速度が落ちる（数秒〜数十秒単位で）という特性があります。そういう仕様らしいです。1ファイルあたり秒単位でアクセス時間かかってたらいろんなところでタイムアウト起こして、様々な不具合を引き起こします。SSDとかNVMeにすればいいってもんでもなく、そう言う仕様。

なので、FreeBSDではディレクトリに”._”で始まるリソースフォークファイルがばら撒かれる設定が必須です。一度、streamに設定してみたことあるんですが、ファイルコピーが成功したり失敗したり、よくわからない不安定な振る舞いになりました。

“fruit:veto_appledouble = no”について

これは、”._”で始まるリソースフォークファイルを、クライアントから直にファイルシステムとして見えるのを隠すかどうかのフラグで、デフォルトはYes。

以前はそれでなんの問題もなかったのですが、冒頭のバージョンの組み合わせだと、”no”に設定しないとクライアントからリソースフォークが見えませんでした。つまりはカスタムアイコンがまったく見えない。

Samba側かmacOS側か、どっちが悪いのかわからないけれどバグっぽいです。いつからそうなったとか検証するの、もう疲れたよ⚪︎トラッシュ・・・。

SambaのGlobalと各共有セクションの記述について

vfsオブジェクトを追加するとき、globalセクションで追加してオプション設定してても、各共有セクションでvfsのロード指定したら、globalセクションで指定したvfsのためのオプションはクリアされるらしい…という記述を見つける。

つまり、globalセクションであらかたオプション設定して、各共有セクションで追加でオプション変更するような記述するとき、各共有セクションでvfs objectを指定したらあかんらしい…。

時々不可解な振る舞いになってたのは、このせいか…。

macOSでsamba/netatalkファイル共有時によくあるトラブル

macOSからsamba/netatalkファイル共有へのアクセスにおいて、一見動いているように見えて細かな設定で対応しないと、以下のようなトラブルが起きる…という例を最後に示しておきます。

1. Apple製ソフトで開いたファイルを編集した時「上書き保存」が出来ない。
2. Microsoft Office関連のソフトで開いたファイルを編集したた時「上書き保存」ができない。
3. TimeMachineが使えない。
4. 内部にDBを持つソフト（ミュージック/写真/Finalcut/Lightroomなど）で、DBが部分的に破損する。

基本的に共有上のファイルを、アプリから直接開きに行く場合ですね。

1と2の原因は、リソースフォークだったりEAまわりだったり、ACL周りだったりします。どちらも保存前のファイルに対して、EAやらACLを書き換えて保存無しでファイルを閉じるときには元通りに戻すと言う事を、ユーザーの見えないところで勝手にやろうとして自爆します。

ちなみにMicrosoft officeでのACL周りのトラブルは、Windowsとsambaでもきちんと設定しないと起きます。

3はあらかた不具合がこなれた感じです。

4はまだまだ油断ならない感じ…。