環境は FreeBSD 6.0-RELEASE + netatalk 2.0.3 + 各種パッチ（netatalk2.0.3のcjk patch ports にさらに non-ascii-volume patch を当てたもの）。もちろん afpd のインスタンスは -setpassword になっている。クライアントは OS 9 でも OS X でも一緒。
変更できたようなフリはする。ログ1では
Nov 25 09:26:42 afpd[720][auth.c:905]: I:AFPDaemon: password change continued.
Nov 25 09:26:42 afpd[720][auth.c:896]: I:AFPDaemon: changing password for <USERNAME>
Nov 25 09:26:42 afpd[720][uams_dhx_pam.c:159]: I:UAMSDaemon: uams_dhx_pam.c :PAM
: PAM Success
Nov 25 09:26:42 afpd[720][auth.c:905]: I:AFPDaemon: password change succeeded.
って言ってるんだけど、実際には変更したつもりのパスワードで認証は通らない。つか /etc/pam.d/ に netatalk とか afpd とかないのに全然エラーが出ないけど、こういうもんなんだろうか。くそー PAM がよく分かってねぇ。
しかし手順は必ずしも分かりやすくないけど、パスワード変更の UI があったり、ゲストとしてのアクセスも明示できたり、afp の方が全体的にちゃんとしてる気がする。smb の方はどっちも明示できないから何が起きているのかイマイチ分かりにくい。認証を通過したら、そのユーザーにアクセス権限のある共有フォルダだけ見えるってのも afp の方が親切な感じ。
とりあえずパスワード変更については別なアプローチもある2ので、別な実験へと進むことにする。失敗記録を書いてツッコミ待ち戦法。
NFS でマウントしたディスクを共有フォルダとして Netatalk で扱う。ロック周りでエラーを吐きまくり、
- ドラッグしてファイルを放り込むのはエラーメッセージつきで可能
- 削除は不可能
という状態。（Samba の方も一部面白くない挙動をするが、削除できないとか致命的なものはない。）
こりゃ困ったな。nfs マウントして netatalk を走らせてる機械が設定しているつもりの permission は関係ない模様。やっぱ無理だったか？ netatalk 側で CNID scheme だのあれこれいじったりしてみたけど、どれも無関係っぽい。nfs のバージョンはひょっとして関係あるかーと思ったけど確認の方法が分からない。
[2005-11-26 追記] 解決
これとは別にもう一つ、アクセスできていたはずの共有フォルダをなぜかマウントできなくなるという現象が発生し、試しに新しくフォルダを掘って共有掛けたら確実に再現するという事態に陥っていたが、両方解決した。
- Berkeley DB を利用する .AppleDB/ は NFS 上に置かない
- .AppleVolumes.defalut でマウントポイントごとに dbpath: を使ってローカルのファイルシステムにデータベースを置くようにする
- Berkeley DB を NFS で使うなという話は リポジトリの作成と設定（Subversion のドキュメント）にとても分かりやすく書かれています
- nfs mount の際に lock しないオプションを利用する
- Linux なら nolock, FreeBSD なら -L を利用する。これでとりあえずファイルを操作する際のエラーは止まり、通常通りにファイルの生成、削除が行えた。
- これはこれで何か問題が起きそうな気はするが、負荷を上げた際にどうなるかは今後の課題ってことで。
- NFS サーバ側の動作によって違うかもしれない。まぁ何か不都合が起きたときにはここを疑う価値あり、程度に解釈すればよい。また、lock がないなんて気持ち悪すぎる、という向きにはファイル共有用の領域だけロックが外れるようなパーティションの切り方をすればまだマシかと。
基本的なことを自分が分かっていなかっただけとは言え、NFS の上で netatalk を動かそうなんて人はいないのか全然情報がなくて困った。