test

NFS の管理

第 2 章 NFS サーバの設定

この章では、NFS 管理タスクの実行方法について説明します。具体的には、NFS サービスの設定、共有する新規ファイルシステムの追加、ファイルシステムのマウント、Secure NFS システムの使用、WebNFS 機能の使用などです。章の最後では障害追跡の手順を説明し、NFS の多くのエラーメッセージとその意味を示します。

NFS 管理者の責任は、サイトの要求やネットワーク上に存在するコンピュータの役割によって変わります。管理者がローカルネットワークのコンピュータすべてに責任を持つこともありえます。そのような場合は、以下の設定事項について判断する必要があります。

設定が完了したサーバの保守には、以下の作業が必要です。

コンピュータは、サーバとクライアントのどちらにもなれることに注意してください。ローカルファイルシステムをリモートコンピュータと共有したり、リモートファイルシステムをマウントしたりできます。

ファイルシステムの自動共有

NFS 環境でファイルシステムを共有することにより、サーバのファイルシステムにアクセスできるようになります。共有するファイルシステムは、share コマンドや /etc/dfs/dfstab ファイルに指定します。

/etc/dfs/dfstab ファイルの項目は、NFS サーバオペレーションを起動したときに自動的に共有されます。同じファイルシステムを定期的に共有する必要がある場合は、自動共有を設定しなければなりません。たとえばサーバがディスクのないクライアントをサポートしている場合、クライアントのルートディレクトリを常に使用できるようにしておく必要があります。ファイルシステムの共有はほとんどが自動的に行われます。共有を手動で実行するのは、テストか障害追跡の場合だけです。

dfstab ファイルには、サーバがクライアントと共有するすべてのファイルシステムが列挙されており、どのクライアントがファイルシステムをマウントできるかを制御します。dfstab を修正してファイルシステムの追加や削除を行う場合、または共有方法を修正する場合には、ファイルを vi などのテキストエディタで編集します。コンピュータが次に実行レベル 3 に入ったときに、システムが、更新された dfstab を読み、ファイルシステムの共有方法が自動的に判断されます。

dfstab ファイルの各行は、share コマンドで構成されています。その share コマンドは、コマンド行プロンプトに入力してファイルシステムを共有するのと同じコマンドです。share コマンドは、/usr/sbin に保存されています。

ファイルシステム自動共有を設定する方法

  1. /etc/dfs/dfstab ファイルを編集します。

    自動的に共有するファイルシステムの項目を dfstab ファイルに書き込みます。各項目は、ファイルの１行に納めなければなりません。構文は以下のとおりです。 


    share [-F nfs] [-o specific-options] [-d description] pathname

  2. NFS サービスがサーバで動作していることを確認します。

    share コマンド、または share コマンドのセットを初めて実行する場合は、NFS デーモンが動作しない傾向が高くなります。以下のコマンドでデーモンを削除し、再起動してください。


    # /etc/init.d/nfs.server stop
# /etc/init.d/nfs.server start

    これで NFS サービスがサーバで実行されます。ブート時にサーバが実行レベル３になったときには、自動的に再起動されます。

    この時点で autofs マップを設定し、サーバで共有しているファイルシステムにクライアントがアクセスできるようにします。「autofs の設定」 を参照してください。

ファイルシステムのマウント

ファイルシステムをマウントするには、いくつかの方法があります。システムをブートするときに自動的にマウントされるようにするか、コマンド行から必要に応じてマウントするか、オートマウンタを使用します。オートマウンタには、ブート時のマウントやコマンド行からのマウントに比較していくつもの利点がありますが、状況によってこれら 3 つを組み合わせることが必要です。

ブート時のマウント

autofs マップを使用するのではなく、ブート時にファイルシステムをマウントするには、次の手順に従います。この手順は、すべてのローカルファイルシステムで実行しなければなりません。すべてのクライアントで実行しなければならないので、リモートファイルシステムでの実行は推奨できません。

    /etc/vfstab ファイルを編集します。

/etc/vfstab ファイルのエントリ構文は、次のとおりです。

special fsckdev mountp fstype fsckpass mount-at-boot mntopts

vfstab ファイルの項目の例

wasp サーバの /var/mail ディレクトリをクライアントに /var/mail としてマウントするとします。そのためには、クライアント側で、ファイルシステムを /var/mail としてマウントし、読み出しと書き込みの両方ができるようにします。この場合は、以下の項目をクライアントの vfstab ファイルに追加します。


wasp:/var/mail - /var/mail nfs - yes rw
注意 - 注意 -

NFS サーバに NFS vfstab ファイルのエントリを作成するとデッドロックが発生する可能性があるため、作成してはなりません。NFS サービスは、/etc/vfstab のエントリがチェックされてから起動されます。そのため、互いのファイルシステムをマウントしている 2 台のサーバが同時にダウンすると、リブート中にシステムがハングする可能性があります。

コマンド行からマウントする方法

通常オペレーションの間にファイルシステムを手動でマウントするには、mount コマンドをスーパーユーザとして実行します。 


# mount -F nfs -o ro bee:/export/share/local /mnt

上の例では、bee サーバの /export/share/local ファイルシステムが、ローカルシステムの /mnt に読み取り専用でマウントされます。コマンド行からこのようにマウントすることにより、ファイルシステムを一時的に表示することができます。umount を実行するかローカルホストをリブートすると、このマウントは解除されます。

