test

NFS の管理

パート II NFS サービス全般について

パートII では、NFS サービスの大部分の機能とそれらの管理方法について説明します。パートIII では、autofs を取り上げます。

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

第 3 章 NFS リファレンス

この章では、NFS コマンドの概要について説明します。また、NFS 環境のすべての構成要素とそれらが互いにどのように連携するかについても説明します。

NFS ファイル

いくつかの ASCII ファイルでは、いずれのコンピュータ上でも NFS アクティビティをサポートする必要があります。表 3-1 に、こういったファイルとその機能をまとめます。

表 3-1 NFS の ASCII ファイル

ファイル名 

機能 

/etc/mnttab

自動的にマウントしたディレクトリを含む、現在マウントしているファイルシステムを一覧表示する (mnttab(4) のマニュアルページ参照)。編集しないこと。

/etc/netconfig

トランスポートプロトコルのリスト。編集しないこと。 

/etc/nfssec.conf

NFS のセキュリティサービスのリスト。編集しないこと。 

/etc/rmtab

NFS クライアントがリモートにマウントしたファイルシステムを一覧表示する (rmtab(4) のマニュアルページ参照)。 編集しないこと。

/etc/vfstab

ローカルにマウントするファイルシステムを定義する (vfstab(4) のマニュアルページ参照)。

/etc/default/fs

ローカルファイルシステムにおけるデフォルトファイルシステムのタイプを一覧表示する。 

/etc/dfs/dfstab

共有するローカルリソースを一覧表示する。 

/etc/dfs/fstypes

リモートファイルシステムにおけるデフォルトファイルシステムのタイプを一覧表示する。 

/etc/dfs/sharetab

共有している、ローカルとリモートのリソースを一覧表示する (sharetab(4) のマニュアルページ参照)。編集しないこと。

/etc/dfs/fstypes の最初の項目は、リモートファイルシステムにおけるデフォルトファイルシステムのタイプとして使用されることがしばしばあります。この項目は、NFS ファイルシステムのタイプをデフォルトとして定義します。

/etx/default/fs には、項目が 1 つしかありません。ローカルディスクにおけるデフォルトファイルシステムのタイプです。クライアントやサーバでサポートするファイルシステムのタイプは、/kernel/fs のファイルをチェックして決定することができます。

NFS デーモン

NFS アクティビティをサポートするには、システムが実行レベル 3 かマルチユーザモードで動作したときに、いくつかのデーモンを開始します。mountd と nfsd の 2 つのデーモンは、NFS サーバであるシステム上で動作します。サーバデーモンの自動起動は、NFS ファイルシステムのタイプでラベル付けされた項目が /etc/dfs/sharetab に存在するかどうかで変わります。

lockd と statd の 2 つのデーモンは NFS クライアントで動作し、NFS ファイルロッキングをサポートします。NFS サーバでも動作させなければなりません。

lockd

このデーモンは NFS ファイルのレコードロックをサポートします。ロック要求をクライアントから NFS サーバに送り、NFS サーバでローカルのロックを開始します。通常は、パラメータを指定せずに起動します。使用できるオプションは 3 つあります (マニュアルページの lockd(1M) を参照してください)。

-g graceperiod オプションは、サーバがリブートした場合に、その何秒後にロックを再要求するかを示します。NFS サーバはこの秒数の間、それまでのロックの再要求処理しか実行しません。他のサービスに対する要求は、この時間が経過するまで待たされます。このオプションは NFS サーバの応答性に関係するため、NFS サーバでしか変更できません。デフォルト値は 45 秒です。この値を小さくすると、サーバをリブートしてからオペレーションに復帰するまでの時間は短縮されますが、クライアントがすべてのロックを復旧できなくなる可能性が増します。

-t timeout オプションは、ロック要求をリモートサーバに再送信するまで何秒待つかを示します。このオプションは NFS クライアントのサービスに関係します。デフォルト値は 15 秒です。この値を小さくすると、雑音の多いネットワーク上の NFS クライアントに対する応答時間を改善できますが、ロック要求が増えることによってサーバの負荷が増す可能性があります。

nthreads オプションは、サーバが 1 つの接続について同時に処理できるスレッドの数の上限を示します。この値は、NFS サーバに対して予想される負荷に基づいて決定してください。デフォルト値は 20 です。TCP を使用する NFS クライアントはそれぞれ NFS サーバと 1 つの接続を設定するため、各 TCP クライアントはサーバ上で同時に 20 までのスレッドを使うことが許されます。UDP (ユーザデーモンプロトコル) を使用する NFS クライアントは、すべてが NFS サーバと 1 つの接続を共有します。その場合、UDP 接続が使用できるスレッドの数を増やさなければならないことがあるかもしれません。簡単な目安は 1 つの UDP クライアントにつき 2 つのスレッドですが、クライアントに対する作業負荷によってはこれで不十分なこともあります。使用するスレッドを増やすことによるマイナスは、スレッドの使用によって NFS サーバで使われるメモリが増えることです。しかしスレッドが使われないならば、nthreads を大きくしても影響はありません。

mountd

これは、リモートシステムからのファイルシステムマウント要求を処理して、アクセス制御を行う RPC (リモートプロシージャコール) サーバです。/etc/dfs/sharetab を調べることによって、リモートマウントに使用可能なファイルシステムと、リモートマウントを実行可能なシステムを判断します。-v と -r の 2 つのオプションが使えます (マニュアルページの mountd(1M) を参照してください)。

-v オプションは、コマンドを冗長モードで実行します。クライアントが取得すべきアクセス権を NFS サーバが決定するたびに、コンソールにメッセージが表示されます。この情報は、クライアントがファイルシステムにアクセスできない理由を調べるときに役立ちます。

-r オプションは、その後のクライアントからのマウント要求をすべて拒絶します。すでにファイルシステムがマウントされているクライアントには影響しません。

nfsd

これは、他のクライアントからのファイルシステム要求を処理するデーモンです。このコマンドに対してはいくつかのオプションが指定できます。オプションをすべて確認するにはマニュアルページの nfsd(1M) を参照してください。

-l オプションは、接続指向トランスポートでの NFS/TCP に対する接続キューの長さを設定します。デフォルト値は 25 エントリです。

-c #_conn オプションは、接続指向トランスポート 1 つあたりの接続数の上限を選択します。デフォルト値はありません。

nservers オプションは、1 台のサーバが同時に処理可能な要求の数の上限です。デフォルト値は 1 ですが、起動スクリプトでは 16 が選択されます。

このデーモンの以前のバージョンとは異なり、このバージョンの nfsd では複数のコピーを作成して要求を同時に処理することはありません。処理テーブルを ps でチェックすると、動作しているデーモンのコピーが 1 つしかないことがわかります。

statd

lockd とともに動作し、ロック管理機能にクラッシュ機能と回復機能を提供します。NFS サーバでロックを保持しているクライアントの追跡を行い、サーバがクラッシュし、リブートしているあいだに、サーバ側 statd がクライアント側 statd と連絡をとります。次にクライアント側 statd は、サーバ上のすべてのロックを再要求します。クライアントがクラッシュすると、クライアント側 statd はサーバ側 statd にそのことを伝えるので、サーバ上のロックはクリアされます。このデーモンにオプションはありません。詳細については、マニュアルページの statd(1M) を参照してください。

Solaris 7 では、statd がクライアントを追跡する方法が改善されました。Solaris 7 より前のリリースの statd では、クライアントごとにそのクライアントの修飾されていないホスト名を使用して、/var/statmon/sm にファイルが作成されました。そのため、同じホスト名の 2 つのクライアントが異なるドメインに存在する場合や、クライアントが NFS サーバと異なるドメインに存在する場合に問題が発生していました。修飾されていないホスト名にはドメインや IP アドレスの情報がないため、このようなクライアントを区別する方法がありませんでした。これに対処するため、Solaris 7 の statd では、修飾されていないホスト名に対してクライアントの IP アドレスを使用して /var/statmon/sm にシンボリックリンクを作成します。このリンクは、次のような形式です。


