NFS は最低二つの主要な部分、 サーバと一つ以上のクライアントからなります。 クライアントはサーバマシン上に格納されたデータにリモートからアクセスします。 これが適切に機能するには、 いくつかのプロセスが設定されて実行されていなければなりません。

サーバは以下のデーモンを動作させなければなりません。

クライアント側では nfsiod というデーモンも実行できます。 nfsiod デーモンは NFS サーバからのリクエストを処理します。 これは任意であり、性能を改善しますが、 通常の正しい動作には必要としません。詳細については nfsiod(8) マニュアルページを参照してください。

NFS の設定は比較的素直な工程です。 動かさなければならないプロセスは /etc/rc.conf ファイルを少し変更すれば起動時に実行させられます。

NFS サーバでは /etc/rc.conf ファイルの中で、 以下のオプションが設定されていることを確かめてください。

mountd は NFS サーバが有効になっていれば、 自動的に実行されます。

クライアント側では /etc/rc.conf 内に以下の設定があることを確認してください。

/etc/exports ファイルは NFS サーバがどのファイルシステムをエクスポート (ときどき 「共有」 と呼ばれます) するのかを指定します。 /etc/exports ファイル中の各行は、 エクスポートするファイルシステム、 およびそのファイルシステムにアクセスできるマシンを指定します。 ファイルシステムにアクセスできるマシンとともに、 アクセスオプションも指定できます。 このファイルで指定できるオプションはたくさんありますが、 ここではほんの少しだけ言及します。exports(5) マニュアルページを読めば、 他のオプションは簡単にみつけられるでしょう。

いくつか /etc/exports の設定例を示します。

以下の例はファイルシステムのエクスポートの考え方を示しますが、 あなたの環境とネットワーク設定に応じて設定は少し変わるでしょう。 たとえば次の行は /cdrom ディレクトリを、サーバと同じドメイン名か (そのため、いずれもドメイン名がありません)、 /etc/hosts に記述されている三つの例となるマシンに対してエクスポートします。 -ro フラグは共有されるファイルシステムを読み込み専用にします。 このフラグにより、 リモートシステムは共有されたファイルシステムに対して何の変更も行えなくなります。

以下の設定は IP アドレスで指定した 3 つのホストに対して /home をエクスポートします。 この設定はプライベートネットワークで DNS が設定されていない場合に便利でしょう。 内部のホスト名に対して /etc/hosts を設定するという手段もあります。 詳細については hosts(5) を参照してください。 -alldirs フラグはサブディレクトリがマウントポイントとなることを認めます。 言い替えると、これはサブディレクトリをマウントしませんが、 クライアントが要求するか、 または必要とするディレクトリだけをマウントできるようにします。

以下の設定は、サーバとは異なるドメイン名の 2 台のクライアントがアクセスできるように /a をエクスポートします。 -maproot=root フラグは、リモートシステムの root ユーザが、 エクスポートされたファイルシステムに root として書き込むことを許可します。 -maproot=root フラグが無ければ、 リモートマシンの root 権限を持っていても、 共有されたファイルシステム上のファイルを変更することはできないでしょう。

クライアントがエクスポートされたファイルシステムにアクセスするためには、 そうする権限が与えられていなければなりません。 /etc/exports ファイルに クライアントが含まれているかどうか確認してください。

/etc/exports ファイルでは、 それぞれの行が一つのファイルシステムを一つのホストにエクスポートすることを表します。 リモートホストはファイルシステム毎に一度だけ指定することができ、 それに加えて一つのデフォルトエントリを置けます。たとえば /usr が単一のファイルシステムであると仮定します。 次の /etc/exports は無効です。

単一のファイルシステムである /usr は、2 行に渡って、同じホスト client へエクスポートされています。 この場合、正しい書式は次のとおりです。

あるホストにエクスポートされるある 1 つのファイルシステムのプロパティは、 1 行ですべて指定しなければなりません。 クライアントの指定のない行は、単一のホストとして扱われます。 これはファイルシステムをエクスポートできる方法を制限しますが、 多くの場合これは問題になりません。

