第 30 章 リモートファイルシステムの管理

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

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

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

• 「NFS サービスの設定」

• 「Secure NFS システムの管理」

• 「WebNFS の管理作業」

• 「autofs 管理作業の概要」

• 「NFS における障害追跡の方法」

• 「NFS における障害追跡の手順」

• 「NFS のエラーメッセージ」

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

• サーバー専用のコンピュータを置く場合、そのコンピュータの決定

• サーバーとクライアントの両方として動作するコンピュータの決定

• クライアントとしてのみ動作するコンピュータの決定

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

• ファイルシステムの共有開始と共有解除

• 管理ファイルを修正し、コンピュータが共有したり、自動的にマウントしたファイルシステムのリストを更新したりすること

• ネットワークの状態のチェック

• NFS に関連した問題の診断と解決

• autofs のマップの設定

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

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

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

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

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

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

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

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

2. 共有する対象の各ファイルシステムに関してエントリを追加します。

   /etc/dfs/dfstab を編集し、自動的に共有したい各ファイルシステムのファイルにエントリを 1 つ追加します。各エントリは、ファイルの 1 行に納める必要があり、次のような構文を使用します。

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

   すべてのオプションを記載したリストについては、share_nfs(1M) のマニュアルページを参照してください。

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

   share コマンド、または share コマンドセットを初めて実行する場合は、NFS デーモンが動作していないことがあります。次のコマンドでデーモンを終了し、再起動してください。

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

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

次の手順

次の手順は、サーバー上で共有化したファイルシステムにクライアントがアクセスできるよう autofs マップを設定する手順です。「autofs 管理作業の概要」を参照してください。

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

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

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

2. WebNFS サービスを使用して、共有する各ファイルシステムのエントリを追加します。

   /etc/dfs/dfstab を編集し、-public オプションを使用して各ファイルシステムについて、エントリを 1 つ追加します。次に示す例の -index タグはオプションです。

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

   すべてのオプションを記載したリストについては、share_nfs(1M) のマニュアルページを参照してください。

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

   share コマンドまたは share コマンドのセットを初めて実行する場合、NFS デーモンが動作していないことがあります。その場合、次のコマンドでデーモンを終了し、デーモンを再起動してください。

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

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

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

   # shareall

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

   share コマンドを実行し、適切なオプションが表示されていることを確認します。

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

NFS サーバーログを有効にする方法

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

2. ファイルシステム構成の設定を変更します (省略可)。

   /etc/nfs/nfslog.conf で、global タグに関連するデータを変更してすべてのファイルシステムについてデフォルトの設定を編集するか、このファイルシステムに新しいタグを追加することができます。これらの変更が必要でない場合には、このファイルを変更する必要はありません。/etc/nfs/nfslog.conf の形式については、nfslog.conf(1) のマニュアルページで説明しています。

3. NFS サーバーログを使用して、共有する各ファイルシステムについてエントリを追加します。

   /etc/dfs/dfstab を編集し、NFS サーバー記録を有効にしたいファイルシステムについてエントリを 1 つ追加します。log=tag オプションと共に使用するタグは、/etc/nfs/nfslog.conf にも記述する必要があります。次の例では、global タグ内のデフォルト設定を使用しています。

   share -F nfs -o ro,log=global /export/ftp

   すべてのオプションを記載したリストについては、share_nfs(1M) のマニュアルページを参照してください。

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

   share コマンドまたは share コマンドセットを初めて実行する場合、NFS デーモンが動作していないことがあります。その場合、次のコマンドでデーモンを終了し、デーモンを再起動してください。

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

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

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

   # shareall

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

   share コマンドを実行し、適切なオプションが表示されていることを確認します。

   # share - /export/share/man ro "" - /usr/src rw=eng "" - /export/ftp ro,log=global ""

7. NFS ログデーモン nfslogd がすでに実行されていなければ、起動します。

   nfs.server スクリプトを使用して NFS デーモンの再起動をすると、nfslog.conf ファイルが存在している場合、デーモンが起動されます。それ以外の場合には、サーバーのリブート時にコマンドが自動的に再起動されるように、一度手動でコマンドを実行してファイルを作成する必要があります。

   # /usr/lib/nfs/nfslogd

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

ファイルシステムをマウントするには、いくつかの方法があります。システムをブートするときに自動的にマウントされるようにするか、コマンド行から必要に応じてマウントするか、オートマウンタを使用します。オートマウンタには、ブート時のマウントやコマンド行からのマウントに比較していくつもの利点がありますが、状況によってこれら 3 つを組み合わせることが必要です。このような 3 つのファイルシステムのマウント方法に加え、ファイルシステムのマウント時に使用するオプションに応じて、プロセスを有効または無効にする方法がいくつかあります。ファイルシステムのマウントに関するすべての作業のリストについては、表 30-2 を参照してください。