注意 - 注意 -

Solaris 2.6 およびそれ以降に出たパッチに置き換えられた mount コマンドでは、無効なオプションを指定しても警告されません。解釈できないオプションがあると無視されるだけです。予想外の結果が生じるのを避けるために、使用するオプションはすべて確認してください。

オートマウンタを使ってマウントする方法

第 5 章「autofs について」 では、オートマウンタによるマウント方法と保守方法について説明します。通常のシステムに変更を加えずに、リモートファイルシステムが /net マウントポイントでアクセスできるようになります。前の例のように /export/share/local ファイルシステムをマウントする場合、以下を入力するだけです。 


% cd /net/bee/export/share/local

オートマウンタでは、すべてのユーザがファイルシステムをマウントできるので、root としてアクセスする必要はありません。またファイルシステムのマウントを自動的に解除できるので、作業の終了後、ファイルシステムのマウントを解除する必要はありません。

NFS サービスの設定

この節では、NFS サービスを起動または使用するために必要なタスクについて説明します。

NFS サービスを起動する方法

    リブートせずにデーモンを起動するには、スーパーユーザとしてログインして次のコマンドを入力します。


# /etc/init.d/nfs.server start

/etc/dfs/dfstab の中にエントリがあれば、これによってデーモンが起動します。

NFS サービスを停止する方法

    リブートせずにデーモンを停止するには、スーパーユーザとしてログインして次のコマンドを入力します。


# /etc/init.d/nfs.server stop

NFS サーバ上の大型ファイルを無効にする方法

  1. ファイルシステムに大型ファイルが存在しないことを確認します。

    大型ファイルを検索するコマンドの例を示します。


    # cd /export/home1
# find . -xdev -size +2000000 -exec ls -l {} ¥;
    このファイルシステムに大型ファイルが存在する場合は、削除するか別のファイルシステムに移動しなければなりません。

  2. ファイルシステムをアンマウントします。


    # umount /export/home1

  3. ファイルシステムが -largefiles を使ったマウントされていた場合は、ファイルシステムの状態をリセットします。

    fsck を使うと、大型ファイルが存在しないファイルシステムの状態をリセットできます。


    # fsck /export/home1

  4. -nolargefiles を使ってファイルシステムをマウントします。


    # mount -F ufs -o nolargefiles /export/home1

    これはコマンド行からも実行できますが、このオプションを何度も使う場合には次のようなエントリを /etc/vfstab ファイルに追加しておきます。


    /dev/dsk/c0t3d0s1 /dev/rdsk/c0t3d0s1 /export/home1  ufs     2       yes     nolargefiles
    注 -

    今までの Solaris 環境では、大型ファイルは扱えません。クライアントが大型ファイルにアクセスする必要があるときは、NFS サーバのクライアントで実行されている Solaris のバージョンが 2.6 以上であることを確認してください。

クライアント側障害時回避機能の使用方法

    NFS クライアントで、-ro オプションを使ってファイルシステムをマウントします。

これは、コマンド行からも、オートマウンタを使っても、または /etc/vfstab ファイルに次のようなエントリを追加することによっても実現できます。


bee,wasp:/export/share/local - /usr/local nfs - no -o ro

この構文は古いバージョンのオートマウンタでも受け入れられていましたが、ファイルシステムはマウントされても障害時回避機能は使用できなかったため、サーバが選択されるだけでした。

注 -

異なるバージョンの NFS プロトコルを実行しているサーバを、コマンド行や vfstab のエントリに混在させないでください。サポートしているプロトコルが NFS V2 のサーバと V3 のサーバとを混在できるのは、autofs を使用するときだけです。この場合、バージョン 2 かバージョン 3 のサーバのうち、多い方が使われます。

1 つのクライアントに対するマウントアクセスを無効にする方法

  1. /etc/dfs/dfstab ファイルを編集します。

    1 つめの例では、eng ネットグループ内のクライアントのうち rose というホスト以外すべてに対してマウントアクセスが許可されます。2 つめの例では、eng.sun.com DNS ドメイン内のクライアントのうち rose 以外すべてに対してマウントアクセスが許可されます。


    share -F nfs -o ro=-rose:eng /export/share/man
share -F nfs -o ro=-rose:.eng.sun.com /export/share/man

    アクセスリストについての詳細は、「share コマンドを使ってアクセスリストを設定する」 を参照してください。

  2. shareall コマンドを実行します。

    /etc/dfs/dfstab への変更は、このファイルシステムがもう 1 度共有されるかサーバがリブートされるまでは NFS サーバに反映されません。


    # shareall

ファイアウォールを越えて NFS ファイルシステムをマウントする方法

  1. スーパーユーザになります。

  2. 手動でファイルシステムをマウントします。たとえば、次のようなコマンドを入力します 。


    # mount -F nfs -o public bee:/export/share/local /mnt

    この例では、/export/share/local というファイルシステムは、公共ファイルハンドルを使ってローカルクライアントにマウントしています。標準のパス名の代わりに、NFS URL を使用することができます。ただし bee サーバで公共ファイルハンドルがサポートされていないと、マウント操作は失敗します。

    注 -

    この手順は、NFS サーバ上のファイルシステムが public オプションを使用して共有されていることと、クライアントとサーバの間のすべてのファイアウォールでポート 2049 による TCP 接続が可能であることが前提です。Solaris 2.6 からは、共有されているファイルシステムはすべて公共ファイルハンドルによるアクセスが可能です。

