第 5 章 ネットワークファイルシステムの管理 (手順)

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

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

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

• 「NFS サービスの設定」

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

• 「WebNFS の管理作業」

• 「autofs 管理作業の概要」

• 「NFS のトラブルシューティングの方法」

• 「NFS のトラブルシューティングの手順」

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

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

• サーバー専用にするコンピュータの決定

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

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

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

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

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

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

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

• autofs のマップの設定

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

システムでゾーンが有効なときに非大域ゾーンでこの機能を使用するには、『Oracle Solaris のシステム管理 (Oracle Solaris コンテナ : 資源管理と Oracle Solaris ゾーン)』を参照してください。

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

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

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

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

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

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

1. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

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

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

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

   /etc/dfs/dfstab については dfstab(4) のマニュアルページを、オプションの完全な一覧については share_nfs(1M) のマニュアルページを、それぞれ参照してください。

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

   エントリを /etc/dfs/dfstab に追加したあと、システムをリブートするか、shareall コマンドを使用して、ファイルシステムを共有可能にします。

   # shareall

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

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

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

参照

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

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

Solaris 2.6 リリース以降ではデフォルトで、NFS マウントに利用可能なすべてのファイルシステムが、WebNFS アクセス用として自動的に利用可能となります。この手順を使用する必要があるのは、次のいずれかの場合だけです。

• NFS マウントがその時点で利用可能になっていないサーバーで NFS マウントができるようにする場合

• public オプションを使用することで、公開ファイルハンドルをリセットして NFS URL を短くする場合

• index オプションを使用することで、特定の HTML ファイルが強制的に読み込まれるようにする場合

WebNFS サービスを起動する際の注意事項については、「WebNFS アクセスの計画」を参照してください。

1. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

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

   /etc/dfs/dfstab を編集します。各ファイルシステムごとにエントリを 1 つ追加します。次の例の public タグおよび index タグは省略できます。

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

   /etc/dfs/dfstab については dfstab(4) のマニュアルページを、オプションの完全な一覧については share_nfs(1M) のマニュアルページを、それぞれ参照してください。

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

   エントリを /etc/dfs/dfstab に追加したあと、システムをリブートするか、shareall コマンドを使用して、ファイルシステムを共有可能にします。

   # shareall

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

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

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

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

1. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

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

   /etc/nfs/nfslog.conf で設定を変更する方法は 2 つあります。すべてのファイルシステムについてデフォルトの設定を編集するには、global タグに関連するデータを変更します。または、このファイルシステムについて新しいタグを追加します。これらの変更が必要でない場合には、このファイルを変更する必要はありません。/etc/nfs/nfslog.conf の書式については、nfslog.conf(4) のマニュアルページを参照してください。

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

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

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

   /etc/dfs/dfstab については dfstab(4) のマニュアルページを、オプションの完全な一覧については share_nfs(1M) のマニュアルページを、それぞれ参照してください。

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

   エントリを /etc/dfs/dfstab に追加したあと、システムをリブートするか、shareall コマンドを使用して、ファイルシステムを共有可能にします。

   # shareall

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

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

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

6. NFS ログデーモン nfslogd が動作していることを確認します。

   # ps -ef | grep nfslogd

7. (省略可能) 動作していない場合は、nfslogd を起動します。

   • (省略可能) /etc/nfs/nfslogtab が存在している場合は、次のように入力して、NFS ログデーモンを起動します。

     # svcadm restart network/nfs/server:default

   • (省略可能) /etc/nfs/nfslogtab が存在していない場合は、ファイルを作成するために任意の share コマンドを実行してから、デーモンを起動します。

     # shareall # svcadm restart network/nfs/server:default

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

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

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

autofs マップを使用するのではなく、ブート時にファイルシステムをマウントするには、次の手順に従います。リモートファイルシステムにアクセスするクライアントごとに、この手順を行う必要があります。

1. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

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

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

   special  fsckdev  mountp  fstype  fsckpass  mount-at-boot  mntopts

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

   ---

   注意 –

   NFS クライアントの vfstab エントリも持つ NFS サーバーでは、リブート時のハングアップを避けるために、常に bg オプションを指定する必要があります。詳細は、「NFS ファイルシステム用の mount オプション」を参照してください。

   ---

例 5–1 クライアントの vfstab ファイル内のエントリ

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

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

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

新規マウントポイントをテストするために、コマンド行からファイルシステムをマウントすることがあります。このようにしてマウントすると、オートマウンタでアクセスできないファイルシステムに、一時的にアクセスすることができます。

1. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

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

1. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

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. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

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

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

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

   この構文はオートマウンタでも指定できました。しかし、フェイルオーバー機能が使用できるのは単一のサーバーが選択されているときだけで、ファイルシステムがマウントされている間は使用できませんでした。

   ---

   注 –

   異なるバージョンの NFS プロトコルを実行しているサーバーを、コマンド行や vfstab のエントリに混在させないでください。NFS version 2、version 3、または version 4 のプロトコルをサポートしているサーバーを混在して使用できるのは、autofs を使用する場合だけです。autofs では、version 2 、version 3、または version 4 のサーバーの最適なサブセットが使用されます。

   ---

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

1. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

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.example.com /export/share/man

   アクセスリストに関する補足情報については、「share コマンドを使ってアクセスリストを設定する」を参照してください。/etc/dfs/dfstab については、dfstab(4) のマニュアルページを参照してください。

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

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

   # shareall

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

ファイアウォールを越えてファイルシステムにアクセスするには、次の手順を実行します。

1. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

2. 次のコマンドを使用して、ファイルシステムを手動でマウントします。

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

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

   ---

   注 –

   この手順では、NFS サーバーのファイルシステムを public オプションで共有する必要があります。また、クライアントとサーバー間のファイアウォールでは、ポート 2049 で TCP 接続できるようにする必要があります。Solaris 2.6 以降のリリースでは、共有しているすべてのファイルシステムに、公開ファイルハンドルでアクセスできます。そのため、デフォルトでは、public オプションが適用されています。

   ---

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

1. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

2. (省略可能) NFS version 2 または version 3 を使用している場合、次のコマンドを使用して、ファイルシステムを手動でマウントします。

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

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

3. (省略可能) NFS version 4 を使用している場合、次のコマンドを使用して、ファイルシステムを手動でマウントします。

   # mount -F nfs -o vers=4 nfs://bee:3000/export/share/local /mnt

NFS サービスの設定

この節では、次のことを行うために必要な作業を説明します。

• NFS サーバーを起動および停止する

• オートマウンタを起動および停止する

• 異なるバージョンの NFS を選択する

Solaris 10 以降のリリースでは、NFS のデフォルトは version 4 です。

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

1. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

2. サーバー上で NFS サービスを有効にします。

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

   # svcadm enable network/nfs/server

   このコマンドを実行すると、NFS サービスが有効になります。

   ---

   注 –

   Solaris 9 を起動すると、システムのブート時に NFS サーバーは自動的に起動します。さらに、システムのブート以降は、NFS ファイルシステムを共有すると NFS サービスデーモンが自動的に有効になります。「ファイルシステム自動共有を設定する方法」を参照してください。

   ---

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

1. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

2. サーバー上で NFS サービスを無効にします。

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

   # svcadm disable network/nfs/server

オートマウンタを起動する方法

1. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

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

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

   # svcadm enable system/filesystem/autofs

オートマウンタを停止する方法

1. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

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

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

   # svcadm disable system/filesystem/autofs

サーバー上で異なるバージョンの NFS を選択する方法

NFS version 4 を使用しない場合、この手順を使用します。

1. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