ブート時のファイルシステムのマウント方法

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

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

2. ファイルシステムに関するエントリを /etc/vfstab に追加します。

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

special  fsckdev  mountp  fstype  fsckpass  mount-at-boot  mntopts

詳細は、vfstab(4) のマニュアルページを参照してください。

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

vfstab ファイルの項目の例

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

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

コマンド行からファイルシステムをマウントする方法

コマンド行からのファイルシステムのマウントは多くの場合、新しいマウントポイントのテスト、またはオートマウンタを使用しては利用することができないファイルシステムへの一時的なアクセスを許可するために行われます。

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

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

   次のコマンドを入力します。

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

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

   ---

   注意 -

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

   ---

オートマウンタによるマウント

「autofs 管理作業の概要」では、オートマウンタによるマウントの確立とサポートについて詳細に説明します。通常のシステムに変更を加えずに、リモートファイルシステムが /net マウントポイントでアクセスできるようになります。前の例のように /export/share/local ファイルシステムをマウントする場合、次の内容を入力するだけです。

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

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

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

2G バイトを越えるファイルを処理できないクライアントをサポートしているサーバーについては、大型のファイルを作成する機能を無効にしておく必要があります。

以前のバージョンの Solaris による動作環境では、大型のファイルは使用できません。クライアントが大型のファイルにアクセスする必要がある場合には、NFS サーバーのクライアントが 2.6 以降のリリースで動作していることを確認してください。

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

2. ファイルシステム上に大型のファイルが存在していないことを確認してください。

   次の例は、大型のファイルを検索するためのコマンドです。

   # cd /export/home1 # find . -xdev -size +2000000 -exec ls -l {} ¥;

   システム上に大型のファイルが存在する場合には、削除するか、他のファイルシステムに移動する必要があります。

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

   # umount /export/home1

4. ファイルシステムがマウントされている場合には、-largefiles を使用してファイルシステムをリセットします。

   fsck は、ファイルシステム上に大型のファイルが存在しない場合に、ファイルシステムの状態をリセットします。

   # fsck /export/home1

5. nolargefiles を使用して、ファイルシステムをマウントします。

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

   コマンド行からこの操作を行うことができますが、オプションをさらに固定的にするために、/etc/vfstab に次のようなエントリを追加してください。

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

クライアント側フェイルオーバーを使用する方法

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

2. 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. スーパーユーザーになります。

2. /etc/dfs/dfstab にエントリを追加します。

   最初の例では、rose という名称のホストを除き、eng ネットグループ内のすべてのクライアントへのマウントアクセスを許可しています。2 つ目の例では、rose を除き、eng.sun.com DNS ドメイン内にあるすべてのクライアントへのマウントアクセスを許可しています。

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

   アクセスリストに関する補足的な情報については、「share コマンドを使用してアクセスリストを設定する」を参照してください。

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

   /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 オプションを指定すると、必ず公共ファイルハンドルを使用するように指定され、公共ファイルハンドルがサポートされていないとマウントは失敗します。

NFS サービスの設定

この節では、NFS サービスの初期化や使用に必要な作業をいくつか説明します。

NFS サービスの起動方法

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

2. NFS サービスデーモンを有効にします。

   次のコマンドを入力します。

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

   /etc/dfs/dfstab 内にエントリがある場合、このコマンドによりデーモンが起動します。

NFS サービスの停止方法

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

2. NFS サービスデーモンを無効にします。

   次のコマンドを入力します。

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

オートマウンタの起動方法

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

2. autofs デーモンを有効にします。

   次のコマンドを入力します。

   # /etc/init.d/autofs start

   デーモンが起動されます。

オートマウンタの停止方法

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

2. autofs デーモンを無効にします。

   次のコマンドを入力します。

   # /etc/init.d/autofs stop

Secure NFS システムの管理

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

Secure NFS 環境は、認証に Diffie-Hellman (DH) を使用するように設定できます。これらの認証サービスについては、『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 -r を root として実行し、復号化した秘密鍵を /etc/.rootkey に保存しなければなりません。

   ---

   注 -

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

   ---

6. ファイルシステムに対するマウントオプションを更新します。

   /etc/dfs/dfstab ファイルを編集し、任意のエントリ (Diffie-Hellman 認証) に sec=dh オプションを追加します。

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

7. ファイルシステムに対するオートマウンタマップを更新します。

   auto_master データを編集し、任意のエントリ (Diffie-Hellman 認証) 内にマウントオプションとして sec=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

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 の制約」 を参照してください。

NFS URL を使用したブラウズ方法

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

nfs://server<:port>/path

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

ファイアウォール経由で WebNFS アクセスを有効にする方法

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

autofs 管理作業の概要

このセクションでは、ユーザー自身の環境で遭遇する可能性のある最も一般的な作業について説明します。ユーザーのクライアントの必要に最良な形で適合するように autofs を設定するのに役立つ、各シナリオについて推奨される手順も示します。

