2014年7月26日

NFSトラブル Fedora 13/14 nobody:nobody

Fedora 13(FC13)上のVMPlayerで走らせているFedora 14(FC14)がブートしなくなった。原因は不明。ブーとの最中にカーネルがパニックを起こす。

 幸いなことにすべてのバックアップが揃っているので、FC14のイメージをVMPayerで再インストールし、バックアップから必要なファイルを回復させる。わけの分からないVMPlayerのイメージファイルと格闘するよりずっと手っ取り早いという判断。もともとこのFC14はFC14をターゲットにしたプロジェクトのビルドだけを目的として、その他の汎用性はまったく求めていないのでカスタマイズした部分もわずかだ。

エディタやバックアップなどのファイル管理は、すべてセントラルサーバであるFC13に任せ、FC14はプロジェクトの開発ディレクトリのみをNFSマウントして、ビルド作業だけを実行する。以前は/home をまるごとマウントしていたが、ホームディレクトリのしたの種々の設定ファイルがぶつかるとあまりおもしろくないので、プロジェクトの開発ディレクトリだけをマウントすることにした。

ところが通常どおり/etc/fstab にNFSのマウントを記述するとマウントはするが、マウントポイント以下のファイルの所有者がすべて nobody:nobody になってしまう。 このマウントされるサーバのディレクトリは他のマシンにもマウントされているが、そちらは正常なファイルの所有者になっている。このままでは用をなさない。

条件をまとめてみる。
  • FC13がNFSサーバ
    /home/h/project をエfc14にクスポート(rw,wdelay,no_root_squash,no_subtree_check)
  • FC14がNFSクライアント
    mount -t nfs4 fc13:/home/h/projects /home/h/projects
  • FC13とFC14のユーザ「h」は同じID(501)
  • マウントは成功するが、FC14上でマウントしたディレクトリを見るとファイル所有者が nobody:nobody になっている
調査の結果、こちらからの情報が役に立った。

クライアント(FC14)の /etc/idmapd.conf を編集して


#Domain = localdomain.edu

の部分を

Domain = mydomain.edu

のように本物のドメイン(でなければならないのかどうかは不明)に書き換え、

# service rpcidmapd restart

を実行し、マウントをし直す。これでマウントされたディレクトリとその下のファイルが正しいファイル所有者になった。

今回はマウントするファイルの所有者がただ一人だったから、FC14側の ユーザIDをFC13側のIDと一致するように手で書き換えたが、複数のユーザIDが存在するならNISを使うのがよいと思う。

0 件のコメント:

コメントを投稿