2. /etc/default/nfs ファイルを編集します。

   たとえば、サーバーが version 3 だけを使用するようにするには、NFS_SERVER_VERSMAX と NFS_SERVER_VERSMIN の値を 3 に設定します。キーワードとその値の一覧については、「/etc/default/nfs ファイルのキーワード」を参照してください。

   NFS_SERVER_VERSMAX=value NFS_SERVER_VERSMIN=value

   value

   バージョン番号を指定します。

   ---

   注 –

   これらの行は、デフォルトでコメントになっています。ポンド記号 (#) を削除することも忘れないでください。

   ---

3. SMF パラメータを変更して、NFS のバージョン番号を設定します。

   たとえば、サーバーが version 3 だけを使用するようにするには、次のようにして server_vermax と server_versmin の両方を 3 に設定します。

   # sharectl set -p server_vermax=3 nfs # sharectl set -p server_vermin=3 nfs

4. (省略可能) サーバー委託を無効にする場合、/etc/default/nfs ファイルに次の行を追加します。

   NFS_SERVER_DELEGATION=off

   ---

   注 –

   NFS version 4 では、サーバー委託は、デフォルトで有効になっています。詳細は、「NFS version 4 における委託」を参照してください。

   ---

5. (省略可能) クライアントとサーバーの共通ドメインを設定する場合は、/etc/default/nfs ファイルに次の行を追加します。

   NFSMAPID_DOMAIN=my.comany.com

   my.comany.com

   共通ドメインを指定します

   詳細は、「nfsmapid デーモン」を参照してください。

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

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

   # svcs network/nfs/server

   このコマンドは、NFS サーバーサービスがオンラインか、または無効かをレポートします。

7. (省略可能) 必要に応じて、NFS サービスを無効にします。

   NFS サービスがオンラインであることを前の手順で検出した場合、次のコマンドを入力して、サービスを無効にします。

   # svcadm disable network/nfs/server

   ---

   注 –

   NFS サービスを構成する必要がある場合は、「ファイルシステム自動共有を設定する方法」を参照してください。

   ---

8. NFS サービスを有効にします。

   次のコマンドを入力して、サービスを有効にします。

   # svcadm enable network/nfs/server

参照

「NFS におけるバージョンのネゴシエーション」

/etc/default/nfs ファイルを変更することで、クライアント上で異なるバージョンの NFS を選択する方法

次の手順は、/etc/default/nfs ファイルを変更して、クライアント上で使用される NFS のバージョンを制御する方法を示しています。コマンド行を使用する場合は、「コマンド行を使用して、クライアント上で異なるバージョンの NFS を選択する方法」を参照してください。

1. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

2. /etc/default/nfs ファイルを編集します。

   たとえば、クライアント上で version 3 だけを使用するようにするには、NFS_CLIENT_VERSMAX と NFS_CLIENT_VERSMIN の値を 3 に設定します。キーワードとその値の一覧については、「/etc/default/nfs ファイルのキーワード」を参照してください。

   NFS_CLIENT_VERSMAX=value NFS_CLIENT_VERSMIN=value

   value

   バージョン番号を指定します。

   ---

   注 –

   これらの行は、デフォルトでコメントになっています。ポンド記号 (#) を削除することも忘れないでください。

   ---

3. クライアント上で NFS をマウントします。

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

   # mount server-name:/share-point /local-dir

   server-name

   サーバーの名前を指定します。

   /share-point

   共有するリモートディレクトリのパスを指定します。

   /local-dir

   ローカルマウントポイントのパスを指定します。

参照

「NFS におけるバージョンのネゴシエーション」

コマンド行を使用して、クライアント上で異なるバージョンの NFS を選択する方法

次の手順は、コマンド行を使用して、クライアントで特定のマウントに使用される NFS のバージョンを制御する方法を示しています。/etc/default/nfs ファイルを変更する場合は、「/etc/default/nfs ファイルを変更することで、クライアント上で異なるバージョンの NFS を選択する方法」を参照してください。

1. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

2. クライアント上で、目的のバージョンの NFS をマウントします。

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

   # mount -o vers=value server-name:/share-point /local-dir

   value

   バージョン番号を指定します。

   server-name

   サーバーの名前を指定します。

   /share-point

   共有するリモートディレクトリのパスを指定します。

   /local-dir

   ローカルマウントポイントのパスを指定します。

   ---

   注 –

   このコマンドは、NFS プロトコルを使用して、リモートディレクトリをマウントし、/etc/default/nfs ファイルのクライアント設定を上書きします。

   ---

参照

「NFS におけるバージョンのネゴシエーション」

Secure NFS システムの管理

Secure NFS システムを使用するには、関与するすべてのコンピュータにドメイン名が必要です。通常、ドメインとは、複数のコンピュータから構成される管理上のエンティティーのことであり、大規模なネットワークの一部です。ネームサービスを実行している場合、そのドメインに対してネームサービスを設定するようにしてください。『Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)』を参照してください。

NFS サービスでは、Kerberos version 5 認証もサポートされています。Kerberos サービスについては、『Solaris のシステム管理 (セキュリティサービス)』の第 21 章「Kerberos サービスについて」を参照してください。

Secure NFS 環境は、Diffie-Hellman 認証を使用するようにも設定できます。この認証サービスについては、『Solaris のシステム管理 (セキュリティサービス)』の第 16 章「認証サービスの使用 (手順)」を参照してください。

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

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

   NIS+ をネームサービスとして使用している場合は、『Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)』を参照してください。

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

   デーモンが動作していない場合は、次のように入力してキーサーバーを起動します。

   # /usr/sbin/keyserv

5. 秘密鍵の復号化と保存を実行します。

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

   ---

   注 –

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

   ---

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

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

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

   /etc/dfs/dfstab については、dfstab(4) のマニュアルページを参照してください。

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

   auto_master データを編集し、Diffie-Hellman 認証の適切なエントリ内にマウントオプションとして sec=dh を含めます。

   /home auto_home -nosuid,sec=dh

   ---

   注 –

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

   ---

   コンピュータを設置し直したり、移設したり、アップグレードしたりするときに、新しい鍵を設定せず、root 用の鍵も変更しない場合は、必ず /etc/.rootkey を保存してください。/etc/.rootkey を削除するには、通常、次のコマンドを入力します。

   # keylogin -r

WebNFS の管理作業

この節では、WebNFS システムを管理する方法について説明します。次の表に、関連する作業を示します。

WebNFS アクセスの計画