# ls -l /var/statmon/sm
lrwxrwxrwx   1 root          11 Apr 29 16:32 ipv4.192.9.200.1 -> myhost
--w-------   1 root          11 Apr 29 16:32 myhost

この例では、クライアントのホスト名は myhost で、IP アドレスは 192.9.200.1 です。他のホストが myhost という名前を持ち、ファイルシステムをマウントしていると、myhost というホスト名に対するシンボリックリンクは 2 つ作成されます。

NFS コマンド

以下のコマンドは、root 権限で実行しなければ、十分な効果がでません。しかし情報の要求は、すべてのユーザが行えます。

clear_locks

このコマンドを使うと、ある NFS クライアントのファイル、レコード、または共有のロックをすべて削除できます。このコマンドを実行するには、スーパーユーザでなければなりません。NFS サーバから解除できるのは特定のクライアントのロックであり、NFS クライアントから解除できるのは特定のサーバ上のそのクライアントに対するロックです。次の例では、現在のシステム上の tulip という NFS クライアントに対するロックが解除されます。 


# clear_locks tulip

-s オプションを指定すると、どの NFS ホストからロックを解除するかを指定できます。これは、そのロックをかけた NFS クライアントから実行しなければなりません。次の場合、クライアントによるロックが bee という名前の NFS サーバから解除されます。


# clear_locks -s bee
注意 - 注意 -

このコマンドは、クライアントがクラッシュしてロックを解除できないとき以外には使用しないでください。データが破壊されるのを避けるため、使用中のクライアントに関するロックは解除しないでください。

mount

このコマンドを使用すると、指定したファイルシステムをローカルかリモートで、指定したマウントポイントに添付できます。詳細については、mount(1M) のマニュアルページを参照してください。引数を指定しないと、現在ユーザのコンピュータにマウントされているファイルシステムのリストが表示されます。

Solaris の標準インストールには、さまざまな種類のファイルシステムが含まれています。すべてのファイルシステムタイプの説明は、『Solaris のシステム管理 (第 1 巻)』の"ファイルシステムのタイプ" in Solaris のシステム管理 (第 1 巻)を参照してください。ファイルシステムの種類ごとにマニュアルページがあり、その種類に対して mount を実行するときに使用可能なオプションのリストが示されています。たとえば、NFS ファイルシステムのマニュアルページは mount_nfs(1M)、UFS ファイルシステムのマニュアルページは mount_ufs(1M) などです。

Solaris 7 では、server:/pathname という標準の構文の代わりに NFS URL を使用して NFS サーバ上のマウントするパス名を指定することが可能になりました。詳細については、「NFS URL を使用して NFS ファイルシステムをマウントする方法」を参照してください。

注意 - 注意 -

Solaris 2.6 以後の mount コマンドでは、無効なオプションがあっても警告されません。解釈できないオプションがあると無視されるだけです。予想外の結果が生じるのを避けるために、使用するオプションはすべて確認してください。

NFS ファイルシステムにおける mount のオプション

NFS ファイルシステムをマウントするときに -o フラグの後に指定できるオプションの一部を、以下に示します。

bg|fg

この 2 つは、マウントが失敗したときの再試行の方法を選択するオプションです。-bg オプションの場合はバックグラウンドで、-fg オプションの場合はフォアグラウンドでマウントが試みられます。デフォルトは -fg です。常に使用可能にしておく必要のあるファイルシステムに対しては -fg が適しています。この場合、マウントが完了するまで他の処理は実行できません。-bg は、マウント要求が完了しなくてもクライアントは他の処理を実行できるため、必ずしも必要でないファイルシステムに適しています。

largefiles

このオプションを使うと、Solaris 2.6 が実行されているサーバに置かれた 2 ギガバイトを超えるサイズのファイルにアクセスできるようになります。大型ファイルにアクセスできるかどうかは、サーバでしか制御できません。したがって、このオプションは NFS バージョン 3 のマウントでは無視されます。デフォルトでは、2.6 以後の UFS ファイルシステムはすべて -largefiles オプション付きでマウントされます。NFS バージョン 2 プロトコルを使ったマウントでこのオプションを指定すると、エラーが発生してマウントできません。

nolargefiles

UFS マウントでこのオプションを指定すると、ファイルシステム上に大型ファイルが存在せず、この後も作成されないことが保証されます (マニュアルページの mount_ufs(1M) を参照してください)。大型ファイルが存在するかどうかは NFS サーバでしか制御できないため、NFS マウントを使う -nolargefiles にはオプションはありません。このオプションを指定してファイルシステムを NFS マウントしようとすると、エラーが発生して拒否されます。

public

このオプションを指定すると、NFS サーバにアクセスするときに必ず公共ファイルハンドルを使用するようになります。NFS サーバが公共ファイルハンドルをサポートしていれば、MOUNT プロトコルが使用されないため、マウント操作は短時間で行われます。また、MOUNT プロトコルを使用しないため、ファイアウォールを越えたマウントが可能です。

rw|ro

-rw オプションと -ro オプションは、ファイルシステムが読み書き可能と読み取り専用のどちらでマウントされるかを示します。デフォルトは読み書き可能で、これはリモートホームディレクトリやメールスプールディレクトリなどの、ユーザによる変更が必要なファイルシステムに適しています。読み取り専用オプションは、ユーザが変更してはいけないディレクトリに適しています。具体的には、マニュアルページの共有コピーなどです。

sec=mode

このオプションは、マウント時に使われる認証機構を指定します。mode の値は、表 3-2 に示したもののいずれかでなければなりません。モードは、/etc/nfssec.conf ファイルにも定義されます。

表 3-2 NFS セキュリティモード

モード 

選択される認証サービス 

krb4

Kerberos バージョン 4 

none

認証なし 

dh

Diffie-Hellman (DH) 認証 

sys

UNIX の標準認証 

soft|hard

soft オプションを指定してマウントされた NFS ファイルシステムは、サーバが応答しなくなるとエラーを返します。hard オプションが指定されていると、サーバが応答するまで再試行が続けられます。デフォルトは hard です。ほとんどのファイルシステムには hard を使用します。ソフトマウントされたファイルシステムからの値を検査しないアプリケーションが多いので、アプリケーションでエラーが発生してファイルが破壊されるおそれがあるためです。検査するアプリケーションの場合でも、ルーティングの問題などによってアプリケーションが正しい判断をできずに、ファイルが破壊されることがあります。原則として、soft は使用しないでください。hard オプションを指定した場合にファイルシステムが使えなくなると、そのファイルシステムを使うアプリケーションはファイルシステムが復旧するまでハングする可能性があります。

mount コマンドの使用

以下のコマンドのどちらも、bee サーバから NFS ファイルシステムを読み出し専用としてマウントします。 


# mount -F nfs -r bee:/export/share/man /usr/man


# mount -F nfs -o ro bee:/export/share/man /usr/man

このコマンドでは -O オプションによって、/usr/man がすでにマウントされていても bee サーバのマニュアルページがローカルシステムにマウントされます。 


# mount -F nfs -O bee:/export/share/man /usr/man

このコマンドでは、クライアント側障害時回避機能が使われています。 


# mount -F nfs -r bee,wasp:/export/share/man /usr/man
注 -

コマンド行から使用する場合、リスト内のサーバがサポートしている NFS プロトコルは同じバージョンでなければなりません。コマンド行から mount を実行するときは、バージョン 2 とバージョン 3 のサーバを混在させないでください。autofs では混在が可能なので、バージョン 2 サーバとバージョン 3 サーバの最適な組み合わせを使用できます。

mount コマンドで NFS URL を使用する例を示します。 


# mount -F nfs nfs://bee//export/share/man /usr/man

mount コマンドに引数を指定しないと、クライアントにマウントされたファイルシステムが表示されます。 

% mount
/ on /dev/dsk/c0t3d0s0 read/write/setuid on Tues Jan 24 13:20:47 1995
/usr on /dev/dsk/c0t3d0s6 read/write/setuid on Tues Jan 24 13:20:47 1995
/proc on /proc read/write/setuid on Tues Jan 24 13:20:47 1995
/dev/fd on fd read/write/setuid on Tues Jan 24 13:20:47 1995
/tmp on swap read/write on Tues Jan 24 13:20:51 1995
/opt on /dev/dsk/c0t3d0s5 setuid/read/write on Tues Jan 24 13:20:51 1995
/home/kathys on bee:/export/home/bee7/kathys
  intr/noquota/nosuid/remote on Tues Jan 24 13:22:13 1995

