プラスα空間

ブログ in お市 のーと

NetatalkとSambaの共存の続編

昨日、私の場合のNetatalkとSambaの共存方法について書きました。

内容を、HATさんに確認していただきました。

その結果、

がんばって書いた記事が…
 _人人人人人人人人_
 >突っ込み所、満載<
  ̄Y^Y^Y^YY^Y^Y^Y ̄
 原因: [私の知識が不十分]
 文字数: 3823文字
 [ネットワーク技術習得ゲーム]

書いた記事に着いて、HATさんに非常に細かくチェックしていただきました。ありがとうございます。tweet内容をまとめさせていただきました。

上から順にいきます。

afp.confにおいて、vol preset=が定義されていないので、[my default values]のセクションが機能していません。

smb.confにおいて、veto files=にMacが使うファイルやディレクトリが設定されています。これはメタデータとは別の問題を引き起こします。Macが必要とするファイルやディレクトリがMacから見えない。

「AFPで/export/diskにつなぐと、メタデータ部分は拡張属性として保存されます」と書かれていますが、本当にそれが出来るのはZFSだけです。ZFS以外ではリソースフォークはAppleDoubleフォーマットで ._A.pngに保存されます。

「SMBで/export/diskにつなぐとメタデータ部分が「._」で始まるファイルに保存されます」と書かれていますが、それはsmb.confで代替データストリームを保存する設定をしていないからです。

現在のOS XはSMBサーバが代替データストリームに対応している場合、Macのメタデータを代替データストリームに変換してSMBサーバに送信します。FinderInfoはAFP_AfpInfoという名前の代替データストリームの中に入ります。リソースフォークはAFP_Resourceという名前になります。

smb.confにおいて、代替データストリームを拡張属性に保存する設定にしている場合、DosStream.AFP_AfpInfoとDosStream.AFP_Resourceという名前の拡張属性に保存されます。

ZFSならば、DosStream.AFP_AfpInfoとDosStream.AFP_Resourceは問題なく保存されます。しかしながら、ZFS以外の場合、DosStream.AFP_Resourceは巨大なので保存できません。少し昔のMac OS Xはフリーズしました。最近のOS Xはフリーズしませんが、リソースフォークが壊れます。sambaには代替データストリームを別ファイルに保存するvfsも用意されていますが、これを使うと、samba経由以外でファイルに手を加えた場合に滅茶苦茶になるのは容易に想像できます。

「一見、問題ない様に思えますが、SMBで接続している状態で”A.png”を調べてみると…。“A.png”のメタデータが見えなくなってしまいました。」と書かれていますが、これはnetatalk 3.1.2のバグです。Netatalkは、samba経由などで作成された「._」で始まるファイルを発見すると、自動的にnetatalk風の拡張属性に変換する機能があります。だから、netatalkで見える筈なんです。本来は

コレがその修正です。この大問題を解決するために3.1.3がリリースされました。https://github.com/Netatalk/Netatalk/commit/1fd316930fbb61d754cf7df36e584348bb95cfc3

先にOS XからSMBで代替データストリーム設定なしのSambaに転送すると、「._xxx」が出来ます。これをNetatalkが参照すると、メタデータをNetatalk式に変換します。3.1.2にはここにバグがあります。

先にNetatalkに転送して、それをSamba経由でみた場合は、単にメタデータが見えません。

あと、メタデータ問題の他に、Windowsファイル名禁止文字の問題があります。Netatalkは「:」と「/」の入れ換えしか行ないません。OS XがSMB通信する場合、Windows禁止文字が沢山あるのでこれらをUnicode私用領域に置き換えます。sambaはこの私有領域の文字をそのまま保存しますから、netatalkと互換性がありません。

ここまで述べた問題は、「メタデータの保存方法が違う」と「禁止文字の扱いが違う」の2つです。これをsamba側のvfsで解決するのが、最近フランク氏がsamba-technicalメーリングリストに投稿しているfruitです。このvfs_fruitを使うと、OS Xからnetatalk経由で保存したものと、samba経由で保存したものが同じになります。これが完成すれば、メタデータとファイル名の問題が解決するので、netatalkだろうがsambaだろうが、そんな細かいことは気にしないでよくなります。

メタデータとファイル名の問題が解決しても、まだ2つ問題があります。ファイルロック問題とSpotlight問題です。

最近のsamba-jp MLで話題になっている通り、Unix系のファイルロックは適当くさいです。これを解決する為に、sambaが用意しているsmbsharemodesライブラリをnetatalkが利用して、ロックをsambaに通知する必要があります。

更に、netatalkのSpotlight実装をsambaに移植する必要があります。netatalkのSpotlight機能はまだ出来が悪いので先の話だと思います。

これらが全て実装されれば、TimeMachine以外でnetatalkを使う必要がなくなります。さっさと捨てたいですね、こんなマイナーなソフト > Netatalk

以上です。

すごい、これだけで、一つの記事になってしまいます。本日、教えていただいた事も、追記してあります。

元記事の方に、前提条件を書いておくのを忘れました…。それと、netatalkのバージョンも…。それなのに、HATさんには、お見通し。エスパー?!

詳細な検証は、時間のある時にしたいと思います。少しずつ試しているのですが、終わらない…。

コメントを残す