このセクションで説明される作業を実行するには、Solstice System Management Tools を使用するか、『Solaris ネーミングの管理』を参照してください。

autofs 管理の作業マップ

表 30-5 に、autofs に関連する作業についての説明と参照箇所を示します。

管理作業を含むマップ

表 30-6 は、autofs マップの管理時に認識しておく必要のある事項について示したものです。選択したマップのタイプおよびネームサービスにより、autofs マップへの変更を行うために使用する必要があるメカニズムが異なります。

表 30-6 に、マップのタイプとその使用方法を示します。

表 30-7 は、ネームサービスに基づいて autofs 環境に変更を加える方法を示したものです。

表 30-8 に、マップのタイプについて行なった修正に応じた automount コマンドを実行する場合を示します。たとえば、直接マップに対する追加または削除を行なった場合、ローカルシステム上で automount コマンドを実行し、変更が反映されるようにする必要があります。しかし、既存のエントリを修正した場合は、変更を反映するために、automount コマンドを実行する必要はありません。

マップの修正

次の手順では、NIS+ をネームサービスとして使用している必要があります。

マスターマップの修正方法

1. nistbladm コマンドを使用して、マスターマップへの変更を行います。

   『Solaris ネーミングの管理』を参照してください。

2. 各クライアントで、スーパーユーザーになります。

3. 各クライアントで、automount コマンドを実行し、変更が反映されるようにします。

4. 他のユーザーに変更を通知します。

   他ユーザーがコンピュータ上でスーパーユーザーとして automount コマンドを実行するように、通知が必要になります。

automount コマンドは、実行時にマスターマップからの情報の収集を行います。

間接マップの修正方法

nistbladm コマンドを使用して、間接マップへの変更を行います。

『Solaris ネーミングの管理』を参照してください。

変更はマップを次に使用する時、つまり次回のマウント実行時に反映されます。

直接マップの修正方法

1. nistbladm コマンドを使用して、直接マップに対する変更点の追加または削除を行います。

   『Solaris ネーミングの管理』を参照してください。

2. 手順 1 でマウントポイントエントリの追加または削除を行なった場合には、 automount コマンドを実行します。

3. 変更した点を他のユーザーに通知します。

   他ユーザーがコンピュータ上でスーパーユーザーとして automount コマンドを実行するように、通知が必要になります。

   ---

   注 -

   既存の直接マップエントリの内容に修正または変更だけを行なった場合は、automount コマンドを実行する必要はありません。

   ---

   たとえば、異なるサーバーから /usr/src ディレクトリがマウントされるように auto_direct マップを修正するとします。/usr/src がその時点でマウントされていない場合、/usr/src にアクセスするとすぐにその新しいエントリが反映されます。/usr/src がその時点でマウントされている場合、オートアンマウントが実行されるまで待ちます。そのあと、アクセスが可能になります。

   ---

   注 -

   これらの追加の手順が必要だったり、直接マップほどにはマウントテーブル内のスペースを必要としないので、可能であれば必ず間接マップを使用してください。間接マップは構築が容易であり、コンピュータのファイルシステムへの要求が少なくて済みます。

   ---

マウントポイントの重複回避

/src 上にマウントされたローカルなディスクパーティションがあり、他のソースディレクトリのマウントにもその autofs サービスを使用したい場合、問題が発生する可能性があります。マウントポイント /src を指定する場合、ユーザーがアクセスするたびに、そのサービスが対象のローカルパーティションを隠すことになります。

その場合、そのパーティションはたとえば /export/src などの他の場所にマウントする必要があります。また、/etc/vfstab 内に次のようなエントリが必要になります。

/dev/dsk/d0t3d0s5 /dev/rdsk/c0t3d0s5 /export/src ufs 3 yes - 

このエントリが auto_src にある場合

terra		terra:/export/src 

terra はコンピュータ名です。

非 NFS ファイルシステムへのアクセス

autofs は NFS ファイル以外のファイルもマウントすることができます。autofs は、フロッピーディスクや CD-ROM など、削除可能な媒体上のファイルをマウントします。通常は、Volume Manager を使用して削除可能な媒体上のファイルをマウントすることになります。次の例では、autofs を利用してこのマウントがどのように行われるかを示します。Volume Manager と autofs は同時に動作することができないため、まず Volume Manager を終了してから次に示すエントリを使用する必要があります。

サーバーからファイルシステムのマウントを行う代わりに、ドライブに媒体を配置してマップから参照します。autofs を使用し非 NFS ファイルシステムにアクセスを行いたい場合は、次の手順を参照してください。

autofs で CD-ROM アプリケーションにアクセスする

Volume Manager を使用していない場合に、この手順を行なってください。

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