WebNFS を使用するにはまず、nfs://server/path のような NFS URL を実行し、読み込めるアプリケーションが必要です。次に、WebNFS アクセスのためにエクスポートするファイルシステムを選択します。アプリケーションが Web ブラウザの場合は、Web サーバーの文書のルートがよく使用されます。WebNFS アクセスのためにエクスポートするファイルシステムを選択するときは、次の事項を検討する必要があります。

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

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

3. すでに公開されているファイルシステムは、public オプションを使用するのに適しています。たとえば、ftp アーカイブの最上位のディレクトリや Web サイトのメイン URL ディレクトリなどです。

4. share コマンドで index オプションを使用すると、HTML ファイルを強制的に読み込むことができます。そうしない場合は、NFS URL がアクセスされたときにディレクトリが一覧表示されます。

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

   また、NFS と HTTP URL の両方を使用して 1 つの Web サイトにアクセスする場合は、その他の事項も検討する必要があります。これについては、「Web ブラウザの使用と比較した場合の WebNFS の制約」で説明します。

NFS URL を使ってブラウズする方法

ブラウザが WebNFS サービスをサポートしている場合は、次のような NFS URL にアクセスできます。

nfs://server<:port>/path

server

ファイルサーバー名

port

使用するポート番号 (デフォルト値は 2049)

path

公開ファイルハンドルまたはルートファイルシステムに関連するファイルへのパス

ほとんどのブラウザでは、前のトランザクションで使用した URL サービスのタイプ (nfs や http など) を次のトランザクションでも使用できます。ただし、異なるタイプのサービスを含む URL を読み込んだ場合に例外があります。NFS URL を使用したあとに、HTTP URL に対する参照が読み込まれたとします。その場合、次に続くページは NFS プロトコルではなく HTTP プロトコルを使って読み込まれます。

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

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

autofs 管理作業の概要

この節では、ユーザー自身の環境で遭遇する可能性のあるもっとも一般的な作業について説明します。各シナリオについて、ユーザーのクライアントで必要とする条件に最も適合するように autofs を設定するために推奨される手順も示します。この節で説明する作業を実行するには、Solaris 管理コンソールツールを使用するか、『Solaris のシステム管理 (ネーミングとディレクトリサービス : NIS+ 編)』を参照してください。

Solaris 10 以降のリリースでは、/etc/default/autofs ファイルを使用して autofs 環境を設定することもできます。作業の詳細は、「/etc/default/autofs ファイルを使用して autofs 環境を設定する」を参照してください。

autofs 管理の作業マップ

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

/etc/default/autofs ファイルを使用して autofs 環境を設定する

Solaris 10 以降のリリースでは、/etc/default/autofs ファイルを使用して autofs 環境を設定することができます。特に、このファイルにより、autofs コマンドおよび autofs デーモンを設定する方法が追加されました。コマンド行と同じように、この設定ファイルで指定できます。指定するには、キーワードに値を割り当てます。詳細は、「/etc/default/autofs ファイル」を参照してください。

次の手順は、/etc/default/autofs ファイルの使用方法を示しています。

/etc/default/autofs ファイルを使用する方法

1. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

2. /etc/default/autofs ファイル内でエントリを追加または変更します。

   たとえば、すべての autofs マウントポイントの表示をオフに設定するには、次の行を追加します。

   AUTOMOUNTD_NOBROWSE=ON

   このキーワードは、-automountd コマンドの n 引数と同等です。キーワードの一覧については、「/etc/default/autofs ファイル」を参照してください。

3. autofs デーモンを再起動します。

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

   # svcadm restart system/filesystem/autofs

マップの管理作業

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

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

次の表では、使用しているネームサービスごとの、autofs 環境の変更方法を示しています。

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

マップの修正

次の手順は、複数の種類のオートマウンタマップを更新する方法を示します。ネームサービスとして NIS+ を使用する必要があります。

マスターマップを修正する方法

1. マップを変更する権限を持つユーザーとしてログインします。

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

   『Solaris のシステム管理 (ネーミングとディレクトリサービス : NIS+ 編)』を参照してください。

3. 各クライアントで、スーパーユーザーになるか、それと同等の役割になります。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

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

5. マップを変更したことを他のユーザーに通知します。

   他のユーザーがコンピュータ上でスーパーユーザーとして automount コマンドを実行できるように、通知が必要になります。automount コマンドは、実行時にマスターマップから情報を収集することに注意してください。

間接マップを修正する方法

1. マップを変更する権限を持つユーザーとしてログインします。

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

   『Solaris のシステム管理 (ネーミングとディレクトリサービス : NIS+ 編)』を参照してください。変更は、マップを次に使用する時、つまり次回のマウント実行時に反映されることに注意してください。

直接マップを修正する方法

1. マップを変更する権限を持つユーザーとしてログインします。

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

   『Solaris のシステム管理 (ネーミングとディレクトリサービス : NIS+ 編)』を参照してください。