umount

このコマンドにより、現在マウントされているリモートファイルシステムが削除されます。umount コマンドは、テストのために -V オプションをサポートしています。また、-a オプションを使うことによって 1 度に複数のファイルシステムをアンマウントできます。-a オプションに mount_points を指定すると、そのファイルシステムがアンマウントされます。マウントポイントを指定しないと、/etc/mnttab のリストにあるファイルシステムのうち "required" でないものすべてのアンマウントが試みられます。"required" のファイルシステムとは、/、/usr、/var、/proc、/dev/fd、/tmp などです。

ファイルシステムがすでにマウントされていて、/etc/mnttab に項目が指定されている場合、ファイルシステムのタイプのフラグを指定する必要はありません。

ファイルシステムが使用中だと、このコマンドは実行できません。たとえば、あるユーザが cd コマンドによってファイルシステムにアクセスしていると、作業ディレクトリが他に変更されるまでそのファイルシステムは使用中となります。umount コマンドは、NFS サーバに接続できないと一時的にハングすることがあります。

umount コマンドの使用

以下の例では、/usr/man にマウントしたファイルシステムのマウントが解除されます。 


# umount /usr/man

以下の例では、umount -a -V の実行結果が表示されます。

# umount -a -V
umount /home/kathys
umount /opt
umount /home
umount /net

このコマンドでは、ファイルシステムのアンマウント自体は実行されないことに注意してください。

mountall

このコマンドを使用すると、ファイルシステムテーブルに指定したすべてのファイルシステム、または特定グループのファイルシステムをマウントできます。アクセスするファイルシステムタイプを選択するための -F FSType オプション、ファイルシステムテーブル内のリモートファイルシステムをすべて選択する -r オプション、ローカルファイルシステムをすべて選択する -l オプションがあります。 NFS ファイルシステムタイプと指定されているファイルシステムはすべてリモートファイルシステムなので、これらのオプションは余分な指定になることがあります。詳細については、マニュアルページの mountall(1M) を参照してください。

mountall コマンドの使用

以下の２つの例を実行すると、同じ結果になります。 


# mountall -F nfs


# mountall -F nfs -r

umountall

このコマンドを使用すると、ファイルシステムのグループをアンマウントできます。-k オプションは、mount_point に結び付けられているプロセスを終了させるには fuser -k mount_point コマンドを使う必要があることを表します。-s オプションは、アンマウントを並行処理しないことを示します。-l は、ローカルファイルシステムだけを使用することを、-r はリモートファイルシステムだけを使用することを示します。-h host オプションは、指定されたホストのファイルシステムをすべてアンマウントすることを指定します。-h オプションは、-l または -r とは同時に指定できません。

umountall コマンドの使用

以下のコマンドでは、リモートホストからマウントしたすべてのファイルシステムが切り離されます。 


# umountall -r

以下のコマンドでは、bee サーバからマウントしたすべてのファイルシステムが切り離されます。 


# umountall -h bee

share

このコマンドを使用すると、NFS サーバのローカルファイルシステムをマウントできるようになります。また、システム上のファイルシステムのうち、現在共有しているもののリストを表示します。NFS サーバが動作していないと、share コマンドは使用できません。NFS サーバソフトウェアは、/etc/dfs/dfstab に項目がある場合、ブートの途中で自動的に起動されます。NFS サーバソフトウェアが動作していないくても、このコマンドはエラーを表示しません。NFS サーバソフトウェアが動作していることを確認してからこのコマンドを使用するようにしてください。

ディレクトリツリーはすべて共有できるオブジェクトですが、各ファイルシステムの階層構造は、そのファイルシステムが位置するディスクスライスやパーティションで制限されます。たとえばルート (/) ファイルシステムを共有しても、/usr が同じディスクパーティションかスライスに存在しなければ、/usr を共有することはできません。通常、ルートはスライス 0 に、/usr はスライス 6 にインストールされます。また /usr を共有しても、/usr のサブディレクトリにマウントされているローカルディスクパーティションは共有できません。

すでに共有している大きいファイルシステムの一部であるファイルシステムを共有することはできません。たとえば /usr と /usr/local が同じディスクスライスにある場合、/usr も /usr/local も共有することができますが、両方を別々の共有オプションで共有する場合、/usr/local は別のディスクスライスに移動しなければなりません。

警告 - 警告 -

2 つのファイルシステムが同じディスクスライスにある場合、読み出し専用で共有しているファイルシステムに、読み出しと書き込みが可能な状態で共有しているファイルシステムのファイルハンドルでアクセスすることができます。読み出しと書き込みの両方を行うファイルシステムは、読み出し専用で共有する必要があるファイルシステムとは別のパーティションかディスクスライスに保存するほうが安全です。

share オプション

-o フラグに指定できるオプションの一部を示します。

rw|ro

pathname に指定したファイルシステムを、読み出しと書き込みの両方が可能な状態で共有するか、読み出し専用で共有するかを指定します。

rw=accesslist

ファイルシステムは、リスト上のクライアントに対してだけ読み書き可能で共有されます。それ以外の要求は拒否されます。accesslist に定義されるクライアントのリストは、Solaris 2.6 から拡張されました。詳細については、「share コマンドを使ってアクセスリストを設定する」 を参照してください。このオプションは -ro オプションよりも優先されます。

NFSファイルシステムで指定できるオプションは、以下のとおりです。

aclok

このオプションを指定すると、NFS バージョン 2 プロトコルをサポートしている NFS サーバが NFS バージョン 2 クライアントのアクセス制御を行うように設定できます。このオプションを指定しないと、すべてのクライアントは最低限のアクセスしかできません。指定すると、最大限のアクセスができるようになります。たとえば -aclok オプションを指定して共有したファイルシステムでは、1 人のユーザが読み取り権を持っていれば全員が読み取りを許可されます。このオプションを指定しないと、アクセス権を持つべきクライアントからのアクセスが拒否される可能性があります。アクセス権の与えすぎと制限しすぎのどちらを選ぶかは、現在のセキュリティシステムによって決定します。アクセス制御リスト (ACL) について詳細は、『Solaris のシステム管理 (第 2 巻)』の"ファイルのセキュリティの適用手順" in Solaris のシステム管理 (第 2 巻)を参照してください。

注 -

ACL を活用するためには、クライアントでもサーバでも NFS バージョン 3 と NFS_ACL プロトコルをサポートしているソフトウェアを実行します。NFS バージョン 3 プロトコルしかサポートしていないソフトウェアの場合、クライアントは正しいアクセス権を取得できますが、ACL を操作することはできません。NFS_ACL プロトコルをサポートしていれば、正しいアクセス権を取得した上で ACL の操作も可能です。この両方をサポートしているのは、Solaris 2.5 およびその互換バージョンです。

anon=uid

uid は、認証されていないユーザのユーザ ID を選択するために使用します。uid を -1 に設定すると、認証されていないユーザからのアクセスは拒否されます。anon=0 とするとルートアクセス権を与えることができますが、これは認証されていないユーザにルートアクセス権を与えることになるため、代わりに root オプションを使ってください。

index=filename

-index=filename オプションを使うと、ユーザが NFS URL にアクセスするとディレクトリのリストが表示されるのではなく、HTML (HyperText Markup Language) ファイルが強制的に読み込まれます。これは、HTTP URL がアクセスしているディレクトリに index.html ファイルが見つかるとブラウザのような動作をするというものです。このオプションを設定することは、httpd に対して DirectoryIndex オプションを指定するのと同じ意味があります。たとえば、dfstab ファイルのエントリが次のとおりであるとします。


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

このとき、以下の URL によって表示される情報はすべて同じです。


nfs://<server>/<dir>
nfs://<server>/<dir>/index.html
nfs://<server>//export/web/<dir>
nfs://<server>//export/web/<dir>/index.html
http://<server>/<dir>
http://<server>/<dir>/index.html
nosuid

