YaST を利用することで、お使いのコンピュータを NFS サーバに仕立て上げることができます。 NFS サーバでは、許可するコンピュータや特定のグループ内の全メンバーに対して、ファイルやディレクトリをエクスポートすることができます。そのため、 NFS を利用することで、それぞれのホストにインストールすることなく、特定のアプリケーションを利用できるようにすることもできます。

このようなサーバを構築するには、下記の手順で行います:

NFS のエクスポートサービスで使用される設定ファイルは、 /etc/exports と /etc/sysconfig/nfs の 2 種類です。これらのファイルに加えて、 Ketberos が有効化された NFSv4 サーバの設定や、クライアントが数字のユーザ名を扱うことができない場合は、 /etc/idmapd.conf も必要となります。

サービスを開始もしくは再起動するには、 systemctl restart nfs-server を実行します。これにより、 NFS サーバが必要とする RPC port mapper も再起動することができます。

NFS サーバをシステムの起動時に開始するようにするには。 sudo systemctl enable nfs-server を実行します。

注記: NFSv4

NFSv4 は openSUSE Leap で利用できる最新バージョンの NFS プロトコルです。現在の NFSv4 でディレクトリをエクスポートする際の設定は、 NFSv3 と同じです。

Leap 以前の openSUSE では /etc/exports 内での bind マウントが必須でした。現在もなお、この構成に対応してはいますが、廃止予定になっています。

NFS 向けに Kerberos 認証を使用するには、 Generic Security Services (GSS) を有効化しなければなりません。 YaST の NFS サーバダイアログの冒頭で、 GSS セキュリティを有効にする にチェックを入れてください。また、この機能を利用するには、動作する Kerberos サーバを用意しなければなりません。 YaST では Kerberos サーバの構築を行うことはできませんが、この機能を利用するように設定することは可能です。なお、 YaST の設定に加えて Kerberos 認証を使用するにあたっては、 NFS の設定を完了する前に下記の手順を完了する必要があります:

Kerberos 認証を使用するには、サーバ側で idmapd デーモンを動作させる必要もあります。詳しくは /etc/idmapd.conf をお読みください。

Kerberos が有効化された NFS について、さらに詳しくは 22.7項 「さらなる情報」 にあるリンク先をお読みください。

認可済みのユーザであれば、 YaST の NFS クライアントモジュールを利用することで、 NFS サーバ内でエクスポートされたディレクトリをマウントし、ローカルのファイルツリーに組み込むことができます。具体的には、下記の手順で実施します:

設定した内容は /etc/fstab 内に書き込まれ、マウント処理が行われます。後から YaST の設定を起動した場合は、このファイル内にある既存の設定が読み込まれます。

ヒント: ルートファイルシステムとしての NFS について

ディスクレス (自分自身にはディスクが接続されていない) システムでは一般に、 NFS の共有をネットワーク経由でマウントしてルートファイルシステムにすることがありますが、この場合は NFS 共有にアクセスするネットワークデバイスの設定に注意する必要があります。

システムをシャットダウンしたり再起動したりする場合、既定の処理順序では、ネットワークの接続を切ってからルートパーティションのマウントを解除します。ルートファイルシステムに NFS を使用している場合は、ルートファイルシステムのマウントを解除しようとしても、その時点では既にネットワークが切断されているため、正しく終了することができなくなってしまいます。この問題を解決するには、 13.4.1.2.5項 「ネットワークデバイスの有効化」 で説明している手順でネットワークデバイスの設定タブを開いて、 デバイスの有効化 の値を NFSroot に設定してください。

NFS サーバを動作させる場合、ファイルシステムを手動で取り込む際にあらかじめ設定しておくべきことは、 RPC portmapper の有効化です。 nfs サービスを開始すれば、 RPC portmapper についても適切に起動が行われますので、 root で systemctl start nfs を実行してください。あとは mount コマンドを利用して、ローカルのファイルシステムをマウントする場合と同様の手順を実施するだけです:

> sudo mount ホスト名:リモートのパス ローカルのパス

たとえば nfs.example.com というマシンのホームディレクトリをマウントしたい場合は、下記のように実行します:

> sudo mount nfs.example.com:/home /home

NFS クライアントがサーバに対して確立する TCP 接続数を設定するには、 mount コマンドの nconnect オプションを使用します。設定値は 1 から 16 までの範囲で、オプションを指定しない場合の既定値は 1 です。

なお、 nconnect の設定は、特定の NFS サーバに対する初めてのマウント処理にのみ適用されます。また、同じクライアント内で同一の NFS サーバに複数のマウントを行うと、既存の接続は共有され、新しい接続は行われません。そのため、 nconnect の設定を変更したい場合は、あらかじめ特定の NFS サーバに対するマウントを すべて 解除しておく必要があります。これで nconnect の新しい設定値を適用できるようになります。

現在使用中の nconnect の設定値を確認したい場合は、 mount コマンドの出力を参照するか、もしくは /proc/mounts ファイルをお読みください。マウントオプションに何も値が書かれていない場合は、マウント時にオプションを指定しておらず、既定値である 1 が使用されていることになります。

注記: nconnect で指定されているものとは異なる可能性がある件について

初回のマウント後にも接続を開いたり閉じたりすることができるため、実際の接続数は nconnect の設定値とは異なる場合があります。

/nfsmounts /etc/auto.nfs

localdata -fstype=nfs server1:/data
nfs4mount -fstype=nfs4 server2:/

22.4.2.2 /etc/fstab の手作業による編集 #Edit source

NFSv3 の場合、 /etc/fstab ファイル内では下記のように設定します:

nfs.example.com:/data /local/path nfs rw,noauto 0 0