2. autofs マップを更新します。

   CD-ROM のファイルシステムに対するエントリを追加する場合、次のようになります。

   hsfs -fstype=hsfs,ro :/dev/sr0

   マウントしたい CD-ROM 装置の名前が、コロンのあとに続けて表示されます。

autofs で PC-DOS データフロッピーディスクにアクセスする方法

Volume Mananger を使用していない場合に、この手順を行なってください。

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

2. autofs マップを更新します。

   ファイルシステムに対するエントリを追加する場合、次のようになります。

   pcfs -fstype=pcfs :/dev/diskette

CasheFS を使用して NFS ファイルシステムにアクセスする

キャッシュファイルシステム (CacheFS) は、汎用不揮発性キャッシュメカニズムで、小型で高速ローカルディスクを利用して、特定のファイルシステムの性能を向上させます。

CacheFS を使用してローカルディスク上に NFS ファイルシステムからデータをキャッシュすることにより、NFS 環境の性能が改善できます。

CasheFS を使用して NFS ファイルシステムにアクセスする方法

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

2. cfsadmin コマンドを実行して、ローカルディスク上にキャッシュディレクトリを作成します。

   # cfsadmin -c /var/cache

3. 任意のオートマウンタマップに cachefs エントリを追加します。

   たとえば、次に示すエントリをマスターマップに追加して、すべてのディレクトリがキャッシュされます。

   /home auto_home -fstype=cachefs,cachedir=/var/cache,backfstype=nfs

   以下のエントリを auto_home マップに追加すると、rich という名称のユーザーのホームディレクトリのキャッシュだけが行われます。

   rich -fstype=cachefs,cachedir=/var/cache,backfstype=nfs dragon:/export/home1/rich

   ---

   注 -

   あとから検索されるマップ内のオプションは、先に検索されたマップ内のオプションを無効にします。そのため、最後に検出されたオプションが使用されます。前の例では、マスターマップにリストされたオプションの中に変更の必要がある場合には、auto_home マップに追加された特定のエントリがそのマスターマップのオプションを含む必要だけがあります。

   ---

オートマウンタのカスタマイズ

オートマウンタマップの設定方法はいくつかあります。次の作業説明で、オートマウンタマップをカスタマイズして簡単に使用できるディレクトリ構造を実現する方法について詳細な手順を示します。

/home の共通表示の設定

ネットワークユーザーすべてにとって理想的なのは、自分自身のホームディレクトリ、または他の人のホームディレクトリを /home の下に配置できるようにすることです。この表示方法は通常、クライアントでもサーバーでも、すべてのコンピュータを通じて共通です。

Solaris のインストールはそれぞれ、マスターマップ /etc/auto_master を使用して行われます

# Master map for autofs
#
+auto_master
/net     -hosts     -nosuid,nobrowse
/home    auto_home  -nobrowse
/xfn     -xfn

auto_home 用のマップも、/etc の下にインストールされます。

# Home directory map for autofs
#
+auto_home

外部 auto_home マップに対する参照を除き、このマップは空になります。/home 下のディレクトリをすべてのコンピュータに対して共通にする場合、この /etc/auto_home マップは修正しないでください。すべてのホームディレクトリのエントリは、NIS または NIS+ のネームサービスファイルで表示されなくてはなりません。

ユーザーは、各ホームディレクトリから setuid 実行可能ファイルを実行することが許可されていません。この制限がないと、すべてのユーザーがすべてのコンピュータ上でスーパーユーザーの権限を持つことになります。

複数のホームディレクトリファイルシステムで /home を設定する方法

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

2. /export/home の下にホームディレクトリパーティションをインストールします。

   複数のパーティションがある場合には、/export/home1、/export/home2 のように、別のディレクトリにそれぞれインストールを行います。

3. auto_home マップを作成して維持するため、Solstice System Management Tools を使用します。

   新しいユーザーアカウントを作成する場合には、そのユーザーのホームディレクトリの位置を auto_home マップに入力します。マップのエントリは、次のように単純な形式にできます。

   rusty dragon:/export/home1/& gwenda dragon:/export/home1/& charles sundog:/export/home2/& rich dragon:/export/home3/&

   マップキーの代用する & (アンパサンド) の使い方に注意してください。これは、次の例での、2 つ目の rusty の使用を省略した形式です。

   rusty dragon:/export/home1/rusty

   auto_home マップが適切に配置されている場合、ユーザーは /home/user パスを使用して、ユーザー自身のホームディレクトリを含むすべてのホームディレクトリが参照できます。user がログイン名であり、マップ内でのキーです。すべてのホームディレクトリを共通に表示する仕組みは、他ユーザーのコンピュータにログインする場合に便利です。autofs は、ユーザー自身のホームディレクトリをマウントします。同様に、他のコンピュータ上でリモートウィンドウシステムのクライアントを動作させる場合、クライアントプログラムは、ウィンドウシステム表示を提供するコンピュータと同じ /home ディレクトリを表示します。

   この共通表示は、サーバーにも拡張されています。前の例を使用すれば、rusty がサーバー dragon にログインする場合、autofs は、/export/home1/rusty を /home/rusty にループバックマウントすることにより、ローカルディスクへの直接アクセスを提供します。

   ユーザーは、各ホームディレクトリの実際の位置を意識する必要はありません。rusty がさらにディスクスペースを必要とし、rusty 自身のホームディレクトリを他のサーバーに再配置する必要がある場合には、auto_home マップ内の rusty のエントリを新しい位置を反映するように変更することだけが必要になります。すべてのユーザーは、/home/rusty パスを継続して使用することができます。