このオプションを使うと、setuid モードまたは setgid モードを有効にしようとしても無視されます。NFS クライアントは、setuid か setgid のビットがオンの状態ではファイルを作成できません。

public

-public オプションは、WebNFS ブラウズのために追加されました。このオプションで共有できるのは、1 台のサーバにつき 1 つのファイルシステムだけです。

root=accesslist

サーバが、リスト上のホストに対してルートアクセス権を与えます。デフォルトでは、サーバはどのリモートホストにもルートアクセス権は与えません。選択されているセキュリティモードが -sec=sys 以外だと、accesslist に指定できるホストはクライアントだけです。accesslist に定義されたクライアントのリストは、Solaris 2.6 で拡張されました。詳細については、「share コマンドを使ってアクセスリストを設定する」 を参照してください。

注意 - 注意 -

他のホストにルートアクセス権を与えるには、広い範囲でセキュリティが保証されていることが前提です。-root= option は十分慎重に使用してください。

sec=mode[:mode]

mode は、ファイルシステムへのアクセス権を取得するために必要なセキュリティモードです。デフォルトのセキュリティモードは、UNIX の認証です。モードは複数指定できますが、コマンド行に指定するときは 1 行につき 1 つのセキュリティモードだけにしてください。-mode の各オプションは、次に -mode が出現するまでその後の -rw、-ro、-rw=、-ro=、-root=、-window= オプションに適用されます。-sec=none とすると、すべてのユーザがユーザ nobody にマップされます。

window=value

value は、NFS サーバで資格が有効な時間の上限です。デフォルトは 30000 秒 (8.3 時間) です。

share コマンドを使ってアクセスリストを設定する

リリース 2.6 より前の Solaris で、share コマンドの -ro=、-rw=、-root= オプションに指定する accesslist の内容は、ホスト名がネットグループ名に限定されていました。Solaris 2.6 以降では、このアクセス制御リストにドメイン名、サブネット番号、およびアクセス権を与えないエントリも指定できます。この拡張により、名前空間を変更したり多数のクライアントを定義したリストを使うことなく、サーバでのファイルアクセス制御を今までより簡単に管理できます。

以下のコマンドでは、rose と lilac では読み出しと書き込みの両方のアクセスが認められますが、その他では、読み出しのみが許可されます。 


# share -F nfs -o ro,rw=rose:lilac /usr/src

以下の例では、eng ネットグループのすべてのホストで読み出しのみができるようになります。rose クライアントでは、読み出しと書き込みの両方ができます。 


# share -F nfs -o ro=eng,rw=rose /usr/src
注 -

rw と ro には必ず引数が必要です。読み書き可能オプションを指定しないと、デフォルトによってすべてのクライアントが読み書き可能になります。

1 つのファイルシステムを複数クライアントで共有するには、すべてのオプションを同じ行に指定しなければなりません。同じオブジェクトに share コマンドを複数回実行しても、最後のコマンドしか有効になりません。以下のコマンドでは、3 つのクライアントシステムで読み出しと書き込みができますが、rose と tulip では、ファイルシステムに root でアクセスできます。


# share -F nfs -o rw=rose:lilac:tulip,root=rose:tulip /usr/src

複数の認証機構を使ってファイルシステムを共有するときには、セキュリティモードの後に必ず -ro、-ro=、-rw、-rw=、-root、-window の各オプションを指定してください。この例では、eng というネットグループ内のすべてのホストに対して UNIX 認証が選択されています。これらのホストは、ファイルシステムを読み取り専用モードでしかマウントできません。ホスト tulip と lilac は、Diffie-Hellman (DH) 認証を使えば読み書き可能でファイル・システムをマウントできます。tulip と lilac は、そのホスト名が eng ネットグループのリストに含まれていれば、DH 認証を使っていなくても読み取り専用でマウントすることは可能です。


# share -F nfs -o sec=dh,rw=tulip:lilac,sec=sys,ro=eng /usr/src

UNIX 認証はデフォルトのセキュリティモードですが、-sec を指定するとデフォルトは無効になります。他の認証機構とともに UNIX 認証も使う場合には、必ず -sec=sys オプションを指定してください。

実際のドメイン名の名前にドットを付けると、アクセスリストの中で DNS ドメイン名が使えます。ドットは、その後の文字列が完全に修飾されたホスト名ではなくドメイン名であることを表します。次のエントリは、マウントから eng.sun.com ドメイン内のすべてのホストへのアクセスを許可するためのものです。


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

この例で、"." はそれぞれ NIS または NIS+ 名前空間を通じて一致するすべてのホストに対応します。ネームサービスから返される結果にはドメイン名は含まれません。".eng.sun.com" というエントリは、名前空間の解決に DNS を使用するすべてのホストに一致します。DNS が返すホスト名は必ず完全に修飾されるので、DNS と他の名前空間を組み合わせると長いエントリが必要です。

実際のネットワーク番号かネットワーク名の前に "@" を指定すると、アクセスリストの中でサブネット番号が使えます。これは、ネットワーク名をネットグループ名や完全に修飾されたホスト名と区別するためです。サブネットは、/etc/networks の中か NIS または NIS+ 名前空間の中で識別できなければなりません。以下のエントリは、サブネット 129.144 が eng ネットワークと識別されるならばすべて同じ意味を持ちます。


# share -F nfs -o ro=@eng /export/share/man
# share -F nfs -o ro=@129.144 /export/share/man
# share -F nfs -o ro=@129.144.0.0 /export/share/man

2 番めと 3 番めのエントリは、ネットワークアドレス全体を指定する必要がないことを表しています。

ネットワークアドレスの先頭部分がバイトによる区切りでなく、CIDR (Classless Inter-Domain Routing) のようになっている場合には、マスクの長さをコマンド行で具体的に指定できます。この長さは、ネットワーク名かネットワーク番号の後ろにスラッシュで区切ってアドレスの接頭辞に有効ビット数として指定します。たとえば、次のようにします。


# share -f nfs -o ro=@eng/17 /export/share/man
# share -F nfs -o ro=@129.144.132/17 /export/share/man
この例で、"/17" はアドレスの先頭から 17 ビットがマスクとして使われることを表します。CIDR について詳細は、RFC 1519 を参照してください。

また、エントリの前に "-" を指定することでアクセスの拒否を示すこともできます。エントリは左から右に読み込まれるため、アクセス拒否のエントリはそれを適用するエントリの前に置く必要があることに注意してください。


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

この例では、eng.sun.com ドメイン内のホストのうち、rose を除いたすべてに対してアクセス権が許可されます。

unshare

このコマンドを使用すると、以前に使用可能な状態になっていたファイルシステムを、クライアントがマウントできないようにします。unshare コマンドを使用すると、share コマンドで共有したファイルシステムや、/etc/dfs/dfstab で自動的に共有しているファイルシステムが共有できないようになります。unshare コマンドを使用し、dfstab ファイルで共有しているファイルシステムの共有を解除する場合は、実行レベル 3 を終了して再度実行レベル 3 に戻ると、そのファイルシステムがまた共有されることに注意してください。実行レベル 3 を終了しても変更内容を継続させるには、そのファイルシステムを dfstab ファイルから削除しなければなりません。

NFSファイルシステムの共有を解除している場合、クライアントから既存マウントへのアクセスは禁止されます。クライアントにはファイルシステムがまだマウントされている可能性がありますが、ファイルにはアクセスできません。

unshare コマンドの使用

以下のコマンドでは、指定したファイルシステムの共有が解除されます。


# unshare /usr/src

shareall

このコマンドを使用すると、複数のファイルシステムを共有することができます。オプションなしで使用すると、/etc/dfs/dfstab 内のすべてのエントリが共有されます。share コマンドを並べたファイルの名前を指定することができます。ファイル名を指定しないと、/etc/dfs/dfstab の内容が検査されます。"-" を使ってファイル名を置き換えれば、標準入力から share コマンドを入力できます。

shareall コマンドの使用

以下のコマンドでは、ローカルファイルに羅列されているすべてのファイルシステムが共有されます。 