NFSv4 でマウントする場合は、 3 列目の nfs を nfs4 として設定します:

nfs.example.com:/data /local/pathv4 nfs4 rw,noauto 0 0

noauto オプションを指定することで、システムの起動時には自動的にマウントされないようにしています。このように設定している状況で、手作業でファイルシステムをマウントするには、下記のようにマウントポイントを指定するだけでかまいません:

> sudo mount /local/path

注記: 起動時点でのマウントについて

noauto オプションを指定しない場合、システムの起動時に動作する初期化スクリプトが、自動的にマウント処理を行います。また、ネットワークが動作する前にマウント処理を実施しないようにするため、 _netdev オプションを設定してもかまいません。

NFS は 1980 年代に開発された、最も古いプロトコルのうちの 1 つです。そのため、 NFS は小さなファイルを共有するには十分なプロトコルですが、巨大なファイルや多数のクライアントを扱うような環境では、 NFS がボトルネックとなって、システムの性能に顕著な悪影響を及ぼしてしまいます。これは昔に比べてファイルが容易に巨大化しやすい環境になったためで、イーサネットの速度がそれに追随できていないことによるものです。

通常の NFS サーバに対してクライアントがファイルを要求すると、サーバはファイルのメタデータを読み込んだあと、全てのデータを収集してネットワーク経由でファイルを転送します。しかしながら、小さなファイルであっても大きなファイルであっても、性能のボトルネックが発生します:

pNFS (parallel NFS) では、このような制限を、ファイルシステムのメタデータとデータの位置をそれぞれ分離することで克服しています:

メタデータとストレージサーバは単一の論理 NFS サーバを構成します。クライアントがファイルに対して読み込みまたは書き込みの要求を行うと、メタデータサーバが NFSv4 クライアントに対して、ファイルチャンクにアクセスする際に使用するストレージサーバを指定します。クライアントはサーバ内のデータに直接アクセスすることができます。

openSUSE Leap では、 pNFS のクライアント側のみに対応しています。

> sudo mount -t nfs4 -o nfsvers=4.2 MDS_サーバ マウントポイント

> sudo echo 32767 > /proc/sys/sunrpc/nfsd_debug
> sudo echo 32767 > /proc/sys/sunrpc/nfs_debug

NFS 4 では、サーバ側で TCP ポート 2049 を開くだけでかまいません。ファイアウオールでポートを開くには、 NFS サーバ側の firewalld で、 nfs サービスを有効化します:

> sudo firewall-cmd --permanent --add-service=nfs --zone=ゾーン名
firewall-cmd --reload

ここで、 ゾーン名 には NFS サーバ側で使用しているゾーン名を指定します。

NFSv4 の場合、クライアント側でのファイアウオール設定は不要です。特に指定を行わない限り、クライアント側は利用可能な最新の NFS バージョンを利用してマウントを実施しますので、クライアント側が NFSv4 に対応していれば、共有は自動的にバージョン 4.2 でマウントすることになります。

NFS 3 では下記のようなサービスが必要となります:

これらのサービスは rpcbind で制御され、既定では動的にポートが割り当てられます。ファイアウオール内に位置する NFS サーバの場合、まずは使用するサービスに対して固定のポートを使用するように設定する必要があります。ポートを固定したのち、ファイアウオールでポートを開いてください。

重要: firewalld の設定再読み込みについて

firewalld の設定を変更したあとは、変更を反映させるために下記のコマンドを実行し、デーモンに再読み込みを行わせる必要があります:

> sudo firewall-cmd --reload

注記: ファイアウオールのゾーンについて

ゾーン名 の箇所には、マシン内で現在使用しているファイアウオールゾーンを指定してください。どのゾーンを使用しているのかはマシンごとに異なる可能性があることに注意してください。

NFS で発生する問題は、表示されるエラーメッセージのほか、 /var/log/messages に記録されるログメッセージを読むことで原因を探り当てることができる場合があります。ですが、表示されるメッセージや /var/log/messages 内のログメッセージだけでは不十分で、原因を探り当てられないことも多くあります。このような場合、問題を再現させてネットワークのパケットを採取することで、原因に辿り着きやすくすることができます。

まずは問題点を明確にしてください。様々な方法でシステムのテストを実施して問題を再現させ、どこで問題が発生しているのかを明確にしましょう。あとは問題を切り分けていって、最も簡単な再現手順を作り上げてから、下記に示す再現手順を実施してください。

重要: 高度なデバッグは熟練者向けの仕組みである件について

本章で説明している内容は、 NFS のコードへの理解がある高度な NFS 管理者向けの説明です。そのため、まずは 22.8.1項 「一般的なトラブルシューティング」 で示している説明に従って、問題点を絞り込むところから始めるようにしてください。その後、必要であれば、より詳しく状況を調べるために本章に示すデバッグ手順を実施してください。

NFS 関連の情報を収集するにあたっては、様々な分野のデバッグ用コードが存在しています。しかしながら、デバッグメッセージは非常に分かりにくいものであるほか、出力量も非常に大きいため、性能への影響もあり得ます。場合によっては、デバッグ機能によって問題の再現を妨害してしまうこともあります。ほとんどの場合においてデバッグ機能は不要であり、 NFS のコードを熟知した人間にのみ有用であることに注意してください。

rpcdebug -m モジュール名 -s flags

rpcdebug -m モジュール名 -c flags

man 8 rpcdebug

MOUNTD_OPTIONS=""

MOUNTD_OPTIONS="-d all"

man 8 rpc.mountd

systemctl restart nfs-server  # NFS サーバ関連の変更の場合
systemctl restart nfs  # NFS クライアント関連の変更の場合