/ws 下のプロジェクト関連ファイルを統合する方法

大きなソフトウェアの開発プロジェクトの管理者を想定してください。そこで、プロジェクト関連のファイルをすべて /ws というディレクトリの下で利用できるようにしたいと仮定します。このようなディレクトリは、そのサイトのすべてのワークステーションで共通である必要があります。

1. /ws ディレクトリに対するエントリを、サイトの NIS または NIS+ の auto_master マップに追加します。

   /ws auto_ws -nosuid

   auto_ws マップが、/ws ディレクトリの内容を決定します。

2. -nosuid オプションを用心のために追加しておきます。

   このオプションは、すべての作業空間に存在する可能性のある setuid プログラムをユーザーが動作できないようにします。

3. auto_ws マップにエントリを追加します。

   auto_ws マップは、各エントリがサブプロジェクトを記述するように構成されています。最初の操作により、マップが次のようになります。

   compiler alpha:/export/ws/& windows alpha:/export/ws/& files bravo:/export/ws/& drivers alpha:/export/ws/& man bravo:/export/ws/& tools delta:/export/ws/&

   各エントリの最後のアンパサンド (&) は、エントリキーを省略したものです。たとえば、最初のエントリは次のエントリと同じ意味です。

   compiler alpha:/export/ws/compiler

   この最初の操作によりマップは単純に見えるようになりますが、不適切な場合もあります。プロジェクトの調整者が、man エントリ内のドキュメントが各サブプロジェクトの下のサブディレクトリとして提供されるべきである見なすとします。さらに、各サブプロジェクトは、ソフトウェアの複数のバージョンを記述するために、複数のサブディレクトリを必要とします。この場合、サーバー上のディスクパーティション全体に対して、これらのサブディレクトリをそれぞれ割り当てる必要があります。

   次のように、マップ内のエントリを修正してください。

   compiler ¥ /vers1.0 alpha:/export/ws/&/vers1.0 ¥ /vers2.0 bravo:/export/ws/&/vers2.0 ¥ /man bravo:/export/ws/&/man windows ¥ /vers1.0 alpha:/export/ws/&/vers1.0 ¥ /man bravo:/export/ws/&/man files ¥ /vers1.0 alpha:/export/ws/&/vers1.0 ¥ /vers2.0 bravo:/export/ws/&/vers2.0 ¥ /vers3.0 bravo:/export/ws/&/vers3.0 ¥ /man bravo:/export/ws/&/man drivers ¥ /vers1.0 alpha:/export/ws/&/vers1.0 ¥ /man bravo:/export/ws/&/man tools ¥ / delta:/export/ws/&

   現在のマップはかなり長くなっていますが、まだ 5 つのエントリを含んでいるだけです。各エントリは、複数のマウントがあるために長くなっています。たとえば、/ws/compiler に対する参照は、vers1.0、vers2.0、および man ディレクトリ用に 3 つのマウントを必要とします。各行の最後のバックスラッシュは、エントリが次の行まで続いていることを autofs に伝えるものです。実際、エントリは 1 つの長い行となっていますが、行ブレークやインデントのいくつかはエントリを読みやすくする目的で使用されています。tools ディレクトリには、すべてのサブプロジェクトに対するソフトウェア開発ツールが含まれているため、同じサブディレクトリ構造の対象とはなっていません。tools ディレクトリは単一のマウントのままです。

   この配置は、システムの管理者に大きな柔軟性を提供します。ソフトウェアプロジェクトでは、非常に大きなディスクスペースを消費します。プロジェクトのすべての過程を通じて、さまざまなディスクパーティションを再配置し、拡張することになる可能性もあります。このような変更が auto_ws マップに反映される限り、/ws 下のディレクトリ階層構造が変更されることもなく、ユーザーに対する通知の必要はありません。

   サーバー alpha と bravo が同一の autofs マップを参照するため、それらのコンピュータにログインするすべてのユーザーは期待通りに /ws 名前空間を発見できます。このようなユーザーには、NFS マウントではなく、ループバックマウントを通じてのローカルファイルへの直接アクセスが提供されます。

共有名前空間にアクセスするために異なるアーキテクチャを設定する方法