# shareall /etc/dfs/special_dfstab

unshareall

このコマンドを使用すると、現在共有されているリソースがすべて使用できなくなります。-F FSType オプションによって、/etc/dfs/fstypes に定義されているファイルシステムタイプのリストを選択します。このフラグによって、特定のタイプのファイルシステムだけを共有解除できます。デフォルトのファイルシステムタイプは、/etc/dfs/fstypes に定義されています。特定のファイルシステムを選択するには、unshare コマンドを使います。

unshareall コマンドの使用

次の例では、NFS タイプのすべてのファイルシステムの共有が解除されます。


# unshareall -F nfs

showmount

このコマンドを使用すると、NFS サーバから共有したファイルシステムをリモートにマウントしたすべてのクライアントや、クライアントがマウントしたファイルシステム、または共有しているファイルシステムとクライアントのアクセス情報が表示されます。構文は以下のとおりです。

showmount [ -ade ] [ hostname ]

-a を指定すると、すべてのリモートマウント (クライアント名とディレクトリ) のリストが表示されます。-d を指定すると、クライアントがリモートにマウントしたディレクトリのリストが表示されます。-e では、共有 (またはエクスポート) しているファイルのリストが表示されます。hostname には、表示する情報が保存されているNFSサーバを指定します。hostname を指定しないと、ローカルホストを入力するように要求されます。

showmount コマンドの使用

以下のコマンドでは、すべてのクライアント、およびマウントしたディレクトリが表示されます。


# showmount -a bee
lilac:/export/share/man
lilac:/usr/src
rose:/usr/src
tulip:/export/share/man

以下のコマンドでは、マウントしたディレクトリが表示されます。


# showmount -d bee
/export/share/man
/usr/src

以下のコマンドでは、共有しているファイルシステムが表示されます。


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

setmnt

このコマンドを使用すると、/etc/mnttab テーブルが作成されます。このテーブルは、mount コマンドと umount コマンドで参照されます。通常、このコマンドを使用することはありません。システムがブートされるときに自動的に使用されます。

その他のコマンド

NFS の障害追跡には以下のコマンドを使用します。

nfsstat

このコマンドを使用すると、NFS と RPC 接続について統計情報を収集できます。構文は次のとおりです。

nfsstat [ -cmnrsz ]

-c を指定すると、クライアント側の情報が表示され、-m を指定すると、マウントした各 NFS ファイルシステムの統計が表示されます。-n では、クライアントとサーバの両方の NFS 情報が表示され、-r では、RPC の統計が表示されます。-s を指定すると、サーバ側の情報が表示され、-z を指定すると、統計がゼロに設定されます。コマンド行にオプションを指定しないと、-cnrs が使用されます。

新しいソフトウェアやハードウェアを処理環境に追加した場合、サーバ側の統計を収集することが、デバッグにたいへん役立ちます。このコマンドを週に最低 1 度は実行し、履歴を作成するようにしてください。統計を保存しておくと、以前の効率のよい記録になります。

nfsstat コマンドの使用

# nfsstat -s
 
Server rpc:
Connection oriented:
calls      badcalls   nullrecv   badlen      xdrcall    dupchecks  dupreqs
11420263   0          0          0           0          1428274    19
Connectionless:
calls      badcalls   nullrecv   badlen      xdrcall    dupchecks  dupreqs
14569706   0          0          0           0          953332     1601
 
Server nfs:
calls      badcalls
24234967   226
Version 2: (13073528 calls)
null       getattr    setattr    root        lookup     readlink   read
138612 1%  1192059 9% 45676 0%   0 0%        9300029 71% 9872 0%   1319897 10%
wrcache    write      create     remove      rename     link       symlink
0 0%       805444 6%  43417 0%   44951 0%    3831 0%    4758 0%    1490 0%
mkdir      rmdir      readdir    statfs
2235 0%    1518 0%    51897 0%   107842 0%
Version 3: (11114810 calls)
null       getattr    setattr    lookup      access     readlink   read
141059 1%  3911728 35% 181185 1% 3395029 30% 1097018 9% 4777 0%   960503 8%
write      create     mkdir      symlink     mknod      remove     rmdir
763996 6%  159257 1%  3997 0%    10532 0%    26 0%      164698 1%  2251 0%
rename     link       readdir    readdirplus fsstat     fsinfo     pathconf
53303 0%   9500 0%    62022 0%   79512 0%    3442 0%    34275 0%   3023 0%
commit    
73677 0% 
 
Server nfs_acl:
Version 2: (1579 calls)
null       getacl     setacl     getattr     access
0 0%       3 0%       0 0%       1000 63%    576 36%
Version 3: (45318 calls)
null       getacl     setacl
0 0%       45318 100% 0 0%

上記は、NFS サーバの統計です。最初の 5 行は RPC に関するもので、残りの部分は NFS のアクティビティのレポートです。どちらの統計でも総コール数に対する badcallsi の数や 1 週間あたりの calls 数がわかるので、障害が発生した時点を突き止めのに役立ちます。badcallsiの値は、クライアントからの不良メッセージの数を表すもので、ネットワーク上のハードウェアにおける問題を突き止められます。

いくつかの接続では、ディスクに対する書き込みアクティビティが発生します。この数値の急激な上昇は障害の可能性を示すものなので、調査が必要です。NFS バージョン 2 の場合、特に注意しなければならない接続は、 setattr、write、create、remove、rename、link、symlink、mkdir、および rmdir です。 NFS バージョン 3 の場合には、commit の値に特に注意します。ある NFSサーバの commit レベルが、それと同等のサーバと比較して高い場合は、NFS クライアントに十分なメモリがあるかどうかを確認してください。サーバの commit オペレーションの数は、クライアントにリソースがない場合に上昇します。

pstack

このコマンドを使用すると、各プロセスにおけるスタックトレースが表示されます。root で実行しなければなりません。プロセスがハングした場所を判断するのに使用します。使用できるオプションは、チェックするプロセスの PID だけです (proc(1) のマニュアルページ参照)。

以下の例では、実行中の nfsd プロセスをチェックしています。


# /usr/proc/bin/pstack 243
243:    /usr/lib/nfs/nfsd -a 16
 ef675c04 poll     (24d50, 2, ffffffff)
 000115dc ???????? (24000, 132c4, 276d8, 1329c, 276d8, 0)
 00011390 main     (3, efffff14, 0, 0, ffffffff, 400) + 3c8
 00010fb0 _start   (0, 0, 0, 0, 0, 0) + 5c

プロセスが新規の接続要求を待っていることが示されています。これは、正常な反応です。要求が行われた後でもプロセスがポーリングしていることがスタックから分かった場合、そのプロセスはハングしている可能性があります。「NFS サービスの再起動」 の指示に従って問題を解決してください。ハングしたプログラムによって問題が発生しているかどうかを確実に判断するには、「NFS の障害追跡手順」 を参照してください。

rpcinfo

このコマンドは、システムで動作している RPC サービスに関する情報を生成します。RPC サービスの変更にも使用できます。このコマンドには、たくさんのオプションがあります (rpcinfo(1M) のマニュアルページ参照)。以下は、このコマンドで使用できるオプションの概要です。

rpcinfo [ -m | -s ] [ hostname ]

rpcinfo [ -t | -u ] [ hostname ] [ progname ]

-m は rpcbind 操作の統計テーブル、-s は登録済みの RPC プログラムすべての簡易リスト、-t は TCP を使う RPC プログラム、-u は UDP を使う RPC プログラムを表示します。hostname は情報を取得する元のサーバ、progname は情報を収集する対象の RPC プログラムです。hostname を指定しないと、ローカルホスト名が使われます。progname の代わりに RPC プログラム番号が使えますが、ユーザが覚えやすいのは番号よりも名前です。NFS バージョン 3 が実行されていないシステムでは、-s オプションの代わりに -p オプションが使えます。

このコマンドで生成されるデータには、以下のものがあります。

rpcinfo コマンドの使用

以下の例では、サーバで実行している RPC サービスに関する情報を収集しています。生成されたテキストには sort コマンドのフィルタをかけ、より読みやすくしています。この例では、RPC サービスの数行を省略しています。