下記は、 /usr および /exports がローカルファイルシステムである場合の、 有効なエクスポートリストの例です。

変更が有効となるように、 /etc/exports が変更されたら mountd を再起動しなければなりません。 これは mountd プロセスに HUP シグナルを送ることで実行できます。

他には、再起動すれば、FreeBSD はすべてを適切に設定します。 しかしながら、再起動は必須ではありません。 root 権限で以下のコマンドを実行すれば、すべてが起動するでしょう。

NFS サーバでは

NFS クライアントでは

これでリモートのファイルシステムを実際にマウントする準備がすべてできました。 この例では、サーバの名前は server で、 クライアントの名前は client とします。 リモートファイルシステムを一時的にマウントするだけ、 もしくは設定をテストするだけなら、クライアント上で root 権限で以下のコマンドを実行するだけです。

これで、サーバの /home ディレクトリが、クライアントの /mnt にマウントされます。もしすべてが正しく設定されていれば、 クライアントの /mnt に入り、 サーバにあるファイルすべてを見れるはずです。

リモートファイルシステムを起動のたびに自動的にマウントしたいなら、 ファイルシステムを /etc/fstab ファイルに追加してください。 例としてはこのようになります。

fstab(5) マニュアルページに利用可能なオプションがすべて掲載されています。

NFS には実用的な使用法がいくつもあります。 ここで典型的な使用法をいくつか紹介しましょう。

amd(8) (自動マウントデーモン) は、 ファイルシステム内のファイルまたはディレクトリがアクセスされると、 自動的にリモートファイルシステムをマウントします。 また、一定の間アクセスされないファイルシステムは amd によって自動的にアンマウントされます。 amd を使用することは、通常 /etc/fstab 内に記述する恒久的なマウントに対する、 単純な代替案となります。

amd はそれ自身を NFS サーバとして /host および /net ディレクトリに結びつけることによって動作します。 このディレクトリ内のどこかでファイルがアクセスされると、 amd は対応するリモートマウントを調べて、 自動的にそれをマウントします。 /net が、エクスポートされたファイルシステムを IP アドレスで指定してマウントするのに利用される一方で、 /host は、エクスポートされたファイルシステムをリモートホスト名で指定してマウントするのに利用されます。

/host/foobar/usr 内のファイルにアクセスすると、 amd はホスト foobar からエクスポートされた /usr をマウントします。

例のように showmount はエクスポートとして /usr を表示します。 /host/foobar/usr にディレクトリを変更すると、 amd はホスト名 foobar を解決し、お望みのエクスポートをマウントしようと試みます。

amd は /etc/rc.conf 内に次の行を記述すれば、 起動スクリプトによって起動されます。

さらに amd_flags オプションによって amd にフラグをカスタマイズして渡せます。デフォルトでは amd_flags は次のように設定されています。

/etc/amd.map ファイルは、 エクスポートがマウントされるデフォルトオプションを決定します。 /etc/amd.conf ファイルは、 amd のより高度な機能の一部を設定します。

詳細については amd(8) および amd.conf(5) マニュアルページを参照してください。

訳: 渡辺 智雄 <tomo@jp.FreeBSD.org>. 6 September 1996.

ISA バス用のイーサネットアダプタの中には性能が悪いため、 ネットワーク、特に NFS で深刻な問題がおきるものがあります。 これは FreeBSD に限ったことではありませんが FreeBSD でも起こり得ます。

この問題は (FreeBSD を使用した) PC がシリコングラフィックス社やサン・マイクロシステムズ社などの高性能なワークステーションにネットワーク接続されている場合に頻繁に起こります。 NFS マウントはうまく動作するでしょう。 また、いくつかの操作もうまく動作するかもしれませんが、 他のシステムに対する要求や応答は続いていても、 突然サーバがクライアントの要求に対して応答しなくなります。これは、 クライアントが FreeBSD か上記のワークステーションであるときにクライアント側に起きる現象です。 多くのシステムでは、いったんこの問題が現われると、 行儀良くクライアントを終了する手段はありません。 NFS がこの状態に陥ってしまうと正常に戻すことはできないため、 多くの場合クライアントをリセットすることが唯一の解決法となります。