表計算ツールやワードプロセッサパッケージのようなローカルな実行可能ファイルやアプリケーションについて、共有名前空間を作成する必要があります。この名前空間のクライアントは、異なる実行可能フォーマットを必要とする複数の異なるワークステーションアーキテクチャを使用します。また、ワークステーションには、異なるリリースのオペレーシングシステムを使用するものもあります。

1. nistabladm コマンドで auto_local マップを作成します。

   『Solaris ネーミングの管理』を参照してください。

2. その名前空間に属するファイルとディレクトリが簡単に識別できるように、共有名前空間について、サイト固有の名称を 1 つ選択します。

   たとえば、その名称として /usr/local を選択した場合、/usr/local/bin パスは明らかにこの名前空間の一部です。

3. ユーザーのコミュニティ識別を簡単にするため、autofs 間接マップを作成し、/usr/local にマウントします。NIS (または NIS+) の auto_master マップ内で、次のエントリを設定します。

   /usr/local auto_local -ro

   なお、-ro マウントオプションは、クライアントがファイルやディレクトリのすべてに対して書き込みができないことを示してます。

4. サーバー上の任意のディレクトリをエクスポートします。

5. auto_local マップ内に bin エントリを 1 つ含めます。

   ディレクトリ構造は次のようになります。

   bin aa:/export/local/bin

   異なるアーキテクチャのクライアントを処理するため、クライアントのアーキテクチャタイプに応じて、その bin ディレクトリへの参照をサーバー上の異なるディレクトリに割り当てる必要があります。

6. 異なるアーキテクチャのクライアントを処理するため、autofs CPU 変数を加えて、エントリの変更を行います。

   bin aa:/export/local/bin/$CPU

   • SPARC クライアント - 実行可能ファイルを /export/local/bin/sparc に配置する

   • IA クライアント - 実行可能ファイルを /export/local/bin/i386 に配置する

非互換のクライアントオペレーティングシステムのバージョンをサポートする方法

1. クライアントのオペレーティングシステムのタイプを決定する変数と、アーキテクチャタイプを結合します。

   CPU タイプと OS リリースの両方を特定する名称を作成するために、autofs OSREL 変数は CPU 変数と結合することができます。

2. 次のようなマップエントリを作成します。

   bin aa:/export/local/bin/$CPU$OSREL

   バージョン 5.6 のオペレーティングシステムを動作させているクライアントについて、次のファイルシステムをエクスポートします。

   • SPARC クライアント - /export/local/bin/sparc5.6 をエクスポートする

   • IA クライアント - /export/local/bin/i3865.6 に実行可能ファイルを配置する

複数のサーバーを通じて共用ファイルを複製する方法

読み取り専用の複製されたファイルシステムを共有する最良の方法は、フェイルオーバーの利用です。フェイルオーバーについての説明は、「クライアント側フェイルオーバー機能」を参照してください。

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

2. autofs マップ内のエントリを修正します。

   すべての複製サーバーのリストを、コンマ区切りのリストとして、次のように作成します。

   bin aa,bb,cc,dd:/export/local/bin/$CPU

   autofs は、最も近いサーバーを選択します。サーバーが複数のネットワークインタフェースを持っている場合は、各インタフェースのリストを作成してください。autofs はクライアントに最も近接したインタフェースを選択し、NFS トラフィックの不必要なルーティングを避けるようにしています。

セキュリティ制限を適用する方法

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

2. NIS または NIS+ のネームサービス auto_master ファイル内に次のようなエントリを作成します。

   /home auto_home -nosuid

   nosuid オプションは、setuid または setgid ビットを設定したファイルをユーザーが作成できないようにします。

   このエントリは、通常のローカルな /etc/auto_master ファイル内の /home に関するエントリを無効にします (前述の例を参照)。これは、ファイル内の /home エントリの前に、+auto_master の外部ネームサービスマップへの参照が生じるためです。auto_home マップ内のエントリがマウントオプションを含む場合、nosuid オプションは無効になります。そのため、オプションを auto_home マップで使用しないか、nosuid オプションを各エントリに含むことになります。

   ---

   注 -

   サーバー上の /home またはその下に、ホームディレクトリのディスクパーティションをマウントしないでください。

   ---

autofs で公共ファイルハンドルを使用する方法

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

2. 次のように、autofs マップ内にエントリを作成します。

   /usr/local -ro,public bee:/export/share/local

   public オプションは、公共ハンドルの使用を強制します。NFS サーバーが公共ファイルハンドルをサポートしない場合、マウントは失敗します。

autofs で NFS URL を使用する方法

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

2. 次のように、autofs エントリを作成します。

   /usr/local -ro nfs://bee/export/share/local

   サービスは、NFS サーバー上で公共ファイルハンドルの使用を試みますが、そのサーバーが公共ファイルハンドルをサポートしない場合、MOUNT プロトコルが使用されます。