% rpcinfo -s bee |sort -n
   program version(s) netid(s)                         service     owner
    100000  2,3,4     udp,tcp,ticlts,ticotsord,ticots  portmapper  superuser
    100001  4,3,2     ticlts,udp                       rstatd      superuser
    100002  3,2       ticots,ticotsord,tcp,ticlts,udp  rusersd     superuser
    100003  3,2       tcp,udp                          nfs         superuser
    100005  3,2,1     ticots,ticotsord,tcp,ticlts,udp  mountd      superuser
    100008  1         ticlts,udp                       walld       superuser
    100011  1         ticlts,udp                       rquotad     superuser
    100012  1         ticlts,udp                       sprayd      superuser
    100021  4,3,2,1   ticots,ticotsord,ticlts,tcp,udp  nlockmgr    superuser
    100024  1         ticots,ticotsord,ticlts,tcp,udp  status      superuser
    100026  1         ticots,ticotsord,ticlts,tcp,udp  bootparam   superuser
    100029  2,1       ticots,ticotsord,ticlts          keyserv     superuser
    100068  4,3,2     tcp,udp                          cmsd        superuser
    100078  4         ticots,ticotsord,ticlts          kerbd       superuser
    100083  1         tcp,udp                          -           superuser
    100087  11        udp                              adm_agent   superuser
    100088  1         udp,tcp                          -           superuser
    100089  1         tcp                              -           superuser
    100099  1         ticots,ticotsord,ticlts          pld         superuser
    100101  10        tcp,udp                          event       superuser
    100104  10        udp                              sync        superuser
    100105  10        udp                              diskinfo    superuser
    100107  10        udp                              hostperf    superuser
    100109  10        udp                              activity    superuser
	.
	.
    100227  3,2       tcp,udp                          -           superuser
    100301  1         ticlts                           niscachemgr superuser
    390100  3         udp                              -           superuser
1342177279  1,2       tcp                              -           14072

次の例では、サーバの特定トランスポートを使用している RPC サービスの情報を収集する方法について説明しています。


% rpcinfo -t bee mountd
program 100005 version 1 ready and waiting
program 100005 version 2 ready and waiting
program 100005 version 3 ready and waiting
% rpcinfo -u bee nfs
program 100003 version 2 ready and waiting
program 100003 version 3 ready and waiting

最初の例では、TCP で実行している mountd サービスをチェックしています。2 番目の例では、UDP で実行している NFS サービスをチェックしています。

snoop

このコマンドは、ネットワーク上のパケットの監視によく使用されます。root として実行しなければなりません。クライアントとサーバの両方で、ネットワークハードウェアが機能しているかどうかを確認する方法としてよく使用されます。使用できるオプションは多数あります (snoop(1M) のマニュアルページ参照)。以下で、このコマンドの概要を説明します。

snoop [ -d device ] [ -o filename ] [ host hostname ]

-d device には、ローカルネットワークインタフェースを指定します。-o filename には、取り込んだすべてのパケットを保存するファイルを指定します。hostname には、表示するパケットが通過したホストを指定します。

-d device オプションは、複数のネットワークインタフェースがあるサーバで特に有効です。ホストの設定以外にも、使用できる式が多数あります。コマンド式を grep で組み合わせることでも、十分に使用できるデータを生成できます。

障害追跡をする場合は、パケットの発信元と送信先のホストが正しいことを確認してください。また、エラーメッセージも調べてください。パケットをファイルに保存すると、データの検査が容易になります。

truss

このコマンドを使用すると、プロセスがハングしたかどうかを確認できます。root で実行しなければなりません。このコマンドに指定できるオプションは多数あります (truss(1) のマニュアルページ参照)。構文の概要は以下のとおりです。

truss [ -t syscall ] -p pid

-t syscall には、追跡するシステムコールを指定します。-p pid には、追跡するプロセスの PID を指定します。syscall には、追跡するシステムコールをカンマで区切って指定することもできます。また、syscall の指定を ! で始めると、そのシステムコールは追跡されなくなります。

次の例は、プロセスが新しいクライアントからの接続要求を待っていることを示しています。 


# /usr/bin/truss -p 243
poll(0x00024D50, 2, -1)         (sleeping...)

これは正常な反応です。新規接続の要求が行われた後でも反応が変わらない場合、そのプロセスはハングしている可能性があります。「NFS サービスの再起動」 の指示に従ってプログラムを修正してください。ハングしたプログラムによって問題が発生しているかどうかを確実に判断するには、「NFS の障害追跡手順」 を参照してください。

コマンドを組み合わせて使う

以下の節では、NFS の複雑な機能をいくつか紹介します。

バージョン 2 とバージョン 3 のネゴシエーション

NFS サーバがサポートしているクライアントが NFS バージョン 3 を使っていない場合に備えて、開始手順にはプロトコルレベルのネゴシエーションが含まれています。クライアントとサーバの両方がバージョン 3 をサポートしていると、バージョン 3 が使われます。どちらか片方でもバージョン 2 しかサポートしていないと、バージョン 2 が使われます。

ネゴシエーションによって決まった値は、mount コマンドに対して -vers オプションを使うことで変更できます (マニュアルページの mount_nfs(1M) を参照してください)。ほとんどの場合、デフォルトによって最適なバージョンが選択されるため、ユーザが指定する必要はありません。

UDP と TCP のネゴシエーション

開始時には、トランスポートプロトコルもネゴシエーションされます。デフォルトでは、クライアントとサーバの両方がサポートしているコネクション型トランスポートの中で最初に見つかったものが選択されます。それが見つからない場合には、コネクションレス型トランスポートプロトコルの中で最初に見つかったものが使われます。システムでサポートされているトランスポートプロトコルのリストは、/etc/netconfig にあります。TCP はコネクション型トランスポートプロトコルで、Solaris 2.6 でサポートされています。UDP はコネクションレス型トランスポートプロトコルです。

NFS プロトコルのバージョンとトランスポートプロトコルが両方ともネゴシエーションによって決まった場合は、NFS プロトコルのバージョンがトランスポートプロトコルよりも優先されます。UDP を使う NFS バージョン 3 プロトコルの方が、TCP を使う NFS バージョン 2 プロトコルよりも優先されます。mount コマンドでは NFS プロトコルのバージョンもトランスポートプロトコルも手動で選択できます (マニュアルページの mount_nfs(1M) を参照してください)。ほとんどの場合、ネゴシエーションによって選択されるオプションの方が適切です。

ファイル転送サイズのネゴシエーション

ファイル転送サイズは、クライアントとサーバの間でデータを転送するときに使われるバッファのサイズです。原則として、ファイル転送サイズが大きいほどパフォーマンスが向上します。NFS バージョン 3 には転送サイズに上限はありませんが、Solaris 2.6 以降がデフォルトで提示するバッファサイズは 32 キロバイトです。クライアントは、必要であればマウント時にこれより小さい転送サイズを提示することができますが、ほとんどの場合必要ありません。

転送サイズは、NFS バージョン 2 を使っているシステムとはネゴシエーションされません。このとき、ファイル転送サイズの上限は 8 キロバイトに設定されます。

mount コマンドに対して -rsize オプションと -wsize オプションを使うと、転送サイズを手動で設定できます。PC クライアントの一部では転送サイズを小さくする必要があります。また、NFS サーバが大きなファイル転送サイズに設定されている場合には、転送サイズを大きくすることができます。

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

クライアントがサーバからファイルシステムをマウントするとき、そのファイルシステムに対応するファイルハンドルをサーバから取得する必要があります。そのためには、クライアントとサーバの間でいくつかのトランザクションが発生します。この例では、クライアントはサーバから /home/terry をマウントします。snoop によって追跡したトランザクションは、次のとおりです。 


