OpenSolaris 2009.06(snv111b)での話。

非グローバルゾーンでsamba(SUNWsmba)を動かそうと思っても、そのままでは下記のようなエラーが/var/samba/log/log.smbdに残ってしまって動かない。smb.confがないのと違ってsvcs的にはonlineになるが、netstat -aで見るとlistenしていないのがわかる。

[2010/06/27 05:44:16, 0] lib/util_sock.c:(822)
  bind failed on port 445 socket_addr = 0.0.0.0.
  Error = Permission denied

さらに、nmbd(svcsの名前だとwins)のほうはsvcsで見るとmaintenance状態になっていることがわかる。

これは、非グローバルゾーンでの特権が足りないせいなので、zonecfgを使ってlimitprivを追加してやる。うちでは内部的に使っているサーバなので大変緩く、下記のようにした。(長いけど続けて)

set limitprev = default,file_downgrade_sl,file_upgrade_sl,
sys_trans_label,win_colormap,win_config,
win_dac_read,win_dac_write,win_devices,
win_fontpath,win_mac_read,win_mac_write,
win_selection,sys_smb

これでzoneを再起動してやるとsambaがlistenするようになる。セキュリティ的になんでもかんでもつけるのが嫌であれば、ここのglobal: limitprivのところを読んで適宜付け替えるとよい。

余談。opensolarisのブートディスクが壊れたのでこういうことをやっているのだが、zfsは新しくインストールし直した環境からzpool importするだけで構成情報まで含めて一発でとってきてくれるのがなんともうれしい。そういう都合から、sambaまで含めて全部zfs上のzoneに乗せてしまいたいのでこういうことをした次第。グローバルゾーンはハイパーバイザー代わりで十分。:-)

ちょっと特殊な環境でしか起こりえないと思う問題なのだが、fixに思いの外手間がかかったのでメモ。

symfonyの開発中で、クライアントがWindowsXP(SP3)、サーバはクライアントのWindowsにインストールしたVMWareの中でFedora9を動かしている環境。Fedora9は現在最新版のsamba()をインストールしていて、WindowsからUNCパス(\\servername\hogeという指定)でプロジェクトごとe-texteditorで開いて作業している。subversionはサーバ側が1.4系列、クライアント側はTortoiseSVNの1.5系列、https/WebDAVを使っていて、サーバは手元とは別の場所にある。

このような環境下で、場合により「コミットには成功しましたが続けて他のエラーが生じました」「次のパスを処理する際にクリーンアップに失敗しました」というようなエラーがでる。だが、このエラーメッセージをgoogleで調べても、TortoiseSVNの言語ファイルのソースばかり出てきてエラーにはたどり着くことが出来ない。

そこで、その言語ファイルの訳語元「Commit succeeded, but other errors follow」や、「」を調べていて、やっとこさそれっぽい記事にたどり着いた。このMLのスレッドでは、解決策として「samba使うのを止めるか」または「最新のsambaに入れ直せ」、ということになっている。調べてみると、その記事の書かれたとき(2008/09/15)のsambaの最新版は3.2.3。その３日後に3.2.4が出ている。手元の環境は3.2.3-0.20.fc9。このドキュメントを信用する限り問題はないはず。

だが、その環境で問題が起こっているので、念には念をということで3.2.4をfedora-updates-testing-newkeyリポジトリから拾ってみた。インストールされたバージョンは3.2.4-0.21.fc9。だが、やはり問題は再現したのであった。

その後、Eclipse+PDT+Subclipse1.4.xの環境でも同じ問題が発生したこともあり、どうもTortoiseSVNが原因ではない模様。ついったでしばらく文句垂れていたのは冤罪だったようだ。ほんとごめん>TSVN

このまま調べるのをやめてしまうと、また問題が起きるたびにフォローアップ作業をしなければならない。それは悔しいのでもう少し調べてみると、こんな記事を見つけた。曰く、共有フォルダごとの設定に、create maskやらの設定を追加するとちゃんと動くようになるよ!　とのこと。うちではこんな風に書き換えてみた。下線部分が追記分。

[homes]
        comment = Home Directories
        browseable = no
        writable = yes
        create mask = 0644
        force create mode = 0600
        security mask = 0555
        force security mode = 0600

試してみると、これがなんとエラーが発生しなくなるではないか・・。

原因が良く説明できないが、症状がなくなったことは大変めでたい。もし正確な原因がわかる方がいればコメントいただければ幸い。