「正しい」 解決法は、より高性能のイーサネットアダプタを FreeBSD システムにインストールすることですが、 満足に動作させる簡単な方法があります。 FreeBSD システムが サーバ になるのなら、 クライアントからのマウント時に -w=1024 オプションをつけて下さい。FreeBSD システムが クライアント になるのなら、 NFS ファイルシステムを -r=1024 オプションつきでマウントして下さい。 これらのオプションは自動的にマウントをおこなう場合には クライアントの fstab エントリの 4 番目のフィールドに指定してもよいですし、 手動マウントの場合は mount コマンドの -o パラメータで指定してもよいでしょう。

NFS サーバとクライアントが別々のネットワーク上にあるような場合、 これと間違えやすい他の問題が起きることに注意して下さい。 そのような場合は、ルータが必要な UDP 情報をきちんとルーティングしているかを確かめて下さい。 していなければ、たとえあなたが何をしようと解決できないでしょう。

次の例では fastws は高性能ワークステーションのホスト (インタフェース) 名で、 freebox は低性能のイーサネットアダプタを備えた FreeBSD システムのホスト (インタフェース) 名です。 また /sharedfs はエクスポートされる NFS ファイルシステムであり (exports(5) を参照) 、 /project はエクスポートされたファイルシステムの、 クライアント上のマウントポイントとなります。 すべての場合において、アプリケーションによっては hard や soft, bg といった追加オプションがふさわしいかもしれないことに注意して下さい。

クライアント側 FreeBSD システム (freebox) の /etc/fstab の例は以下のとおりです。

freebox 上で手動で mount コマンドを実行する場合は次のようにして下さい。

サーバ側 FreeBSD システム (fastws) の /etc/fstab の例は以下のとおりです。

fastws 上で手動で mount コマンドで実行する場合は次のようにして下さい。

近いうちにどのような 16 ビットのイーサネットアダプタでも、上記の読み出し、 書き込みサイズの制限なしで操作できるようになるでしょう。

失敗が発生したとき何が起きているか関心のある人に、 なぜ回復不可能なのかも含めて説明します。NFS は通常 (より小さいサイズへ分割されるかもしれませんが) 8 K の 「ブロック」 サイズで動作します。 イーサネットのパケットサイズは最大 1500 バイト程度なので、 上位階層のコードにとっては 1 つのユニットであって、 NFS 「ブロック」 は複数のイーサネットパケットに分割されるものの、 上位階層のコードにとっては 1 つのユニットであって、 ユニットとして受信され、組み立て直され、 肯定応答 (ACK) されなければなりません。 高性能のワークステーションは次々に NFS ユニットを構成するパケットを、 標準の許す限り間隔を詰めて次々に送り出すことができます。 小さく、容量の低いカードでは、 同じユニットの前のパケットがホストに転送される前に、 後のパケットがそれを踏みつぶしてしまいます。 このため全体としてのユニットは、再構成も肯定応答もできません。 その結果、 ワークステーションはタイムアウトして再送を試みますが、 8 K のユニット全体を再送しようとするので、 このプロセスは際限無く繰り返されてしまいます。

ユニットサイズをイーサネットのパケットサイズの 制限以下に抑えることにより、 受信した完全なイーサネットパケットについて個々に肯定応答を返せることが保証されるので、 デッドロック状態を避けられるようになります。

それでも、高性能なワークステーションが力任せに次々と PC システムにデータを送ったときには踏みつぶしが起きるかもしれません。 しかし、高性能のカードを使っていれば、NFS 「ユニット」 で必ずそのような踏みつぶしが起きるとは限りません。 踏みつぶしが起きたら、影響を受けたユニットは再送されて、 受信され、組み立てられ、肯定応答される十分な見込みがあります。