Network File System ( NFS ) とは、サーバ内のファイルにアクセスするためのプロトコルで、これを利用することによってローカルのファイルと同じようなやり方でアクセスすることができるようになる仕組みです。
openSUSE Leap では、スパースファイルやファイルの事前割り当て、サーバ側での複製やコピー、アロケーションデータブロック (ADB) や強制アクセス制御 (MAC) のためのラベル型 NFS (この機能を使用する場合、クライアントとサーバの両方で MAC が必要となります) 等に対応した NFS v4.2 をインストールします。
Network File System (NFS) はコンピュータ間でのファイル共有を行うためのネットワークプロトコルで、標準化されているだけでなく、十分に実証された幅広いサポートが特長のプロトコルです。
ネットワーク内でのユーザ管理を共通化し、中央でとりまとめる目的で、 Network Information Service (NIS) を併用する場合があります。 NFS と NIS を併用することで、ネットワーク内でのファイルやディレクトリに対するアクセス制御を集中管理することができるようになります。また、ユーザにとっても NFS と NIS を利用することで、ネットワークの資源とローカルの資源を完全に透過的に扱うことができるようになります。
既定の設定では、 NFS はネットワーク側を完全に信用する設計になっていることから、 NFS サーバを有効化するにあたっては、信頼のできるネットワークに接続するようにしてください。具体的には、 NFS サーバが接続するネットワーク内の全てのコンピュータで管理者権限が適切に管理され、かつ物理的なアクセスに対しても保護があることをお確かめください。
また、 NFS サーバが接続するネットワークが完全にプライベートなものであり、単一のキャビネット内やマシンルーム内に存在していて、部外者による不正なアクセスができないよう、十分なセキュリティを確保してください。場合によっては、サブネット全体についても十分な制限が必要となるなど、きめ細かく信頼を構築する必要があることもあります。このような場合の要件に適合させるため、 NFS では Kerberos インフラストラクチャなどにも対応しています。 Kerberos を使用するには NFSv4 が必要となりますが、既定で有効化されています。詳しくは 第6章 「Kerberos を利用したネットワーク認証」 をお読みください。
YaST モジュールでは、下記の用語を使用します。
NFS サーバが 公開する ディレクトリを意味します。これにより、クライアントは自身のシステム内に、このディレクトリ以下の内容を取り込むことができるようになります。
NFS クライアントは、 NFS (Network File System) プロトコルを介して、 NFS サーバが提供する NFS サービスに接続するシステムを指します。 Linux カーネルには TCP/IP プロトコルが統合されているため、クライアント側で追加のソフトウエアをインストールする必要はありません。
NFS サーバは、クライアントに対して NFS サービスを提供するシステムを意味します。サーバ側では下記のデーモンを動作させてサービスを提供しています: nfsd
(ワーカー), idmapd
(NFSv4 向けの ID と名前のマッピングシステム、特定の用途でのみ必要となります), statd
(ファイルロック (施錠)), and mountd
(マウント要求)
NFSv3 はバージョン 3 の実装を意味します。状態遷移機能のない、クライアント認証に対応した 「古い」 実装です。
NFSv4 はバージョン 4 の新しい実装で、 Kerberos を介して機密を保持することのできるユーザ認証機能に対応しています。また、 NFSv4 ではポートを 1 つだけしか使用しない設計になっているため、 NFSv3 よりもファイアウオール環境には適した仕組みになっています。
プロトコルは https://datatracker.ietf.org/doc/rfc7531/ で規定されています。
Parallel NFS の略で、 NFSv4 のプロトコル拡張です。 pNFS に対応したクライアントであれば、 NFS サーバ内の任意のデータに直接アクセスすることができます。
原理上、全てのエクスポートは IP アドレスのみでアクセスすることができます。ただし、タイムアウトの問題を避けるために、 DNS システムをご用意ください。具体的には、 mountd
デーモンがログの記録時に逆引き参照を行いますので、そのために必要となります。
NFS サーバは、既定の設定ではインストールされません。 NFS サーバをインストールするには、 YaST を起動して
› を選択し、 内にある の を選択してください。あとは を押して必要なパッケージをインストールしてください。NIS と同様に、 NFS もクライアント/サーバ型のシステムになっています。ですが、 1 台のマシンでネットワークに対してファイルシステムを提供 (エクスポート) しながら、他のホストにあるファイルシステムをマウントする (インポート) することができます。
NFS サーバの設定は、 YaST もしくは手作業で実施することができます。認証については、 NFS と Kerberos を組み合わせることができます。
YaST を利用することで、お使いのコンピュータを NFS サーバに仕立て上げることができます。 NFS サーバでは、許可するコンピュータや特定のグループ内の全メンバーに対して、ファイルやディレクトリをエクスポートすることができます。そのため、 NFS を利用することで、それぞれのホストにインストールすることなく、特定のアプリケーションを利用できるようにすることもできます。
このようなサーバを構築するには、下記の手順で行います:
YaST を起動し、 図22.1「NFS サーバ設定ツール」 をご覧ください) 。なお、必要に応じて、追加のソフトウエアをインストールするよう求められることがあります。
› を選択します (まずは
のラジオボタンを押します。お使いのシステムで firewalld
が動作している場合は、 NFS 向けの設定を別途実施する必要があります (詳しくは 22.5項 「ファイアウオールを介した NFS サーバと NFS クライアントの通信」 をお読みください) 。現時点の YaST では firewalld
への対応が完全ではありませんので、 "ファイアウオールを設定できません" のメッセージを無視して続行してください。
また、必要であれば 注記: NFSv2 をお読みください。
をチェックしてください。 NFSv4 を無効化した場合、 YaST は NFSv3 のみに対応するようになります。なお、 NFSv2 の有効化については、NFSv4 を有効化した場合は、追加で NFSv4 ドメイン名を入力します。このパラメータは idmapd
デーモンが使用するパラメータで、 Kerberos の設定時やクライアントが数字のユーザ名では処理できないような場合に利用します。 idmapd
を動作させない場合や、特に要件がない場合は、 localdomain
(既定値) のままでかまいません。 idmapd
について、詳しくは /etc/idmapd.conf
をお読みください。
ドメイン名は全ての NFSv4 クライアント側でも設定する必要があります。同じドメイン名を設定したクライアントでないと、アクセスが拒否されてしまうためです。なお、既定のドメイン名は、サーバ/クライアントとも localdomain
になっています。
サーバに対してのアクセスをさらに保護したい場合は、
を選択します。この仕組みを使用するには、お使いのドメイン内に Kerberos がインストールされ、サーバとクライアントの両方で Kerberos が設定されている必要があります。 設定が終わったら を押すことで、次の設定ダイアログに進むことができます。お使いのディレクトリをエクスポートするには、ダイアログの上半分で
を押します。許可するホストの設定を行っていない場合は、クライアントの情報を入力するためのポップアップが自動的に表示されます。ホストをワイルドカードで設定することができます (通常は既定の設定のままでかまいません) 。
ホストのワイルドカードでは、下記の 4 種類の設定を行うことができます。 1 種類目は単一のホスト名を指すためのホスト名や IP アドレスの設定、 2 種類目はネットグループによる設定、 3 種類目はワイルドカード (たとえば *
を指定すると、全てのマシンからアクセスできるようになります) 、そして 4 種類目は IP ネットワークです。
これらのオプションについて、詳しくは exports
のマニュアルページをお読みください。
最後に
を押すと、設定を完了することができます。NFS のエクスポートサービスで使用される設定ファイルは、 /etc/exports
と /etc/sysconfig/nfs
の 2 種類です。これらのファイルに加えて、 Kerberos が有効化された NFSv4 サーバの設定や、クライアントが数字のユーザ名を扱うことができない場合は、 /etc/idmapd.conf
も必要となります。
サービスを開始もしくは再起動するには、 systemctl restart nfs-server
を実行します。これにより、 NFS サーバが必要とする RPC port mapper も再起動することができます。
NFS サーバをシステムの起動時に開始するようにするには。 sudo systemctl enable nfs-server
を実行します。
NFSv4 は openSUSE Leap で利用できる最新バージョンの NFS プロトコルです。現在の NFSv4 でディレクトリをエクスポートする際の設定は、 NFSv3 と同じです。
Leap 以前の openSUSE では /etc/exports
内での bind マウントが必須でした。現在もなお、この構成に対応してはいますが、廃止予定になっています。
/etc/exports
/etc/exports
ファイルには、エクスポートするディレクトリの設定一覧が含まれています。各行には共有するディレクトリのほか、共有方法の指定も含まれています。 /etc/exports
では、下記のような書式で各行を設定します:
/共有/ディレクトリ ホスト(オプションリスト)
たとえば、下記のようになります:
/nfs_exports/public *(rw,sync,root_squash,wdelay) /nfs_exports/department1 *.department1.example.com(rw,sync,root_squash,wdelay) /nfs_exports/team1 192.168.1.0/24(rw,sync,root_squash,wdelay) /nfs_exports/tux 192.168.1.2(rw,sync,root_squash)
上記の例では、 ホスト の欄にそれぞれ下記を指定しています:
*
: ネットワーク内の全てのクライアントに対して共有するよう指定しています
*.department1.example.com
: *.department1.example.com のドメインに属するクライアントにのみ共有するよう指定しています
192.168.1.0/24
: 192.168.1.0/24 の IP アドレス範囲内にのみ共有するよう指定しています
192.168.1.2
: 192.168.1.2 の IP アドレスを持つマシンにのみ共有するよう指定しています
上記の例に加えて、 /etc/netgroup
ファイルで定義できるネットグループを利用した制限を設定 ( @my-hosts
) することもできます。指定可能な全てのオプションとその意味について、詳しくは /etc/exports
のマニュアルページ ( man exports
) をお読みください。
なお、 NFS サーバが動作している間に /etc/exports
ファイルを変更した場合は、 sudo systemctl restart nfs-server
を実行して、変更内容を反映させるために再起動を行う必要があります。
/etc/sysconfig/nfs
/etc/sysconfig/nfs
ファイルには、 NFSv4 サーバデーモンの動作に関わるいくつかのパラメータが含まれています。特に NFS4_SUPPORT
を yes
(既定値) に設定しておくことが重要です。 NFS4_SUPPORT
は NFS サーバが NFSv4 のエクスポートとクライアントに対応するかどうかを決定するパラメータです。
なお、 NFS サーバが動作している間に /etc/sysconfig/nfs
ファイルを変更した場合は、 sudo systemctl restart nfs-server
を実行して、変更内容を反映させるために再起動を行う必要があります。
Leap 以前の openSUSE では、 /etc/exports
内で --bind
マウントのオプションが必須でした。現在もなお、この構成に対応してはいますが、廃止予定になっています。また、現在の NFSv4 でディレクトリをエクスポートする際の設定は、 NFSv3 と同じです。
NFS クライアント側で NFSv2 を必要としている場合は、サーバ側でも /etc/sysconfig/nfs
に下記の設定を行う必要があります:
NFSD_OPTIONS="-V2" MOUNTD_OPTIONS="-V2"
サービスを再起動したら、下記のコマンドを実行すると、バージョン 2 に対応しているかどうかがわかります:
>
cat /proc/fs/nfsd/versions
+2 +3 +4 +4.1 +4.2
/etc/idmapd.conf
idmapd
デーモンは、 Kerberos 認証を使用している場合や、クライアント側で数字のユーザ名を扱うことができない場合にのみ必要となるデーモンです。 Linux カーネル 2.6.39 以降では、 Linux クライアントは数字のユーザ名にも対応しています。 idmapd
デーモンは、 NFSv4 のサーバ宛のリクエストやクライアント宛の応答に対して、名前と ID とのマッピングを行います。
必要であれば、 idmapd
を NFSv4 サーバ内で動作させる必要があります。クライアント側での名前と ID のマッピングは、 nfs-client パッケージで提供されている nfsidmap
が行います。
なお、ユーザ名と ID (uid) が、 NFS でファイルを共有する可能性のある全てのマシン間で正しく統一されていることをご確認ください。これは NIS や LDAP など、任意のドメイン認証の仕組みで実施することができます。
また、 /etc/idmapd.conf
内の Domain
パラメータは設定必須となります。この値は NFSv4 のクライアントとサーバの両方で同じ値になっていなければなりません。よく分からない場合は、サーバとクライアントの両方で、既定値である localdomain
をお使いください。それ以外の値を設定する場合、通常はホストの FQDN 名からホスト名を抜いたものを指定します。設定ファイルの例は下記のようになります:
[General] Verbosity = 0 Pipefs-Directory = /var/lib/nfs/rpc_pipefs Domain = localdomain [Mapping] Nobody-User = nobody Nobody-Group = nobody
idmapd
デーモンを開始するには、 systemctl start nfs-idmapd
を実行します。デーモンが動作している間に /etc/idmapd.conf
ファイルを変更した場合は、 systemctl restart nfs-idmapd
を実行して設定を適用してください。
詳しくは idmapd
と idmapd.conf
のマニュアルページをお読みください ( man idmapd
および man idmapd.conf
で読むことができます) 。
NFS 向けに Kerberos 認証を使用するには、 Generic Security Services (GSS) を有効化しなければなりません。 YaST の NFS サーバダイアログの冒頭で、
にチェックを入れてください。また、この機能を利用するには、動作する Kerberos サーバを用意しなければなりません。 YaST では Kerberos サーバの構築を行うことはできませんが、この機能を利用するように設定することは可能です。なお、 YaST の設定に加えて Kerberos 認証を使用するにあたっては、 NFS の設定を完了する前に下記の手順を完了する必要があります:サーバとクライアントの両方が、同じ Kerberos ドメインに属するようにしてください。同じ KDC (鍵配布センター) サーバにアクセスしなければならないほか、 krb5.keytab
ファイルを共有しなければなりません (既定では /etc/krb5.keytab
内に配置されます) 。 Kerberos について、詳しくは 第6章 「Kerberos を利用したネットワーク認証」 をお読みください。
クライアント側で systemctl start rpc-gssd.service
を実行して、 gssd サービスを開始します。
サーバ側で systemctl start rpc-svcgssd.service
を実行して、 svcgssd サービスを開始します。
Kerberos 認証を使用するには、サーバ側で idmapd
デーモンを動作させる必要もあります。詳しくは /etc/idmapd.conf
をお読みください。
Kerberos が有効化された NFS について、さらに詳しくは 22.7項 「さらなる情報」 にあるリンク先をお読みください。
お使いのホストを NFS クライアントとして設定する場合は、追加のソフトウエアをインストールする必要はありません。必要な全てのパッケージが既定でインストールされるためです。
認可済みのユーザであれば、 YaST の NFS クライアントモジュールを利用することで、 NFS サーバ内でエクスポートされたディレクトリをマウントし、ローカルのファイルツリーに組み込むことができます。具体的には、下記の手順で実施します:
まずは YaST の NFS クライアントモジュールを起動します。
タブ内にある を押します。 NFS サーバのホスト名と取り込むディレクトリ、そしてローカル側のマウント先ディレクトリをそれぞれ指定します。
NFSv4 を使用している場合は、 localdomain
です。
NFS 向けに Kerberos 認証を使用するには、 GSS セキュリティを有効化しなければなりません。この場合は、
を選択します。お使いのシステムで firewalld
が動作している場合は、 NFS 向けの設定を別途実施する必要があります (詳しくは 22.5項 「ファイアウオールを介した NFS サーバと NFS クライアントの通信」 をお読みください) 。現時点の YaST では firewalld
への対応が完全ではありませんので、 「ファイアウオールを設定できません」 のメッセージを無視して続行してください。
最後に
を押すと、設定を保存することができます。設定した内容は /etc/fstab
内に書き込まれ、マウント処理が行われます。後から YaST の設定を起動した場合は、このファイル内にある既存の設定が読み込まれます。
ディスクレス (自分自身にはディスクが接続されていない) システムでは一般に、 NFS の共有をネットワーク経由でマウントしてルートファイルシステムにすることがありますが、この場合は NFS 共有にアクセスするネットワークデバイスの設定に注意する必要があります。
システムをシャットダウンしたり再起動したりする場合、既定の処理順序では、ネットワークの接続を切ってからルートパーティションのマウントを解除します。ルートファイルシステムに NFS を使用している場合は、ルートファイルシステムのマウントを解除しようとしても、その時点では既にネットワークが切断されているため、正しく終了することができなくなってしまいます。この問題を解決するには、 13.4.1.2.5項 「ネットワークデバイスの有効化」 で説明している手順でネットワークデバイスの設定タブを開いて、 の値を に設定してください。
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
の設定値とは異なる場合があります。
aufofs デーモンは、リモートのファイルシステムを自動的にマウントする際に使用するデーモンです。下記の内容を /etc/auto.master
ファイル内に追加してください:
/nfsmounts /etc/auto.nfs
上記のように設定すると、 /nfsmounts
ディレクトリが NFS マウントのルートディレクトリとして設定され、 auto.nfs
の内容に応じて自動的にマウントされるようになります。 auto.nfs
はそのファイル名でなければならないわけではありません。要件に応じて自由に変更してかまいません。また、 auto.nfs
には、下記のようにして全ての NFS マウントの項目を記述することができます:
localdata -fstype=nfs server1:/data nfs4mount -fstype=nfs4 server2:/
root
で systemctl start autofs
と実行すると、設定を反映させることができます。この例では、 /nfsmounts/localdata
ディレクトリが server1
の /data
ディレクトリを、 /nfsmounts/nfs4mount
が server2
のルートディレクトリをそれぞれマウントするように設定しています。
autofs の動作中に /etc/auto.master
を変更した場合は、変更内容を反映させるために automounter の再起動を行わなければなりません。 systemctl restart autofs
を実行して再起動してください。
/etc/fstab
の手作業による編集 #Edit sourceNFSv3 の場合、 /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) では、このような制限を、ファイルシステムのメタデータとデータの位置をそれぞれ分離することで克服しています:
非データトラフィックを処理する メタデータ もしくは コントロールサーバ
データを保持する 1 つもしくは複数の ストレージサーバ
メタデータとストレージサーバは単一の論理 NFS サーバを構成します。クライアントがファイルに対して読み込みまたは書き込みの要求を行うと、メタデータサーバが NFSv4 クライアントに対して、ファイルチャンクにアクセスする際に使用するストレージサーバを指定します。クライアントはサーバ内のデータに直接アクセスすることができます。
openSUSE Leap では、 pNFS のクライアント側のみに対応しています。
基本的には 手順22.2「NFS ディレクトリのインポート」 に示されている手順に従って作業を行いますが、 のチェックボックスにチェックを入れることと、必要であれば を選択する点が異なります。 YaST でこれを行った場合、必要な手順全てを実施し、必要なオプション類を /etc/exports
に書き込みます。
起動については 22.4.2項 「手作業によるファイルシステムの取り込み」 をお読みください。ほとんどの設定は NFSv4 サーバ側で行います。 pNFS の場合、 mount
に指定する nfsvers
オプションと、メタデータサーバを指定する MDS_サーバ が異なります。
>
sudo
mount -t nfs4 -o nfsvers=4.2 MDS_サーバ マウントポイント
デバッグ機能を有効にするには、下記の /proc
ファイルシステム内の値を変更してください:
>
sudo
echo 32767 > /proc/sys/sunrpc/nfsd_debug>
sudo
echo 32767 > /proc/sys/sunrpc/nfs_debug
NFS サーバと NFS クライアントとの通信は、 Remote Procedure Calls (RPC) と言う仕組みを利用します。マウントデーモンやファイル施錠 (ロック) サービスなどの RPC サービスは、いずれも Linux の NFS 実装の一部として提供されているものです。サーバとクライアントの間にファイアウオールが存在する場合、これらのサービスとファイアウオールは、通信を妨害されることの無いように設定しておく必要があります。
NFS 4 サーバは NFS バージョン 3 との後方互換性がありますが、バージョンによってファイアウオールの設定内容が異なります。また、 NFS 3 で共有をマウントするクライアントが存在する場合、ファイアウオールでは NFS 4 と NFS 3 の両方の設定を実施する必要があります。
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 では下記のようなサービスが必要となります:
portmapper
nfsd
mountd
lockd
statd
これらのサービスは rpcbind
で制御され、既定では動的にポートが割り当てられます。ファイアウオール内に位置する NFS サーバの場合、まずは使用するサービスに対して固定のポートを使用するように設定する必要があります。ポートを固定したのち、ファイアウオールでポートを開いてください。
portmapper
openSUSE Leap の場合、 portmapper
は既定で固定のポートを使用するように設定されています。
ポート | 111 |
プロトコル | TCP, UDP |
動作 | クライアント, サーバ |
|
nfsd
openSUSE Leap の場合、 nfsd
は既定で固定のポートを使用するように設定されています。
ポート | 2049 |
プロトコル | TCP, UDP |
動作 | サーバ |
|
mountd
openSUSE Leap の場合、 mountd
は既定で固定のポートを使用するように設定されています。
ポート | 20048 |
プロトコル | TCP, UDP |
動作 | サーバ |
|
lockd
lockd
に対して固定のポートを使用するように設定するには、下記のようにします:
サーバ側の /etc/sysconfig/nfs
ファイルの下記の箇所を編集します:
LOCKD_TCPPORT=NNNNN LOCKD_UDPPORT=NNNN
なお、 NNNNN の箇所には未使用のポート番号を指定します。なお、両方のプロトコルで同じポートを使用するようにしてください。
あとは NFS サーバを再起動します:
>
sudo
systemctl restart nfs-server
ポート | NNNNN |
プロトコル | TCP, UDP |
動作 | クライアント, サーバ |
|
statd
statd
に対して固定のポートを使用するように設定するには、下記のようにします:
サーバ側の /etc/sysconfig/nfs
ファイルの下記の箇所を編集します:
STATD_PORT=NNNNN
なお、 NNNNN の箇所には未使用のポート番号を指定します。
あとは NFS サーバを再起動します:
>
sudo
systemctl restart nfs-server
ポート | NNNNN |
プロトコル | TCP, UDP |
動作 | クライアント, サーバ |
|
firewalld
の設定再読み込みについてfirewalld
の設定を変更したあとは、変更を反映させるために下記のコマンドを実行し、デーモンに再読み込みを行わせる必要があります:
>
sudo
firewall-cmd --reload
ゾーン名 の箇所には、マシン内で現在使用しているファイアウオールゾーンを指定してください。どのゾーンを使用しているのかはマシンごとに異なる可能性があることに注意してください。
Linux では、ユーザやグループ、その他 ( ugo
) に対して、それぞれ読み込みと書き込み、実行 ( rwx
) のフラグを設定するパーミッション機能が標準化されているものの、それより細かい制御を行うアクセス制御リスト (ACL) については、統一された標準が存在していないのが現状です。その標準の候補として存在するのが ドラフト POSIX ACL と NFSv4 ACL です。 NFSv4 ACL は NFSv4 ネットワークファイルシステムの一部として存在するもので、 Linux (POSIX) システムと Microsoft Windows (WIN32) システムとの妥当な互換性を提供しようとするものです。
NFSv4 ACL はドラフト POSIX ACL を正確に実装するには不十分な存在であるため、 NFSv4 クライアントからのアクセスで ACL にマップするような機能は提供されていません (たとえば setfacl
など) 。
NFSv4 を使用する場合、ドラフト POSIX ACL は擬似的にであっても使用することはできず、 NFSv4 ACL を直接使用する必要があります。つまり、 setfacl
は NFSv3 に対しては動作するものの、 NFSv4 に対しては動作しないことになります。 NFSv4 ファイルシステムで NFSv4 ACL を使用するには、 openSUSE Leap では nfs4-acl-tools
というパッケージをインストールする必要があります。このパッケージには、下記のようなものが含まれています:
nfs4-getfacl
nfs4-setfacl
nfs4-editacl
これらのコマンドは getfacl
や setfacl
に似た動作をするもので、いずれも NFSv4 ACL を調査したり修正したりする際に使用することができます。なお、これらのコマンドは NFSv4 ACL を完全サポートした NFS サーバのファイルシステムに対してのみ動作します。サーバ側で何らかの制限がある場合、これらのプログラムでアクセス制御項目 (ACE) を操作できない場合があります。
また、 NFS の共有を公開しているサーバで直接 NFS ボリュームをマウントすることもできません。
詳しくは https://wiki.linux-nfs.org/wiki/index.php/ACLs#Introduction_to_NFSv4_ACLs (英語) にある Introduction to NFSv4 ACLs (NFSv4 ACL の紹介) をお読みください。
exports
, nfs
, mount
の各マニュアルページに加え、 NFS サーバと NFS クライアントを設定するための情報が /usr/share/doc/packages/nfsidmap/README
に用意されています。また、下記の Web サイトには、さらなるオンライン文書が用意されています:
ネットワークセキュリティに関する一般的な情報については、 第23章 「マスカレードとファイアウオール」 をお読みください。
NFS 共有を自動的にマウントする必要がある場合は、 23.4項 「NFS 共有の自動マウント」 をお読みください。
AutoYaST を利用して NFS を設定する方法については、 4.20項 「NFS クライアントおよびサーバ」 をお読みください。
Kerberos で NFS 共有の機密性を向上したい場合は、 6.6項 「Kerberos と NFS」 をお読みください。
詳細な技術文書をお読みになりたい場合は、 SourceForge (英語) をお読みください。
NFS で発生する問題は、表示されるエラーメッセージのほか、 /var/log/messages
に記録されるログメッセージを読むことで原因を探り当てることができる場合があります。ですが、表示されるメッセージや /var/log/messages
内のログメッセージだけでは不十分で、原因を探り当てられないことも多くあります。このような場合、問題を再現させてネットワークのパケットを採取することで、原因に辿り着きやすくすることができます。
まずは問題点を明確にしてください。様々な方法でシステムのテストを実施して問題を再現させ、どこで問題が発生しているのかを明確にしましょう。あとは問題を切り分けていって、最も簡単な再現手順を作り上げてから、下記に示す再現手順を実施してください。
まずはネットワークパケットの採取を行います。 Linux では tcpdump
コマンド (パッケージ名 tcpdump
) を使用することができます。
tcpdump
コマンドは、たとえば下記のように入力して実行します:
tcpdump -s0 -i eth0 -w /tmp/nfs-demo.cap host x.x.x.x
それぞれのオプションの意味は下記のとおりです:
ネットワークパケットの採取時、長いパケットを省略せずに採取するようにしています。
こちらは実際のローカルインターフェイス名に置き換えてください。ここに any
を指定すると、全てのインターフェイスで送受信されるパケットを採取できますが、不要なデータが多数含まれることになり、分析の際の邪魔になってしまうため、あまりお勧めしません。
採取したパケットの保存先ファイル名を指定します。
NFS 接続の対向側 IP アドレスを指定します。たとえば NFS のクライアント側で tcpdump
を実行してパケットを採取する場合、ここに指定するのは NFS サーバとなります。
場合によっては、 NFS クライアントもしくは NFS サーバのいずれかでパケットを採取すれば原因が判明することもありますが、ネットワークの通信状況が原因のうちの 1 つと疑われる場合は、クライアントとサーバの両方で採取することをお勧めします。
起動した tcpdump
コマンドは動作させたままの状態で、次の手順に進んでください。
(必要であれば) 直面している問題が nfs mount
の実行時に発生しているものである場合は、 nfs mount
コマンドに対して冗長出力を指定するオプション ( -vvv
) を追加して試してみてもかまいません。
(必要であれば) 問題の再現時に strace
を取得する方法もあります。再現時に strace
を実行すると、どこでどのシステムコールを使用したのかを正確に記録することができます。この情報は tcpdump
内のイベント情報とともに使用します。
たとえば NFS マウント内で mycommand --param を実行すると問題が発生する場合、 strace
は下記のように入力して実行します:
strace -ttf -s128 -o/tmp/nfs-strace.out mycommand --param
再現時に strace
を採取しない場合は、問題を再現させた時刻を覚えておいて、 /var/log/messages
内のログのうち、その時刻の前後に存在するログを確認してもかまいません。
問題を再現させることができたら、 tcpdump
を動作させている端末内で CTRL–c を押して、 tcpdump
を停止してください。なお、 strace
は通常、コマンドの終了後に自動的に終了しますが、停止しない場合は同様の手順で停止してください。
採取したパケットや strace
のデータは、知識と経験のある管理者であれば分析することができます。上記の手順を実施した場合、それぞれ /tmp/nfs-demo.cap
と /tmp/nfs-strace.out
というファイルに保存されています。
本章で説明している内容は、 NFS のコードへの理解がある高度な NFS 管理者向けの説明です。そのため、まずは 22.8.1項 「一般的なトラブルシューティング」 で示している説明に従って、問題点を絞り込むところから始めるようにしてください。その後、必要であれば、より詳しく状況を調べるために本章に示すデバッグ手順を実施してください。
NFS 関連の情報を収集するにあたっては、様々な分野のデバッグ用コードが存在しています。しかしながら、デバッグメッセージは非常に分かりにくいものであるほか、出力量も非常に大きいため、性能への影響もあり得ます。場合によっては、デバッグ機能によって問題の再現を妨害してしまうこともあります。ほとんどの場合においてデバッグ機能は不要であり、 NFS のコードを熟知した人間にのみ有用であることに注意してください。
rpcdebug
によるデバッグの有効化 #Edit sourcerpcdebug
は NFS クライアントと NFS サーバの両方でそれぞれデバッグフラグを設定することができます。ご利用の openSUSE Leap で rpcdebug
が利用できない場合は、 NFS クライアントであれば nfs-client
パッケージを、 NFS サーバであれば nfs-kernel-server
パッケージをそれぞれインストールしてください。
デバッグフラグを設定するには、下記のように入力して実行します:
rpcdebug -m モジュール名 -s flags
デバッグフラグの設定を解除するには、下記のように入力して実行します:
rpcdebug -m モジュール名 -c flags
ここで、 モジュール名 には下記のいずれかを指定します:
NFS サーバコードのデバッグ向け
NFS クライアントコードのデバッグ向け
NFS ロック (施錠) マネージャのデバッグ向け。 NFS クライアントと NFS サーバのいずれかで指定します。また、 NFS v2/v3 でのみ使用されます。
Remote Procedure Call (リモートプロシージャコール) のデバッグ向け。 NFS クライアントと NFS サーバのいずれかで指定します。
rpcdebug
コマンドの詳しい使い方については、下記のマニュアルページをお読みください:
man 8 rpcdebug
NFS の動作は他の関連サービスに依存して変化します。これにはたとえば NFS マウントデーモン (rpc.mountd
) などがあります。関連サービスに対して設定するオプションは、 /etc/sysconfig/nfs
で指定します。
たとえば /etc/sysconfig/nfs
には下記のようなパラメータがあります:
MOUNTD_OPTIONS=""
デバッグモードを有効化するには、 -d
オプションに続いて下記のいずれかの値を指定します: all
, auth
, call
, general
, parse
たとえば rpc.mountd
の全てのデバッグ機能を有効化するには、下記のように指定します:
MOUNTD_OPTIONS="-d all"
指定可能なオプションについて知りたい場合は、下記のマニュアルページをお読みください:
man 8 rpc.mountd
また、 /etc/sysconfig/nfs
を変更した場合は、サービスを再起動する必要があります:
systemctl restart nfs-server # NFS サーバ関連の変更の場合 systemctl restart nfs # NFS クライアント関連の変更の場合