client -> server PORTMAP C GETPORT prog=100005 (MOUNT) vers=3 proto=UDP
server -> client PORTMAP R GETPORT port=33492
client -> server MOUNT3 C Null
server -> client MOUNT3 R Null
client -> server MOUNT3 C Mount /export/home9/terry
server -> client MOUNT3 R Mount OK FH=9000 Auth=unix
client -> server PORTMAP C GETPORT prog=100003 (NFS) vers=3 proto=TCP
server -> client PORTMAP R GETPORT port=2049
client -> server NFS C NULL3
server -> client NFS R NULL3
client -> server NFS C FSINFO3 FH=9000
server -> client NFS R FSINFO3 OK
client -> server NFS C GETATTR3 FH=9000
server -> client NFS R GETATTR3 OK

この追跡結果では、クライアントがまずマウントポート番号を NFS サーバの portmap サービスに要求します。クライアントが取得したマウントポート番号 (33492) は、サーバに対する存在確認のために使用されます。このポート番号でサービスが実行中であることが確認できると、クライアントはマウントを要求します。この要求により、サーバはマウントされるファイルシステムに対するファイルハンドル (9000) を送ります。これに対してクライアントは、NFS ポート番号を要求します。クライアントはサーバからポート番号を受け取り、NFS サービス (nfsd) を ping してから、ファイルハンドルを使用してファイルシステムに関する NFS 情報を要求します。

次の追跡結果では、クライアントは -public オプションを使用してファイルシステムをマウントしています。 


client -> server NFS C LOOKUP3 FH=0000 /export/home9/terry
server -> client NFS R LOOKUP3 OK FH=9000
client -> server NFS C FSINFO3 FH=9000
server -> client NFS R FSINFO3 OK
client -> server NFS C GETATTR3 FH=9000
server -> client NFS R GETATTR3 OK

デフォルトの公共ファイルハンドル (0000) を使用しているために、すべてのトランザクションにポートマップサービスから情報が与えられ、NFS ポート番号を決定するためのトランザクションはありません。

マウント時の -public オプションと NFS URL の意味

-public オプションを使用すると、マウントが失敗することがあります。NFS URL を組み合わせると、状況がさらに複雑になる可能性があります。これらのオプションを使用した場合にファイルシステムがどのようにマウントされるかは、次のとおりです。

クライアント側障害時回避機能

クライアント側障害時回避機能を使うと、複製されたファイルシステムをサポートしているサーバが使用不能になったときに、NFS クライアントは別のサーバに切り替えることができます。ファイルシステムが使用不能になる原因としては、接続しているサーバのクラッシュ、サーバの過負荷、ネットワーク障害が考えられます。通常、このような場合の障害時回避機能はユーザには分かりません。設定が行われていれば、障害時回避機能はクライアント上のプロセスを中断することなく実行されます。

障害時回避機能が行われるためには、ファイルシステムが読み取り専用でマウントされている必要があります。また、ファイルシステムが完全に同じでないと障害時回避機能は成功しません。ファイルシステムが同一になる条件については、「複製されたファイルシステムとは」 を参照してください。障害時回避機能の候補としては、静的なファイルシステム、または変更の少ないファイルシステムが適しています。

CacheFS を使ってマウントされたファイルシステムは、障害時回避機能には使えません。CacheFS ファイルシステムは、それぞれについて追加情報が格納されています。この情報は障害時回避の際に更新できないため、ファイルシステムをマウントするときには障害時回避機能と CasheFS のどちらか片方の機能しか使えません。

各ファイルシステムについて用意すべき複製の数を決める要素はさまざまです。一般的に、サーバを何台か用意してそれぞれが複数のサブネットをサポートするという環境の方が、サブネット 1 つについて 1 台のサーバを用意するよりもすぐれています。この場合、リストにあるサーバを 1 台ずつチェックする必要があるため、リスト上のサーバが増えるにつれてマウントにかかる時間も増えます。

障害時回避機能に関する用語

障害時回避機能のプロセスを完全に理解するには、以下の 2 つの用語を理解しておく必要があります。

複製されたファイルシステムとは

障害時回避機能に関して、あるファイルシステムのすべてのファイルが元のファイルシステムのファイルとサイズも vnode タイプも同じ場合に、そのファイルシステムを「複製」といいます。アクセス権、作成日付などのファイル属性は関係ありません。ファイルサイズか vnode タイプが異なると再マッピングは失敗し、元のサーバが再び使用可能になるまでプロセスはハングします。

複製されたファイルシステムを保守するには、rdist や cpio などのファイル転送機構を使います。複製されたファイルシステムを更新すると不整合が発生するので、できるだけ以下を守ってください。

障害時回避機能と NFS ロック

ソフトウェアパッケージの一部は、ファイルに読み取りロックをかける必要があります。そのようなソフトウェアが正常に動作できるようにするため、読み取り専用ファイルシステムに対しても読み取りロックがかけられるようになっています。ただし、これはクライアント側でしか認識されません。サーバ側で意識されないため、再マッピングされてもロックはそのまま残ります。ファイルはもともと変更が許されないので、サーバ側でファイルをロックする必要はありません。

大型ファイル

Solaris 2.6 およびその互換バージョンでは、2 ギガバイトを超えるファイルを扱えます。デフォルトでは、UFS ファイルシステムはこの新機能を活かすために -largefiles オプション付きでマウントされます。以前のリリースでは、2 ギガバイトを超えるファイルは扱えません。具体的な方法については 「NFS サーバ上の大型ファイルを無効にする方法」 を参照してください。

サーバのファイルシステムが -largefiles オプション付きでマウントされていれば、Solaris 2.6 の NFS クライアントでは何も変更しなくても大型ファイルにアクセスできます。しかし、Solaris 2.6 のコマンドすべてで大型ファイルが扱えるわけではありません。大型ファイルを処理可能なコマンドのリストは、largefile(5) を参照してください。大型ファイル用機能拡張を備えた NFS バージョン 3 プロトコルをサポートしていないクライアントは、大型ファイルには一切アクセスできません。Solaris 2.5 クライアントでは、NFS バージョン 3 プロトコルを使うことはできますが、大型ファイルを扱う機能は含まれていません。

WebNFS サービスの動作方法

WebNFS サービスとは、あるディレクトリに置かれたファイルを、公開ファイルハンドルを使ってクライアントからアクセスできるようにするものです。ファイルハンドルは、NFS クライアントがファイルを識別できるようにカーネルが生成するアドレスです。公開ファイルハンドル の値はあらかじめ決まっているため、サーバがクライアントに対してファイルハンドルを生成する必要はありません。定義済みのファイルハンドルを使用するというこの機能によって、MOUNT プロトコルが不要になってネットワークトラフィックが減り、クライアントにとってはパフォーマンスが向上します。

デフォルトでは、NFS サーバの公開ファイルハンドルはルートファイルシステムに対して設定されます。このデフォルトのため、サーバに対してマウント権限を持っているすべてのクライアントに対して WebNFS アクセス権が与えられます。公開ファイルハンドルは、share コマンドによって任意のファイルシステムに切り替えることができます。

あるファイルシステムに対するファイルハンドルをクライアントが持っているとき、アクセスするファイルに対応するファイルハンドルを知るには LOOKUP を実行します。 NFS プロトコルでは、パス名の構成要素を 1 度に 1 つしか評価できません。したがって、ディレクトリ階層のレベルが 1 つ増えるたびに 1 回ずつ LOOKUP を実行します。公開ファイルハンドルからの相対パスに対して LOOKUP を実行する場合には、WebNFS サーバは複数構成要素参照という方法によって 1 度にパス名全体を評価できます。複数構成要素参照を使うことにより、WebNFS サーバはパス名の中のディレクトリレベルを 1 つずつファイルハンドルに変換しなくても目的のファイルに対するファイルハンドルを取得できます。

また、NFS クライアントは単一の TCP 接続上で同時に複数のダウンロードを行うこともできます。これにより、複数の接続を設定することによる余分な負荷をサーバにかけずに、高速なアクセスが実現できます。Web ブラウザアプリケーションも複数ファイルを同時にダウンロードできますが、それぞれのファイルに独自の接続が確立されます。WebNFS ソフトウェアは接続を 1 つしか使わないため、サーバに対するオーバーヘッドを軽減できます。

パス名の中の最後の構成要素が他のファイルシステムに対するシンボリックリンクである場合、通常の NFS アクティビティによってあらかじめそのファイルへのアクセス権を持っていれば、クライアントはそのファイルにアクセスできます。