NFS URL を使用して NFS ファイルシステムをマウントする方法

  1. スーパーユーザになります。

  2. 手動でファイルシステムをマウントします。たとえば、次のようなコマンドを入力します 。


    # mount -F nfs nfs://bee:3000/export/share/local /mnt

    この例では、bee というサーバの /export/share/local というファイルシステムが、NFS ポート番号 3000 を使用してマウントされます。ポート番号は指定しなくてもかまいません。その場合、デフォルトの NFS ポート番号である 2049 が使用されます。NFS URL には public オプションを指定できます。public オプションを指定しない場合、サーバが公共ファイルハンドルをサポートしていなければ、MOUNT プロトコルが使用されます。public オプションを指定すると、必ず公共ファイルハンドルを使用するように指定され、公共ファイルハンドルがサポートされていないとマウントは失敗します。

Secure NFS システムの管理

Secure NFS システムを使用するには、自分が責任を持つすべてのコンピュータにドメイン名が必要です。「ドメイン」とは管理上の実体であり、一般には、大きなネットワークに参加する複数のコンピュータから構成されます。NIS+ を実行している場合、そのドメインに対して NIS+ ネームサービスを設定しなければなりません。『Solaris ネーミングの設定と構成』を参照してください。

Secure NFS 環境は、認証に Diffie-Hellman (DH) か Kerberos (KERB) バージョン 4、または両方の組み合わせを使用するように設定できます。これらの認証サービスについては、『Solaris のシステム管理 (第 2 巻)』の「システムセキュリティの管理の概要」を参照してください。

DH 認証を使って Secure NFS 環境を設定する方法

  1. ドメインにドメイン名を割り当て、そのドメイン名をドメイン内の各コンピュータに知らせます。

    ネームサービスとして NIS+ を使っている場合は、『Solaris ネーミングの管理』を参照してください。

  2. newkey または nisaddcred コマンドを使ってクライアントのユーザの公開鍵と秘密鍵を設定して、各ユーザに chkey コマンドを使って各自の Secure RPC パスワードを設定してもらいます。

    注 -

    これらのコマンドについての詳細は、newkey(1M)、nisaddcred(1M)、chkey(1) のマニュアルページを参照してください。

    公開鍵と秘密鍵が生成されると、公開鍵と暗号化された秘密鍵が publickey データベースに格納されます。

  3. ネームサービスが応答していることを確認します。NIS+ を実行している場合は、以下を入力してください。


    # nisping -u
Last updates for directory eng.acme.com. :
Master server is eng-master.acme.com.
 Last update occurred at Mon Jun 5 11:16:10 1995

Replica server is eng1-replica-replica-58.acme.com.
 Last Update seen was Mon Jun 5 11:16:10 1995

    NIS を実行している場合は、ypbind デーモンが動作していることを確認してください。

  4. keyserv デーモン (キーサーバ) が動作していることを、以下を入力することで確認してください。 


    # ps -ef | grep keyserv
root 100 		 1		 16	 Apr 11 ?			 0:00 /usr/sbin/keyserv
root	 2215 2211			 5 09:57:28 pts/0 0:00 grep keyserv

    keyserv デーモンが動作していない場合は、以下を入力してキーサーバを起動します。 


    # /usr/sbin/keyserv

  5. keylogin を実行し、秘密鍵の復号化と保存を実行してください。

    通常、ログインパスワードはネットワークパスワードと同じです。この場合、keylogin は不要です。ログインパスワードとネットワークパスワードが異なる場合、ユーザはログインしてから keylogin を実行しなければなりません。 また、keylogin -r を root として実行し、復号化した秘密鍵を /etc/.rootkey に保存しなければなりません。

    注 -

    keylogin -r は、root の秘密鍵が変更されたか、/etc/.rootkey が損失した場合にのみ、実行する必要があります。

  6. /etc/dfs/dfstab ファイルを編集し、該当するエントリに -sec=dh オプションを追加します (DH 認証用)。 


    share -F nfs -o sec=dh /export/home

  7. auto_master マップを編集し、該当するエントリのマウントオプションとして -sec=dh を指定します (DH 認証用)。 


    /home	auto_home	-nosuid,sec=dh
    注 -

    リリース 2.5 以前の Solaris では、セキュリティ保護されているものとして共有されているファイルシステムを、セキュリティ保護されたものとしてクライアントがマウントしないと、ユーザはそのユーザ本来の立場ではなく未認証としてのアクセス権しか得られません。Solaris 2.5 以降の NFS バージョン 2 では、セキュリティモードが一致しないと、share コマンド行に -sec=none が指定されていない限り、NFS サーバによってアクセスが拒否されます。NFS のバージョン 3 では、セキュリティ保護されていることを示すモードが NFS サーバから引き継がれるので、クライアントが -sec=krb4 や -sec=dh を指定する必要はありません。ユーザは、そのユーザ自身としてファイルにアクセスできます。

    コンピュータを設置し直したり、移設したり、アップグレードするときに、新しい鍵を設定せず、root 用の鍵も変更しない場合は、忘れずに /etc/.rootkey を保存してください。/etc/.rootkey を削除する場合は、以下を実行してください。 


    # keylogin -r