autofs のブラウザ機能を無効にする

Solaris 2.6 リリースから使い始めた場合、インストールされる /etc/auto_master のデフォルトバージョンには、/home と /net 用のエントリに追加された -nobrowse オプションが含まれます。さらに、アップグレード手順により、/home と /net のエントリが修正されていない場合には、-nobrowse オプションが それらエントリに追加されます。ただし、このような変更を手動で加えるか、またはインストール後にサイト固有の autofs マウントポイントに対するブラウズ機能をオフにすることが必要な場合もあります。

ブラウズ機能をオフにする方法はいくつかあります。automountd デーモンに対してコマンド行オプションを使用してオフにすると、そのクライアントに対する autofs ブラウザ機能は完全に無効になります。あるいは、NIS または NIS+ 名前空間内の autofs マップを使用してすべてのクライアント上の各マップエントリに対してブラウザ機能をオフにできます。またネットワーク全体に渡る名前空間が使用されていない場合には、ローカルな autofs マップを使用して、各クライアント上の各マップエントリに対してブラウザ機能をオフにできます。

1 つの NFS クライアント上の autofs ブラウズ機能を完全に無効にする方法

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

2. -n オプションを起動クリプトに追加します。

   root として、/etc/init.d/autofs スクリプトを編集し、automountd デーモンを起動する行に -n オプションを追加します。

   /usr/lib/autofs/automountd -n ¥ < /dev/null > /dev/console 2>&1 # start daemon

3. autofs サービスを再起動します。

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

すべてのクライアントの autofs ブラウズ機能を無効にする方法

すべてのクライアントに対するブラウズ機能を無効にするには、NIS または NIS+ のようなネームサービスを使用する必要があります。それ以外の場合には、各クライアント上でオートマウンタマップを手動で編集する必要があります。この例では、/home ディレクトリのブラウズ機能が無効にされています。無効にする必要がある各間接 autofs ノードに対して、この手順を実行してください。

1. ネームサービス auto_master ファイル内の /home エントリに -nobrowse オプションを追加します。

   /home auto_home -nobrowse

2. すべてのクライアント上で、automount コマンドを実行します。

   新規の動作は、クライアントシステム上での automount コマンドを実行したあと、またはリブートのあとで反映されます。

   # /usr/sbin/automount

1 つの NFS クライアントの autofs ブラウズ機能を無効にする方法

この例では、/net ディレクトリのブラウズ機能を無効にします。同じ手順が、/home やその他の autofs マウントポイントに対して使用することができます。

1. automount エントリが /etc/nsswitch.conf にあることを確認します。

   優先するローカルファイルエントリについては、ネームサービススイッチファイル内のエントリがネームサービスの前に files をリストする必要があります。たとえば、次のようになります。

   automount: files nisplus

   これは、標準的な Solaris にインストールされるデフォルトの構成です。

2. /etc/auto_master 内の +auto_master エントリの位置を確認します。

   名前空間内のエントリに優先するローカルファイルへの追加については、+auto_master エントリが /net の下に移動されている必要があります。

   # Master map for automounter # /net -hosts -nosuid /home auto_home /xfn -xfn +auto_master

   標準的な構成では、+auto_master エントリがファイルの先頭に配置されます。これにより、ローカルな変更が使用されなくなります。

3. /etc/auto_master ファイル内の /net エントリに -nobrowse オプションを追加します。

   /net -hosts -nosuid,nobrowse

4. すべてのクライアント上で、automount コマンドを実行します。

   新規の動作は、クライアントシステム上で automount コマンドを実行したあと、またはリブートしたあとで反映されます。

   # /usr/sbin/automount

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 サービスがエラーになった場所を判断するには、いくつかの手順を踏まなければなりません。次の項目をチェックしてください。

• クライアントとサーバーがソフトウェア的に接続されているかどうか

• クライアントが 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. スーパーユーザーになります。

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 サービスを再起動する方法

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

2. リブートせずにデーモンを有効にするために、次のコマンドを入力します。

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

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

rpcbind をウォームスタートする方法

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

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

2. rpcbind の 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

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

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

   # kill -s term 115

   ---

   注 -

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

   ---

4. 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 -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

autofs の障害追跡

autofs の使用時、問題に遭遇することがあります。この節では、問題解決プロセスについてわかりやすく説明します。この節は、2 つの項目に分類されます。

この節では、autofs が生成するエラーメッセージのリストを示します。このリストは、2 つのパートに分かれています。

• automout の詳細形式 (-v) オプションにより生成されるエラーメッセージ

• 通常表示されるエラーメッセージ

各エラーメッセージのあとには、そのメッセージの説明と考えられる原因が続きます。

障害追跡時には、詳細形式 (-v) オプションで autofs プログラムを開始します。そうしないと、理由がわからないまま問題に遭遇することになります。