3. マップを変更したことを他のユーザーに通知します。

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

   ---

   注 –

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

   ---

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

   ---

   注 –

   できるだけ間接マップを使用してください。間接マップは構築が容易であり、コンピュータのファイルシステムへの要求が少なくて済みます。また、間接マップは直接マップよりもマウントテーブル内のスペースを必要としません。

   ---

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

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

たとえば /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 アプリケーションにアクセスする方法

ボリュームマネージャーを使用していない場合に、この手順を行なってください。

1. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

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

   次のような CD-ROM のファイルシステム用のエントリを追加します。

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

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

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

ボリュームマネージャーを使用していない場合に、この手順を行なってください。

1. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

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

   次のようなフロッピーディスクのファイルシステム用のエントリを追加します。

   pcfs -fstype=pcfs :/dev/diskette

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

キャッシュファイルシステム (CacheFS) は、汎用不揮発性キャッシュメカニズムで、小型で高速なローカルディスクを利用して、特定のファイルシステムのパフォーマンスを向上させます。たとえば、CacheFS を使用すると、NFS 環境のパフォーマンスを改善できます。

CacheFS は、異なるバージョンの NFS では違った動作をします。たとえば、クライアントとバックファイルシステムで NFS version 2 または version 3 が動作している場合、ファイルはクライアントのアクセス用にフロントファイルシステムにキャッシュされます。ただし、クライアントとサーバーの両方で NFS version 4 が動作している場合は、次のように機能します。クライアントが CacheFS のファイルへのアクセスを初めて要求するとき、要求は、フロント (またはキャッシュされた) ファイルシステムを省略して、バックファイルシステムに直接送られます。NFS version 4 では、ファイルはフロントファイルシステムにキャッシュされなくなりました。すべてのファイルアクセスは、バックファイルシステムから提供されます。また、ファイルはフロントファイルシステムにキャッシュされていないため、フロントファイルシステムに反映する CacheFS 固有のマウントオプションは無視されます。CacheFS 固有のマウントオプションはバックファイルシステムに適用しません。

初めてシステムを NFS version 4 に構成すると、キャッシュが動作しないことを示す警告がコンソールに表示されます。

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

1. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

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

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

# Home directory map for autofs
#
+auto_home

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

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

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

1. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

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

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

3. Solaris 管理コンソールツールを使用して、auto_home マップを作成して維持します。

   新しいユーザーアカウントを作成する場合は、そのユーザーのホームディレクトリの場所を 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 がさらにディスク容量を必要とし、自身のホームディレクトリを他のサーバーに再配置する必要がある場合には、単純な変更で十分です。新しい場所を反映するように 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. auto_local マップを作成します。

   『Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)』を参照してください。

2. 共有名前空間について、サイト固有の名称を 1 つ選択します。

   この名称により、その名前空間に属するファイルとディレクトリが簡単に識別できるようになります。たとえば、その名称として /usr/local を選択した場合、/usr/local/bin パスは明らかにこの名前空間の一部です。

3. ユーザーのコミュニティー識別を簡単にするため、autofs 間接マップを作成します。

   autofs 間接マップを /usr/local にマウントします。NIS の auto_master マップ内で、次のエントリを設定します。

   /usr/local auto_local -ro

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

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

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

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

   bin aa:/export/local/bin

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

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

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

   • x86 クライアント – 実行可能ファイルを /export/local/bin/i386 に配置します。

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

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

   autofs OSREL 変数と CPU 変数を結合して、CPU タイプと OS リリースの両方を示す名前を作成することができます。

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

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

   SunOS 5.6 を動作させているクライアントについて、次のファイルシステムをエクスポートします。

   • SPARC クライアント – /export/local/bin/sparc5.6 をエクスポートします。

   • x86 クライアント – /export/local/bin/i3865.6 に実行可能ファイルを配置します。

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

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

1. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

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

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

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

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

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

1. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

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

   /home auto_home -nosuid

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

   このエントリは、汎用ローカルファイル /etc/auto_master 内の /home のエントリを無効にします。前述の例を参照してください。これは、+auto_master が、ファイル内の /home エントリより先に、外部のネームサービスマップを参照するためです。auto_home マップ内のエントリにマウントオプションがある場合、nosuid オプションは無効になります。そのため、auto_home マップ内でオプションを使用しないようにするか、nosuid オプションを各エントリに含める必要があります。

   ---

   注 –

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

   ---

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

1. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

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

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

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

autofs で NFS URL を使用する方法

1. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

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. NFS クライアント上で、スーパーユーザー、またはそれと同等の役割になります。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

2. /etc/default/autofs ファイルを編集して、次のキーワードと値を追加します。

   AUTOMOUNTD_NOBROWSE=TRUE

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

   # svcadm restart system/filesystem/autofs

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

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

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

   /home auto_home -nobrowse

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

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

   # /usr/sbin/automount