通常、NFS URL は公開ファイルハンドルからの相対位置として評価されます。パスの先頭にスラッシュを 1 つ追加すると、サーバのルートファイルシステムからの相対位置に変更できます。次の例では、公開ファイルハンドルが /export/ftp ファイルシステムに設定されていればこの 2 つの NFS URL は同等です。


nfs://server/junk
nfs://server//export/ftp/junk

Web ブラウザと比較した場合の WebNFS の制約

HTTP を使う Web サイトで実現可能な機能のいくつかは、WebNFS ではサポートされていません。この違いは、NFS サーバはファイルを送るだけであるため、特別な処理はすべてクライアントで行う必要があることが原因です。ある Web サイトを WebNFS と HTTP 両方のアクセスに対応させるには、以下を考慮してください。

Secure NFS システム

NFS 環境は、アーキテクチャやオペレーティングシステムの異なるコンピュータから構成されるネットワーク上でファイルシステムを共有するためには、強力で使いやすい手段です。しかし、NFS の操作によるファイルシステムの共有を便利にする機能が、一方ではセキュリティ上の問題につながっています。今まで、NFS はほとんどのバージョンで UNIX (AUTH_SYS) 認証を使ってきましたが、現在では AUTH_DH のようなより強力な認証方式も使用可能です。UNIX 認証の場合、NFS サーバはファイル要求を認証するために、その要求を行ったユーザではなくコンピュータを認証します。したがって、クライアント側のユーザがスーパーユーザでログインすると、ファイルの所有者になりすますことができます。DH 認証では、NFS サーバはユーザを認証するため、この様な操作が困難になります。

ルートへのアクセス権とネットワークプログラミングについての知識があれば、だれでも任意のデータをネットワークに入れ、ネットワークから任意のデータを取り出すことができます。ネットワークに対する最も危険な攻撃は、有効なパケットを生成したり、または "対話" 対話を記録し後で再生することによってユーザを装うなどの手段により、データをネットワークに持ち込むことです。これらはデータの整合性に影響を与えます。許可を持つユーザを装うことなく、単にネットワークトラフィックを受信するだけの受動的な盗み聞きならば、データの整合性が損なわれることはないため、それほど危険ではありません。ユーザはネットワークに送信されるデータを暗号化することによって、機密情報のプライバシーを守ることができます。

ネットワークのセキュリティ問題における共通の対処方法は、解決策を各アプリケーションにゆだねることです。さらに優れた手法としては、すべてのアプリケーションを対象として、標準の認証システムを導入することです。

Solaris オペレーティングシステムには、NFS が実装されるメカニズムである遠隔手続き呼び出し (RPC) のレベルで、認証システムが組み込まれています。このシステムは Secure RPC と呼ばれ、ネットワーク環境のセキュリティを大幅に向上させるとともに、NFS のセキュリティを強化します。Secure RPC の機能を利用した NFS システムを、Secure NFS システムと呼びます。

Secure RPC

Secure RPC は Secure NFS システムの基本となるメカニズムです。Secure RPC の目標は、少なくともタイムシェアリングシステム (すべてのユーザが 1 台のコンピュータを共有するシステム) 程度に安全なシステムを構築することです。タイムシェアリングシステムはログインパスワードによりユーザを認証します。DES (Data Encryption Service) 認証でもこれは同じです。ユーザは、ローカル端末の場合と同じように、任意のリモートコンピュータにログインできます。ユーザのログインパスワードは、ネットワークセキュリティへのパスポートです。タイムシェアリングでは、システム管理者は信頼のおける人で、パスワードを変更してだれかを装うようなことはしないという道徳上の義務を負います。Secure RPC では、ネットワーク管理者は「公開鍵」を格納するデータベースのエントリを変更しないという前提で信頼されています。

RPC 認証システムを理解するには、「資格 (credential)」と「ベリファイア」という 2 つの用語を理解する必要があります。ID バッジを例にとれば、資格とは、名前、住所、誕生日など人間を識別するものです。ベリファイアとはバッジに添付された写真であり、バッジの写真をその所持者と照合することによって、そのバッジが盗まれたものではないことを確認できます。RPC では、クライアントプロセスは RPC 要求のたびに資格とベリファイアの両方をサーバに送信します。クライアントはサーバの資格をすでに知っているため、サーバはベリファイアだけを送り返します。

RPC の認証機能は拡張が可能で、さまざまな認証システムを組み込むことができます。現在のところ、このようなシステムには UNIX、DH、KERB (Kerberos バージョン 4) の 3 つがあります。

ネットワークサービスで UNIX 認証を使用する場合、資格にはクライアントのコンピュータ名、UID、GID、グループアクセスリストが含まれ、ベリファイアには何も含まれません。ベリファイアが存在しないため、ルートユーザは su などのコマンドを使用して、適切な資格を偽ることができます。UNIX 認証でのもう 1 つの問題は、ネットワーク上のすべてのコンピュータを UNIX コンピュータと想定していることです。UNIX 認証を異機種ネットワーク内のほかのオペレーティングシステムに適用した場合、これは正常に動作しません。

UNIX 認証の欠点を補うために、Secure RPC では DH 認証か KERB 認証を使います。

DH 認証

DH 認証は、Data Encryption Standard (DES) と Diffie-Hellman 公開鍵暗号手法を使用してネットワーク上のユーザとコンピュータの両方を認証します。DES は標準暗号化機能であり、Diffie-Hellman 公開鍵暗号手法は、公開鍵と非公開鍵という 2 つの鍵を使用する暗号方式です。公開鍵と非公開鍵は名前空間に格納されます。NIS の場合、それらの鍵を publickey マップに格納し、NIS+ は cred テーブルに格納します。これらのマップにはすべての認証の候補ユーザの公開鍵と非公開鍵が入っています。マップとテーブルの設定については、『Solaris ネーミングの管理』を参照してください。

DH 認証のセキュリティは、送信側が現在時刻を暗号化する機能に基づいていて、受信側はこれを復号して、自分の時刻と照合します。タイムスタンプは DES を使って暗号化されます。この方式が機能するには次の条件が必要です。

ネットワークが時間同期プログラムを実行する場合、クライアントとサーバ上の時間は自動的に同期されます。時間同期プログラムを使用できない場合、ネットワーク時間ではなく、サーバの時間を使用してタイムスタンプを計算できます。クライアントは、RPC セッションを開始する前にサーバに時間を要求し、自分のクロックとサーバのクロックとの時間差を計算します。タイムスタンプを計算するときには、この差を使用してクライアントのクロックを補正します。サーバがクライアントの要求を拒否するほど、クライアントとサーバのクロック同期がずれた場合、DH 認証システムはサーバとの間で再び同期をとります。

クライアントとサーバは、ランダムな対話鍵 (セッションキーとも呼びます) を生成することによって、同じ暗号化鍵に到達します。次に、公開鍵暗号手法 (公開鍵と秘密鍵を必要とする暗号化方式) を使用して共通鍵を推理します。この共通鍵は、クライアントとサーバだけが推理できる鍵です。対話鍵は、クライアントのタイムスタンプを暗号化および復号化するために使用されます。共通鍵は、この対話鍵を暗号化および復号化するために使用されます。

KERB 認証

Kerberos は MIT で開発された認証方式です。Kerberos での暗号化は DES に基づいています。

Kerberos はユーザのログインパスワードを認証することにより機能します。ユーザは kinit コマンドを入力しますが、このコマンドは、認証サーバからセッション時間 (またはデフォルトセッション時間の 8 時間) の間有効であるチケットを得ます。ユーザがログアウトするときに、このチケットは kdestroy コマンドを使って削除できます。

Kerberos ソフトウェアは、SunOS ソフトウェアの一部ではなく、 MIT の Athena プロジェクトから入手できます。SunOS ソフトウェアは次のソフトウェアを提供します。

詳細については、『Solaris のシステム管理 (第 2 巻)』の「Secure RPC の概要」を参照してください。

NFS での Secure RPC の使用

Secure RPC を使う場合は、以下の点に注意してください。