次の節は、autofs のエラー時に表示されがちなエラーメッセージと、生じうる問題についての説明です。

automount -v により生成されるエラーメッセージ

bad key key in direct map mapname

直接マップのスキャン中、autofs が接頭辞 / のないエントリーキーを発見しました。直接マップ内のキーは、フルパス名でなくてはなりません。

bad key key in indirect map mapname

間接マップのスキャン中、autofs が / を含むエントリキーを発見しました。間接マップのキーは、パス名ではなく、単なる名称でなくてはなりません。

can't mount server:pathname: reason

サーバー上のマウントデーモンが、server:pathname のファイルハンドルの提供を拒みました。サーバー上のエクスポートテーブルを確認してください。

couldn't create mount point mountpoint: reason

autofs は、マウントに必要なマウントポイントを作成することができませんでした。この症状は、すべてのサーバーのエクスポートされたファイルシステムを階層的にマウントしようとする場合に頻繁に生じます。必要なマウントポイントは、マウントできないファイルシステム内にだけ存在し (エクスポートは不可)、エクスポートされる親ファイルシステムは読み取り専用でエクスポートされるため、必要なマウントポイントが作成できないことになります。

leading space in map entry entry text in mapname

autofs はオートマウントマップ内に先頭にスペースを含むエントリを発見しました。通常これは、たとえば次の例のように、適切に継続されていないマップエントリの記述がある場合です。

fake /blat frobz:/usr/frotz

この例では、autofs が 2 つ目の行に遭遇した場合に警告が生成されます。これは、最初の行がバックスラッシュ (¥) で終端されていないためです。

mapname: Not found

必要とされるマップが配置されていません。このメッセージは、-v オプションが使用されている場合にだけ生成されます。マップ名のスペルとパス名を確認してください。

remount server:pathname on mountpoint: server not responding

autofs が、アンマウントしたファイルシステムの再マウントに失敗しました。

WARNING: mountpoint already mounted on

autofs が、既存のマウントポイント上にマウントしようとしました。これは、autofs 内で内部エラー (異常) が生じたことを意味しています。

その他のエラーメッセージ

dir mountpoint must start with '/'

オートマウンタのマウントポイントは、フルパス名で与えられなくてはなりません。マウントポイントのスペルとパス名を確認してください。

hierarchical mountpoints: pathname1 and pathname2

autofs は、マウントポイントが階層的な関係を持つことを許可しません。autofs マウントポイントは、他のオートマウントされたファイルシステムに含まれていてはなりません。

host server not responding

autofs が、server で示されるサーバーにコンタクトしようとしましたが、応答がありません。

hostname: exports: rpc_err

hostname で示される場所からエクスポートリストを得たことを示すエラーです。これは、サーバーまたはネットワークの問題を示します。

map mapname, key key: bad

マップエントリが不適切な形式であり、autofs が処理できません。そのエントリを再確認してください。そのエントリにエスケープする必要のある文字が含まれている可能性があります。

mapname: nis_err

NIS マップ内のエントリの参照におけるエラーです。NIS に問題のある可能性があります。

mount of server:pathname on mountpoint:reason

autofs がマウントに失敗しました。サーバーまたはネットワークに問題のある可能性があります。

mountpoint: Not a directory

autofs は、ディレクトリではない mountpoint に示される場所に自分自身をマウントすることができません。マウントポイントのスペルとパス名を確認してください。

nfscast: cannot send packet: reason

autofs が、複製されたファイルシステムの位置を示すリスト内にあるサーバーへの照会パケットを送信できません。

nfscast: cannot receive reply: reason

autofs が、複製されたファイルシステムの位置を示すリスト内にあるいずれのサーバーからも応答を受けられません。

nfscast: select: reason

このようなエラーメッセージはすべて、複製されたファイルシステムのサーバーの ping に関する問題を示します。ネットワークの問題を示している場合もあります。

pathconf: no info for server:pathname

autofs が、パス名に関する pathconf 情報の取得に失敗しました。 (fpathconf(2) のマニュアルページを参照。)

pathconf: server: server not responding

autofs が、pathconf(2) に情報を提供する server に示されるサーバー上のマウントデーモンにコンタクトできませんでした。

autofs のその他のエラー

/etc/auto* ファイルが実行ビットセットを持っている場合、オートマウンタは次のようなメッセージを生成するマップの実行を試みます。

/etc/auto_home: +auto_home: not found

この場合、auto_home ファイルは不適切な権限をもつことになります。このファイル内の各エントリは、非常によく似たエラーメッセージを生成します。ファイルへのこのような権限は、次のコマンドを入力することにより取り消す必要があります。

# chmod 644 /etc/auto_home

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 クライアントが、2G バイトを超えるサイズのファイルにアクセスしようとしています。

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 オプションの両方にポート番号を指定しても意味がありません。

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