選択したファイルシステムの autofs ブラウズ機能を無効にする方法

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

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

   優先するローカルファイルエントリについては、ネームサービススイッチファイル内のエントリがネームサービスの前に files を一覧表示する必要があります。次に例を示します。

   automount: files nis

   これは、標準的な 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 の問題を追跡するときは、問題が発生する可能性があるのは主に、 サーバー、クライアント、およびネットワークであることを覚えておいてください。この節で説明するのは、個々の構成要素を切り離して、正常に動作しない部分を見つけ出そうというものです。リモートマウントを正常に実行するには、サーバー上で 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 サービスがサーバー上で動作しているかどうか

上記の項目をチェックする過程で、ネットワークのほかの部分が機能していないことに気付く場合があります。たとえば、ネームサービスやネットワークのハードウェアが機能していない場合があります。複数のネームサービスでのデバッグ手順については、『Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)』で説明しています。また、上記の項目をチェックする過程で、クライアント側には問題がないことが判明することもあります。たとえば、作業領域のすべてのサブネットから、少なくとも 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 コマンドを実行します。

   別のクライアントから実行したコマンドが失敗したら、「サーバーで NFS サービスを確認する方法」を参照してください。

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

   このコマンドが失敗する場合は、そのクライアントのネットワークソフトウェアの構成を確認します (/etc/netmasks、/etc/nsswitch.conf など)。

6. (省略可能) rpcinfo コマンドの出力を確認します。

   rpcinfo コマンドを使用しても「program 100003 version 4 ready and waiting」と表示されない場合は、NFS version 4 がサーバー上で有効になっていません。NFS version 4 の有効化については、表 5–3 を参照してください。

7. ソフトウェアに問題がない場合は、ネットワークハードウェアを確認します。

   クライアントをネットワークの別の場所へ移動して確認します。

NFS サーバーをリモートで確認する方法

NFS version 4 のサーバーを使用している場合は、UDP と MOUNT プロトコルをサポートする必要がないことに注意してください。

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

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

   デーモンが起動していない場合は、「NFS サービスを再起動する方法」を参照してください。

2. サーバーで nfsd プロセスが応答することを確認します。

   クライアント上で、次のコマンドを入力し、サーバーからの UDP NFS 接続をテストします。

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

   ---

   注 –

   NFS version 4 は、UDP をサポートしません。

   ---

   サーバーが動作している場合、プログラムとバージョン番号が表示されます。-t オプションを使用すると、TCP 接続を検査できます。上記コマンドでエラーになる場合は、「サーバーで 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

   サーバーが動作している場合は、UDP プロトコルに関連しているプログラムとそのバージョン番号が出力されます。-t オプションを使用すると、TCP 接続を検査できます。エラーになる場合は、「サーバーで NFS サービスを確認する方法」に進んでください。

4. ローカル autofs サービスを使用していた場合は、そのサービスを確認します。

   % cd /net/wasp

   /net か /home マウントポイントのうち、適切に動作する方を確認します。エラーになる場合は、次のコマンドを root としてクライアントから入力し、autofs サービスを再起動します。

   # svcadm restart system/filesystem/autofs

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

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

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

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

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

1. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

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. 次のコマンドを入力し、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

   サーバーが動作している場合は、UDP プロトコルに関連しているプログラムとそのバージョン番号が出力されます。rpcbind がハングアップしたと思われる場合は、サーバーをリブートしてください。

6. 次のコマンドを入力して、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

   ---

   注 –

   NFS version 4 は、UDP をサポートしません。

   ---

   サーバーが動作している場合は、UDP プロトコルに関連しているプログラムとそのバージョン番号が出力されます。rpcinfo に -t オプションを指定し、TCP 接続も確認します。これらのコマンドを使用するとエラーになる場合は、NFS サービスを再起動します。「NFS サービスを再起動する方法」を参照してください。

7. 次のコマンドを入力して、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

   サーバーが動作している場合は、UDP プロトコルに関連しているプログラムとそのバージョン番号が出力されます。rpcinfo に -t オプションを指定し、TCP 接続も確認します。これらのコマンドを使用するとエラーになる場合は、NFS サービスを再起動します。「NFS サービスを再起動する方法」を参照してください。

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

1. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

2. サーバー上で NFS サービスを再起動します。

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

   # svcadm restart network/nfs/server

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 コマンドは、無効なオプションをマウントテーブルに追加することができません。そのため、mnttab ファイルに記述されているオプションとコマンド行のオプションが一致していることを確認してください。このようにすると、nfsstat コマンドにより報告されなかったオプションを特定することができます。

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

autofs のトラブルシューティング

autofs の使用時に、問題の発生することがあります。この節では、問題解決プロセスについてわかりやすく説明します。この節は、2 つのパートに分かれています。

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