セキュリティ保護された NFS 環境を KERB 認証を使用して設定する方法

  1. /etc/dfs/dfstab ファイルを編集して、所定のエントリに sec=krb4 オプションを追加します。 


    # share -F nfs -o sec=krb4 /export/home

  2. auto_master データを編集して、sec=krb4 をマウントオプションとして指定します。 


    /home	auto_home	-nosuid,sec=krb4
    注 -

    リリース 2.5 以降の Solaris では、セキュリティ保護されているものとして共有されているファイルシステムを、セキュリティ保護されたものとしてクライアントがマウントしないと、ユーザはそのユーザ本来の立場ではなく未認証としてのアクセス権しか得られません。Solaris 2.5 以降の NFS のバージョン 2 では、セキュリティモードが一致しないと、share コマンド行に -sec=none が指定されていない限り、NFS サーバによってアクセスが拒否されます。バージョン 3 では、セキュリティ保護されていることを示すモードが NFS サーバから引き継がれるので、クライアントが -sec=krb4 や -sec=dh を指定する必要はありません。ユーザは、そのユーザ自身としてファイルにアクセスできます。

WebNFS の管理タスク

この節では、WebNFS システムを管理する方法を説明します。以下のタスクについて説明します。

WebNFS アクセスの計画

WebNFS の機能を使用するには、まずアプリケーションを実行して NFS URL (nfs://server/path など) を読み込む必要があります。次に、WebNFS アクセスのためにエクスポートするファイルシステムを選択します。アプリケーションが Web ブラウザの場合には、Web サーバの文書のルートがよく使われます。WebNFS アクセスのためにエクスポートするファイルシステムを選択するときには、考慮すべきことがいくつかあります。

  1. 各サーバには公共ファイルハンドルが 1 つずつあり、このハンドルはデフォルトではサーバのルートファイルシステムに結び付けられています。NFS URL に示されたパスは、この公共ファイルハンドルが結び付けられているディレクトリからの相対パスとして評価されます。その結果としてパスが示す先のファイルまたはディレクトリが、エクスポートされたファイルシステムの中にあると、サーバによってアクセスが実現されます。share コマンドの -public オプションを使うと、エクスポートされる特定のディレクトリにこの公開ファイルハンドルを結び付けることができます。このオプションを使うと、URL はサーバのルートファイルシステムではなく共有ファイルシステムからの相対パスになります。デフォルトでは公開ファイルハンドルはルートファイルシステムを示していますが、ルートファイルシステムを共有しないかぎりこのファイルハンドルでは Web アクセスはできません。

  2. WebNFS 環境では、すでにマウント権限を持っているユーザはファイルシステムが -public オプションを使ってエクスポートされているかどうかに関係なく、ブラウザからファイルにアクセスできます。ユーザは NFS の設定によってファイルに対するアクセス権を持っているため、ブラウザからのアクセスを許すことによって新たにセキュリティが損なわれるおそれはありません。 ファイルシステムをマウントできないユーザは、-public オプションを使ってファイルシステムを共有するだけで WebNFS アクセスを使えるようになります。

  3. FTP アーカイブの最上位ディレクトリや Web サイトの中心となる URL など、すでに公開されているファイルシステムは -public オプションを使用する対象の有力な候補です。

  4. share コマンドで -index オプションを使うと、NFS URL がアクセスされたときにディレクトリがリストされるのではなく HTML ファイルがロードされます。

    ファイルシステムを選択したらファイルを確認し、必要に応じてファイルやディレクトリの表示を制限するようにアクセス権を設定します。アクセス権は、共有される NFS ファイルシステムに合わせて設定します。多くのサイトでは、ディレクトリに対しては 755、ファイルに対しては 644 が適切なアクセスレベルです。

    1 つの Web サイトへのアクセスに NFS URL と HTTP URL の両方を使用する場合には、ほかにも考慮すべき要素があります。「Web ブラウザと比較した場合の WebNFS の制約」 を参照してください。

WebNFS アクセスを有効にする方法

バージョン 2.6 以降では、NFS マウントが可能なファイルシステムはすべてデフォルトで自動的に WebNFS アクセスでも利用できます。この手順を実行する必要があるのは、NFS マウントが許可されていないサーバで、公開ファイルハンドルをリセットすることで NFS URL を短くできるか -index オプションが必要な場合だけです。

  1. /etc/dfs/dfstab ファイルを編集します。

    自動的に共有したいファイルシステムに対応するエントリを 1 つ追加します。-index タグは省略可能です。


    share -F nfs -o ro,public,index=index.html /export/ftp

  2. NFS サービスがサーバで実行されていることを確認します。

    share コマンド、または share コマンドのセットを初めて実行する場合は、NFS デーモンが動作していないと考えられます。以下のコマンドでデーモンを削除し、再起動してください。


    # /etc/init.d/nfs.server stop
# /etc/init.d/nfs.server start

  3. ファイルシステムを共有します。

    /etc/dfs/dfstab ファイルの中にエントリが存在していれば、システムをリブートするか shareall コマンドを実行することによってファイルシステムを共有できます。手順 2 で NFS デーモンを再起動した場合には、そのスクリプトによって shareall コマンドが実行されるため、改めて実行する必要はありません。


    # shareall

  4. 情報が正しいことを確認します。

    share コマンドを実行して、表示されるオプションが正しいか確認します。


    # share
- /export/share/man ro ""
- /usr/src rw=eng ""
- /export/ftp ro,public,index=index.html ""

NFS URL を使ったブラウズ

WebNFS アクセスをサポート可能なブラウザは、次のような形式の NFS URL を使ってアクセスを実現します。


nfs://server<:port>/path

server はファイルサーバの名前、port はポート番号 (デフォルトは 2049)、path はファイルへのパスです。パスは、そのサーバの公開ファイルハンドルまたはルートファイルシステムからの相対パスで示します。

注 -

ほとんどのブラウザでは、URL サービスタイプ (nfs や http など) は別のサービスタイプの URL が読み込まれるまで次のトランザクションに引き継がれます。NFS URL を使用しているときに HTTP URL への参照が読み込まれると、それ以降のページは次に URL で NFS URL が指定されるまで、NFS プロトコルではなく HTTP プロトコルを使って読み込まれます。

ファイアウォール経由で WebNFS を使用する方法

ローカルのサブネットに属していないクライアントに対して WebNFS アクセスを有効にするには、ポート 2049 での TCP 接続を許可するようにファイアウォールを設定します。httpd に対してアクセスを許可するだけでは、NFS URL が使えるようにはなりません。

NFS における障害追跡の概要

NFS のトラブルを追跡するとき、主な障害発生ポイントとしてサーバ、クライアント、またはネットワーク自体の 3 つがあることを覚えておいてください。この節で説明するのは、個々の構成要素を切り離して、正常に動作しない部分を見つ出そうというものです。リモートマウントを正常に実行するには、サーバ上で mountd と nfsd が動作している必要があります。

注 -

/etc/dfs/dfstab ファイルに NFS 共有エントリがある場合、mountd と nfsd はブート時に自動的に起動します。したがって、最初に共有設定を行うときには mountd と nfsd を手作業で起動しなければなりません。

デフォルトでは、すべてのマウントに -intr オプションが設定されます。プログラムが「server not responding」(サーバが応答しません) というメッセージを出してハングした場合、これはキーボード割り込み (Ctrl-C) で終了できます。

ネットワークまたはサーバに問題がある場合、ハードマウントされたリモートファイルにアクセスするプログラムの障害と、ソフトマウントされたリモートファイルにアクセスするプログラムの障害とは異なります。ハードマウントされたリモートファイルシステムの場合、クライアントのカーネルは、サーバが再び応答するまで要求を再試行します。ソフトマウントされたリモートファイルシステムの場合、クライアントのシステムコールは、しばらく試行した後でエラーを返します。このエラーによって予想外のアプリケーションエラーやデータ破壊が起きるおそれがあるため、ソフトマウントは行わないでください。

ファイルシステムがハードマウントされていると、サーバが応答に失敗した場合には、これにアクセスしようとするプログラムはハングします。この場合、NFS は次のメッセージをコンソールに表示します。 


NFS server hostname not responding still trying

サーバが少し後に応答すると、次のメッセージがコンソールに表示されます。


NFS server hostname ok

サーバが応答しないような、ソフトマウントされたファイルシステムにアクセスしているプログラムは、次のメッセージを表示します。


NFS operation failed for server hostname: error # (error_message)
注 -

読み取りと書き込みをするデータを持つファイルシステム、または実行可能ファイルを持つファイルシステムは、ソフトマウントしないでください。エラーが発生する可能性があります。アプリケーションがそのようなソフトエラーを無視すれば、書き込み可能なデータが破壊される恐れがあります。またマウントされた実行可能ファイルが正常にロードされず、動作も正常に行われない可能性があります。

NFS の障害追跡手順

NFS サービスがエラーになった場所を判断するには、いくつかの手順を踏まなければなりません。以下の項目をチェックしてください。

上記の項目をチェックする過程で、ネームサービスやネットワークのハードウェアなど、ネットワークの他の部分が機能していないことが判明する場合があります。NIS+ ネームサービスのデバッグ手順については、『Solaris ネーミングの管理』を参照してください。問題がクライアント側のものではないことが判明することもあります (たとえば作業領域の各サブネットから、最低 1 つのトラブルコールがある場合など)。このような場合は、問題がサーバかサーバ周辺のネットワークハードウェアで発生しているとみなし、クライアントではなく、サーバでデバッグを開始するほうがよいでしょう。

NFS クライアントの接続性のチェック

  1. クライアントと NFS サーバが、ソフトウェア的に接続されていることを確認します。以下のコマンドをクライアントで入力してください。 


    % /usr/sbin/ping bee
bee is alive

    コマンドを入力した結果、サーバが動作していることがわかったら、NFS サーバをリモートでチェックしてください (「NFS サーバをリモートでチェックする方法」 参照)。

  2. クライアントとサーバがソフトウェア的に接続されていない場合は、ローカルネームサービスが動作していることを確認してください。NIS+ クライアントでは、以下を入力します。


    % /usr/lib/nis/nisping -u
Last updates for directory eng.acme.com. :
Master server is eng-master.acme.com.
        Last update occurred at Mon Jun  5 11:16:10 1995
 
Replica server is eng1-replica-58.acme.com.
        Last Update seen was Mon Jun  5 11:16:10 1995

  3. ネームサービスが実行されている場合は、クライアントが正しいホスト情報を受け取るために次のように入力します。


    % /usr/bin/getent hosts bee
129.144.83.117  bee.eng.acme.com

  4. ホスト情報に誤りがなく、クライアントからサーバに接続できない場合は、別のクライアントから ping コマンドを実行します。

    ping コマンドが失敗したら、「サーバで NFS サービスを確認する方法」 を参照してください。

  5. 別のクライアントとサーバがソフトウェア的に接続されている場合は、ping コマンドを使用して元のクライアントとローカルネット上の他のシステムとの接続性をチェックしてください。

    エラーになる場合は、そのクライアントのネットワークソフトウェアの構成をチェックします (/etc/netmasks、/etc/nsswitch.conf など)。

  6. ソフトウェアに問題がない場合は、ネットワークハードウェアをチェックしてください。

    クライアントをネットワークの別の場所へ移動してチェックしてください。

NFS サーバをリモートでチェックする方法

  1. NFS サーバで NFS サービスが実行されていることを、次のコマンドを入力することによって確認します。


    % rpcinfo -s bee|egrep 'nfs|mountd'
100003  3,2     tcp,udp                          nfs      superuser
100005  3,2,1   ticots,ticotsord,tcp,ticlts,udp  mountd   superuser

    デーモンが起動していなければ、「NFS サービスの再起動」 を参照してください。

  2. サーバで nfsd プロセスが応答することをチェックしてください。クライアントで以下のコマンドを入力します。 


    % /usr/bin/rpcinfo -u bee nfs
program 100003 version 2 ready and waiting
program 100003 version 3 ready and waiting

    サーバが動作している場合、プログラムとバージョン番号が表示されます。-t オプションを使用すると、TCP 接続を検査できます。-t オプションでエラーが発生する場合は、「サーバで NFS サービスを確認する方法」 に進んでください。

  3. サーバで mountd が応答することをチェックしてください。以下のコマンドを入力します。 


    % /usr/bin/rpcinfo -u bee mountd
program 100005 version 1 ready and waiting
program 100005 version 2 ready and waiting
program 100005 version 3 ready and waiting

    -t オプションを使用すると、TCP 接続を検査できます。エラーになる場合は、「サーバで NFS サービスを確認する方法」 に進んでください。

  4. ローカル autofs サービスを使用していた場合は、それをチェックしてください。


    % cd /net/wasp

    /net か /home マウントポイントのうち、適切に動作する方をチェックします。動作しない場合は、以下のコマンドをルートとしてクライアントから入力し、autofs サービスを再起動してください。


    # /etc/init.d/autofs stop
# /etc/init.d/autofs start

  5. サーバのファイルシステムの共有が正常に行えることを確認します。


    % /usr/sbin/showmount -e bee
/usr/src										eng
/export/share/man						(everyone)

    サーバの項目とローカルマウントエントリにエラーがないことをチェックします。名前空間もチェックしてください。この例で最初のクライアントが eng ネットグループの中にない場合、/usr/src ファイルシステムはマウントできません。

    すべてのローカルファイルを調べて、マウント情報を含むエントリをすべて検査します。リストには、/etc/vfstab とすべての /etc/auto_* ファイルが含まれています。

サーバで NFS サービスを確認する方法

  1. サーバに root としてログインします。

  2. サーバとクライアントがソフトウェア的に接続されていることを確認します。


    # ping lilac
lilac is alive

  3. サーバとクライアントがソフトウェア的に接続されていない場合は、ローカルネームサービスが動作していることを確認します。NIS+ クライアントで以下のコマンドを入力してください。


    % /usr/lib/nis/nisping -u
Last updates for directory eng.acme.com. :
Master server is eng-master.acme.com.
        Last update occurred at Mon Jun  5 11:16:10 1995
 
Replica server is eng1-replica-58.acme.com.
        Last Update seen was Mon Jun  5 11:16:10 1995

  4. ネームサービスが動作している場合は、サーバにあるネットワークソフトウェアの構成をチェックしてください (/etc/netmasks、/etc/nsswitch.conf など)。

  5. 以下のコマンドを入力し、nfsd デーモンが動作していることをチェックします。 


    # rpcinfo -u localhost nfs
program 100003 version 2 ready and waiting
program 100003 version 3 ready and waiting
# ps -ef | grep nfsd
root    232      1  0  Apr 07     ?     0:01 /usr/lib/nfs/nfsd -a 16 root   3127
2462  1  09:32:57  pts/3  0:00 grep nfsd

    rpcinfo の -t オプションを使用し、TCP 接続を確認してください。エラーになる場合は、NFS サービスを再起動してください (「NFS サービスの再起動」 参照)。

  6. 以下のコマンドを入力し、mountd デーモンが動作していることを確認します。 


    # /usr/bin/rpcinfo -u localhost mountd
program 100005 version 1 ready and waiting
program 100005 version 2 ready and waiting
program 100005 version 3 ready and waiting
# ps -ef | grep mountd
root	   145		  1	0	Apr 07 ?			21:57 /usr/lib/autofs/automountd
root	   234		  1	0	Apr 07 ?			 0:04 /usr/lib/nfs/mountd
root	  3084 	  2462	1 09:30:20 pts/3  0:00 grep mountd

    rpcinfo に -t オプションを指定し、TCP 接続もチェックしてください。エラーになる場合は、NFS サービスを再起動します (「NFS サービスの再起動」 参照)。

  7. 以下のコマンドを入力し、rpcbind デーモンが動作していることを確認します。 


    # /usr/bin/rpcinfo -u localhost rpcbind
program 100000 version 1 ready and waiting
program 100000 version 2 ready and waiting
program 100000 version 3 ready and waiting

    rpcbind がハングしている場合は、サーバをリブートするか、「rpcbind のワームスタート」 に示す作業を行ってください。

NFS サービスの再起動

    リブートせずにデーモンを動作させるには、スーパーユーザになって以下のコマンドを入力します。 


# /etc/init.d/nfs.server stop
# /etc/init.d/nfs.server start

/etc/dfs/dfstab に項目がある場合、デーモンは停止してから再起動します。

rpcbind のワームスタート

何らかのプログラムが動作しているために NFS サーバをリブートできない場合は、以下のようにワームスタートすることで、RPC を使用するすべてのサービスを再起動せずに rpcbind を再起動できます。

  1. root としてサーバにログインし、rpcbindno の PID を調べます。

    ps を実行すると、PID の値が第 2 カラムに表示されます。


    # ps -ef |grep rpcbind
    root   115     1  0   May 31 ?        0:14 /usr/sbin/rpcbind
    root 13000  6944  0 11:11:15 pts/3    0:00 grep rpcbind

  2. SIGTERM シグナルを rpcbind プロセスに送ります。

    以下の例では、送信するシグナルは term で、プログラムの PID は 115 です (kill(1) のマニュアルページ参照)。これにより、rpcbind は /tmp/portmap.file と /tmp/rpcbind.file に現在登録されているサービスのリストを作成します。


    # kill -s term 115
    注 -

    -s term オプションを使って rpcbind プロセスを終了させないと、rpcbind のワームスタートを完了できません。その場合は、サーバを再起動することによってサービスを再開する必要があります。

  3. rpcbind を再起動します。

    rpcbind のワームスタートを実行すると、kill コマンドの実行で作成されたファイルが参照されるので、すべてのRPCサービスを再起動せずにプロセスを再起動できます (rpcbind(1M) のマニュアルページ参照)。


    # /usr/sbin/rpcbind -w

NFS ファイルサービスを提供しているホストを識別する方法

    -m オプションを指定して nfsstat コマンドを実行し、最新の NFS 情報を取得します。

現在のサーバの名前は、 "currserver=" の後に表示されます。


% nfsstat -m
/usr/local from bee,wasp:/export/share/local
 Flags: vers=3,proto=tcp,sec=sys,hard,intr,llock,link,synlink,
		acl,rsize=32768,wsize=32678,retrans=5
 Failover: noresponse=0, failover=0, remap=0, currserver=bee

mount コマンドに使用されたオプションを確認する方法

Solaris 2.6 およびそれ以降に出たパッチに置き換えられた mount コマンドでは、無効なオプションを指定しても警告されません。コマンド行に入力したオプション、または /etc/vfstab から指定したオプションが有効であるかどうかを判断するには、以下の手順を実行します。

たとえば、次のコマンドが実行されたとします。


# mount -F nfs -o ro,vers=2 bee:/export/share/local /mnt

  1. nfsstat コマンドを実行してカーネルを確認します。


    # nfsstat -m
/mnt from bee:/export/share/local
Flags:  vers=2,proto=tcp,sec=sys,hard,intr,dynamic,acl,rsize=8192,wsize=8192,
        retrans=5

    ここで、bee からマウントされたファイルシステムは、プロトコルのバージョンが 2 に設定されています。nfsstat コマンドを使用しても、一部のオプションの情報は表示されませんが、オプションを確認するにはこれが最も正確な方法です。

  2. /etc/mnttab でエントリを確認します。

    mount コマンドでは、無効なオプションはマウントテーブルに追加されません。したがって、実行したコマンド行のオプションと /etc/mnttab にある当該オプションを比較すれば、nfsstat コマンドによってレポートされないオプションがわかります。


    # grep bee /etc/mnttab
bee:/export/share/local /mnt nfs        ro,vers=2,dev=2b0005e 859934818

NFS のエラーメッセージ

ここでは、エラーメッセージ、そのエラーの原因となる条件、およびその問題を解決する方法を少なくとも 1 つ示します。


Bad argument specified with index option - must be a file

-index オプションにはファイル名を指定する必要があります。ディレクトリ名は使えません。


Cannot establish NFS service over /dev/tcp: transport setup problem

このメッセージは、名前空間の中のサービス情報が更新されなかったときによく発生します。UDP に関して報告されることもあります。この問題を解決するには、名前空間の中のサービスデータを更新します。NIS+ の場合、エントリは以下のとおりです。 


nfsd nfsd tcp 2049 NFS server daemon
nfsd nfsd ucp 2049 NFS server daemon

NIS と /etc/services の場合、エントリは以下のとおりです。


nfsd    2049/tcp    nfs    # NFS server daemon
nfsd    2049/ucp    nfs    # NFS server daemon

Cannot use index option without public option

share コマンドに public オプションを指定してください。-index オプションを使うには、公開ファイルハンドルを定義する必要があります。

注 -

Solaris 2.6 より前の Solaris では、share コマンドを使って公共ファイルハンドルを設定する必要があります。Solaris 2.6 以降では、公共ファイルハンドルはデフォルトで / に設定されるため、このエラーメッセージは出力されません。


Could not use public filehandle in request to server

このメッセージは、public オプションが指定されているにもかかわらず NFS サーバが公共ファイルハンドルをサポートしていない場合に表示されます。この場合、マウントは失敗します。この問題を解決するには、公共ファイルハンドルを使わずにマウント要求を行うか、NFS サーバが公共ファイルハンドルをサポートするように再設定します。


NOTICE: NFS3: failing over from host1 to host2

このメッセージは、障害時回避が発生するとコンソールに表示されます。報告のためだけのメッセージです。


filename: File too large

NFS バージョン 2 クライアントが、2 ギガバイトを超えるサイズのファイルにアクセスしようとしています。


mount: ... server not responding:RPC_PMAP_FAILURE - RPC_TIMED_OUT

実行レベルの誤りか、rpcbind の停止かハングのため、マウント先のファイルシステムを共有しているサーバがダウンしているか、またはソフトウェア的に接続されていないことを示すメッセージです。


mount: ... server not responding: RPC_PROG_NOT_REGISTERED

マウントが rpcbind によって登録されているにもかかわらず、NFS マウントデーモン (mountd) が登録されていないことを示すメッセージです。


mount: ... No such file or directory

リモートディレクトリかローカルディレクトリが存在しないことを示すメッセージです。ディレクトリ名の綴りをチェックするか、リモートディレクトリとローカルディレクトリの両方で ls コマンドを実行してください。


mount: ...: Permission denied

コンピュータの名前が、クライアントのリストに載っていないか、マウントするファイルシステムにアクセスできるネットグループに含まれていないことを示すメッセージです。showmount -e を実行し、アクセスリストを確認してください。


nfs mount: ignoring invalid option "-option"

-option フラグが無効です。正しい構文を、マニュアルページの mount_nfs(1M) で確認してください。

注 -

このエラーメッセージは、Solaris 2.6 以降、またはそれ以前のバージョンにパッチを適用した状態で mount コマンドを実行したときには表示されません。


nfs mount: NFS can't support "nolargefiles"

NFS クライアントが、-nolargefiles オプションを使って NFS サーバからファイルシステムをマウントしようとしました。このオプションは、NFS ファイルシステムに対してはサポートされていません。


nfs mount: NFS V2 can't support "largefiles"

NFS バージョン 2 プロトコルでは、大型ファイルを処理できません。大型ファイルを扱う必要がある場合は、バージョン 3 を使用してください。


NFS server hostname not responding still trying

ファイル関連の作業中にプログラムがハングすると、NFSサーバは停止します。このメッセージは、NFS サーバ (hostname) がダウンしているか、サーバかネットワークに問題があることを示すものです。障害時回避機能を使用している場合、hostname はサーバ名のリストになります。「NFS の障害追跡手順」 を参照してください。


NFS fsstat failed for server hostname: RPC: Authentication error

様々な状況で発生するエラーです。最もデバッグが困難なのは、ユーザの属しているグループが多すぎる場合です。現在、ユーザは最大 16 個のグループに属すことができますが、NFS マウントでファイルにアクセスしている場合は、それ以下になります。NFS サーバと NFS クライアントで Solaris 2.5 以降が動作している場合に、ユーザが 16 以上のグループに属さなければならない場合は、ACL を使用することで必要なアクセス権を獲得できます。


port number in nfs URL not the same as port number in port option

NFS URL のポート番号は、マウントの -port オプションのポート番号と一致していなければなりません。一致していないと、マウントは失敗します。同じポート番号にしてコマンドを再実行するか、ポート番号の指定を省略してください。原則として、NFS URL と -port オプションの両方にポート番号を指定しても意味がありません。


relicas must have the same version

NFS 障害時回避機能が正しく機能するためには、複製の NFS サーバが同じバージョンの NFS プロトコルをサポートしていなければなりません。バージョン 2 とバージョン 3 のサーバが混在することは許されません。


replicated mounts must be read-only

NFS 障害時回避機能は、読み書き可能としてマウントされたファイルシステムでは動作しません。ファイルシステムを読み書き可能としてマウントすると、ファイルが変更される可能性が高くなるためです。NFS の障害時回避機能は、ファイルシステムがまったく同じであることが前提です。


replicated mounts must not be soft

複製されるマウントの場合、障害時回避が発生するまでタイムアウトを待つ必要があります。soft オプションを指定すると、タイムアウトが開始してすぐにマウントが失敗するため、複製されるマウントには -soft オプションは指定できません。


share_nfs: Cannot share more than one filesystem with `public' option

/etc/dfs/dfstab ファイルを調べて、-public オプションによって共有するファイルシステムを複数選択していないか確認してください。公開ファイルハンドルは、サーバあたり 1 つしか設定できません。したがって、-public オプションで共有できるファイルシステムは 1 つだけです。


WARNING: No network locking on hostname:path: contact admin to install server change

NFS クライアントが、NFS サーバ上のネットワークロックマネージャと接続を確立できませんでした。この警告は、マウントできなかったことを知らせるためではなくロックが機能しないことを警告するために出力されます。