• automount の詳細形式 (-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 で示されるサーバーにコンタクトしようとしましたが、応答がありません。

対処方法:

NFS サーバーの状態を確認してください。

hostname: exports: rpc-err

説明:

このエラーは、hostname からエクスポートリストを取得する場合に発生します。このメッセージは、サーバーまたはネットワークに問題があることを示します。

対処方法:

NFS サーバーの状態を確認してください。

map mapname, key key: bad

説明:

マップエントリが不適切な形式であり、autofs が処理できません。

対処方法:

そのエントリを再確認してください。そのエントリに、エスケープする必要のある文字が含まれている可能性があります。

mapname: nis-err

説明:

このエラーは、NIS マップのエントリを参照する場合に発生します。このメッセージは、NIS に問題がある可能性があることを示しています。

対処方法:

NIS サーバーの状態を確認してください。

mount of server: pathname on mountpoint:reason

説明:

autofs がマウントに失敗しました。サーバーまたはネットワークに問題のある可能性があります。reason の文字列によって、問題が特定されます。

対処方法:

サポートが必要な場合は、ご購入先に連絡してください。このエラーメッセージが出力されることはほとんどなく、直接的な解決策はありません。

mountpoint: Not a directory

説明:

autofs は、ディレクトリではない mountpoint に示される場所に自分自身をマウントすることができません。

対処方法:

マウントポイントのスペルとパス名を確認してください。

nfscast: cannot send packet: reason

説明:

autofs が、複製されたファイルシステムの場所を示すリスト内にあるサーバーへの照会パケットを送信できません。reason の文字列によって、問題が特定されます。

対処方法:

サポートが必要な場合は、ご購入先に連絡してください。このエラーメッセージが出力されることはほとんどなく、直接的な解決策はありません。

nfscast: cannot receive reply: reason

説明:

autofs が、複製されたファイルシステムの場所を示すリスト内にあるいずれのサーバーからも応答を受けられません。reason の文字列によって、問題が特定されます。

対処方法:

サポートが必要な場合は、ご購入先に連絡してください。このエラーメッセージが出力されることはほとんどなく、直接的な解決策はありません。

nfscast: select: reason

説明:

このようなエラーメッセージはすべて、複製されたファイルシステムのサーバーに対して確認を実行した際に問題が発生したことを示します。このメッセージは、ネットワークに問題がある可能性があることを示しています。reason の文字列によって、問題が特定されます。

対処方法:

サポートが必要な場合は、ご購入先に連絡してください。このエラーメッセージが出力されることはほとんどなく、直接的な解決策はありません。

pathconf: no info for server:pathname

説明:

autofs が、パス名に関する pathconf 情報の取得に失敗しました。

対処方法:

fpathconf(2) のマニュアルページを参照してください。

pathconf: server : server not responding

説明:

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

対処方法:

このサーバーで POSIX マウントオプションを使用しないでください。

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 udp 2049 NFS server daemon

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

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

Cannot use index option without public option

対処方法:

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

---

注 –

Solaris 2.5.1 では、share コマンドを使って公開ファイルハンドルを設定する必要があります。Solaris 2.6 リリースにおいて、公開ファイルハンドルはデフォルトでルート (/) に設定されるように変更されました。このエラーメッセージは出力されません。

---

Could not start daemon : error

説明:

このメッセージは、デーモンが異常終了するか、システムコールにエラーが発生した場合に表示されます。error の文字列によって、問題が特定されます。

対処方法:

サポートが必要な場合は、ご購入先に連絡してください。このエラーメッセージが出力されることはほとんどなく、直接的な解決策はありません。

Could not use public filehandle in request to server

説明:

このメッセージは、public オプションが指定されているにもかかわらず NFS サーバーが公開ファイルハンドルをサポートしていない場合に表示されます。この場合、マウントが失敗します。

対処方法:

この問題を解決するには、公開ファイルハンドルを使用しないでマウント要求を行うか、NFS サーバーが公開ファイルハンドルをサポートするように設定し直します。

daemon running already with pid pid

説明:

デーモンがすでに実行されています。

対処方法:

新たにデーモンを実行する場合は、現在のデーモンを終了し、新しいデーモンを開始します。

error locking lock file

説明:

このメッセージは、デーモンに関連付けられている lock file を正しくロックできなかった場合に表示されます。

対処方法:

サポートが必要な場合は、ご購入先に連絡してください。このエラーメッセージが出力されることはほとんどなく、直接的な解決策はありません。

error checking lock file : error

説明:

このメッセージは、デーモンに関連付けられている lock file を正しく開くことができなかった場合に表示されます。

対処方法:

サポートが必要な場合は、ご購入先に連絡してください。このエラーメッセージが出力されることはほとんどなく、直接的な解決策はありません。

NOTICE: NFS3: failing over from host1 to host2

説明:

このメッセージは、フェイルオーバーが発生するとコンソールに表示されます。報告のためだけのメッセージです。

対処方法:

何もする必要はありません。

filename: File too large

説明:

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

対処方法:

NFS version 2 を使用しないでください。 version 3 または version 4 を使用してファイルシステムをマウントします。nolargefiles オプションについては、「NFS ファイルシステム用の mount オプション」を参照してください。

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 file temporarily unavailable on the server, retrying ...

説明:

NFS version 4 サーバーでは、ファイルの管理をクライアントに委託できます。このメッセージは、クライアントからの要求と重複するほかのクライアントへの委託を、サーバーが再発信していることを示します。

対処方法:

サーバーがクライアントの要求を処理する前に、再発信が行われる必要があります。委託の詳細は、「NFS version 4 における委託」を参照してください。

NFS fsstat failed for server hostname: RPC: Authentication error

説明:

さまざまな状況で発生するエラーです。もっともデバッグが困難なのは、ユーザーの属しているグループが多すぎる場合です。現在、ユーザーは最大 16 個のグループに属すことができますが、NFS マウントでファイルにアクセスしている場合は、それよりも少なくなります。

対処方法:

ただし、ユーザーが 17 個以上のグループに所属する必要がある場合の方法もあります。NFS サーバーおよび NFS クライアントで Solaris 2.5 リリース以降が動作している場合は、アクセス制御リストを使用して、必要なアクセス特権を与えることができます。

nfs mount: ignoring invalid option “ -option”

説明:

-option フラグが無効です。

対処方法:

必要な構文を確認するには、mount_nfs(1M) のマニュアルページを参照してください。

---

注 –

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

---

nfs mount: NFS can't support “nolargefiles”

説明:

NFS クライアントが、-nolargefiles オプションを使用して NFS サーバーからファイルシステムをマウントしようとしました。

対処方法:

このオプションは、NFS ファイルシステムタイプに対してはサポートされていません。

nfs mount: NFS V2 can't support “largefiles”

説明:

NFS version 2 プロトコルでは、大規模ファイルを処理できません。

対処方法:

大規模ファイルを扱う必要がある場合は、version 3 または version 4 を使用してください。

NFS server hostname not responding still trying

説明:

ファイル関連の作業中にプログラムがハングアップすると、NFS サーバーに障害が発生する可能性があります。このメッセージは、NFS サーバー (hostname) がダウンしているか、サーバーかネットワークに問題があることを示すものです。

対処方法:

フェイルオーバー機能を使用している場合、hostname はサーバー名のリストになります。「NFS クライアントの接続性を確認する方法」を参照してください。

NFS server recovering

説明:

NFS version 4 サーバーのリブート中に、一部の操作が許可されませんでした。このメッセージは、サーバーがこの操作の続行を許可するまで、クライアントが待機していることを示します。

対処方法:

何もする必要はありません。サーバーが操作を許可するまで待機します。

Permission denied

説明:

このメッセージは、次の理由により、ls -l、getfacl、および setfacl コマンドによって表示されます。

• NFS version 4 サーバー上のアクセス制御リスト (ACL) エントリ内に存在するユーザーまたはグループを、NFS version 4 クライアント上の有効なユーザーまたはグループにマッピングできない場合、ユーザーはクライアント上の ACL を読み取ることができない。

• NFS version 4 クライアント上で設定されている ACL エントリ内に存在するユーザーまたはグループを、NFS version 4 サーバー上の有効なユーザーまたはグループにマッピングできない場合、ユーザーはクライアント上の ACL に書き込みや変更を行うことができない。

• NFS version 4 のクライアントとサーバーで NFSMAPID_DOMAIN の値が一致しない場合、ID マッピングが失敗する。

詳細は、「NFS version 4 での ACL と nfsmapid」を参照してください。

対処方法:

次の手順を実行してください。

• ACL エントリ内のすべてのユーザーおよびグループ ID がクライアントとサーバーの両方に存在することを確認します。

• NFSMAPID_DOMAIN の値が /etc/default/nfs ファイル内で正しく設定されていることを確認します。詳細は、「/etc/default/nfs ファイルのキーワード」を参照してください。

ユーザーまたはグループをサーバーまたはクライアント上でマッピングできるかどうかを判断するには、「ACL エントリ内のすべてのユーザーおよびグループ ID が NFS version 4 のクライアントとサーバーの両方に存在することを確認します。」にあるスクリプトを使用します。

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 プロトコルをサポートしていなければなりません。

対処方法:

複数のバージョンが混在することは許されません。

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

対処方法:

サーバーを、ロックマネージャーを完全にサポートする新しいバージョンの OS にアップグレードします。