Solaris のシステム管理 (資源管理とネットワークサービス)

パート III ネットワークファイルシステムへのアクセス (トピック)

第 13 章「ネットワークファイルシステムの管理 (概要)」: NFS サービスの概要
第 14 章「ネットワークファイルシステムの管理 (手順)」: NFS サービスの設定と障害回避方法 (トラブルシューティング)
第 15 章「ネットワークファイルシステムへのアクセス (リファレンス)」: NFS サービスの背景情報について

第 13 章ネットワークファイルシステムの管理 (概要)

この章では、ネットワーク経由でファイルシステムにアクセスするために使用する NFS サービスの概要を説明します。また、NFS サービスを理解するために必要な概念、および NFS と autofs の最新の機能についても説明します。

NFS の用語

ここでは、NFS サービスを使用するために必要な基本用語について説明します。NFS サービスの詳細は、第 15 章「ネットワークファイルシステムへのアクセス (リファレンス)」で説明します。

NFS サーバーとクライアント

クライアントとサーバーという用語は、コンピュータがファイルシステムを共有するときの役割を示すものです。ネットワークを介してファイルシステムを提供するコンピュータは、サーバーの役割を果たします。そのファイルシステムにアクセスしているコンピュータをクライアントと呼びます。NFS を使用することによって、どのコンピュータからも他のコンピュータのファイルシステムにアクセスでき、同時に自分のファイルシステムへのアクセスも可能になります。ネットワーク上では 1 台のコンピュータがクライアントかサーバー、またはその両方の役割として動作することができます。

クライアントは、サーバーの共有ファイルシステムをマウントすることによってサーバーのファイルにアクセスします。クライアントがリモートファイルシステムをマウントしたとき、ファイルシステムがコピーされるのではありません。マウントプロセスでは一連のリモート手続き呼び出しによって、クライアントからサーバーのディスク上にあるファイルシステムに透過的にアクセスできるようになります。マウントはローカルマウントのように行われます。ユーザーはファイルシステムがローカルにあるのと同じようにコマンドを入力します。ファイルシステムをマウントする方法については、ファイルシステムのマウントを参照してください。

サーバーのファイルシステムは、NFS オペレーションによって共有すると、クライアントからアクセスできるようになります。NFS ファイルシステムは、autofs を使用すると自動的にマウントできます。share コマンドと autofs に関連する作業については、ファイルシステムの自動共有と autofs 管理作業の概要を参照してください。

NFS ファイルシステム

NFS サービスで共有できるオブジェクトは、ファイル階層の全体、またはその一部です。ファイルを 1 つだけ共有することもできます。すでに共有しているファイル階層と重複するファイル階層は共有できません。モデムやプリンタなどの周辺機器も共有できません。

多くの UNIX システム環境で共有されるファイル階層構造は、1 つのファイルシステム、またはその一部です。しかし NFS サポートは複数のオペレーティングシステムにまたがって動作しますが、ファイルシステムという考え方は UNIX 以外の環境では通用しません。したがって、ファイルシステムという語は、NFS でマウントし共有したファイルまたはファイル階層構造を指します。

NFS サービスについて

NFS サービスとは、アーキテクチャが異なり、別のオペレーティングシステムで動作しているコンピュータが、ネットワークを通じてファイルシステムを共有できるようにするサービスのことです。NFS サポートは、MS-DOS から VMS オペレーティングシステムまで多くのプラットフォームに実装されています。

NFS 環境は、異なるオペレーティングシステムで実現できます。NFS はアーキテクチャの仕様を定義するのではなく、ファイルシステムの抽象モデルを定義しているためです。それぞれのオペレーティングシステムでは、ファイルシステムセマンティクスに NFS 抽象モデルを適用します。このモデルにより、書き込みや読み出しのようなファイルシステムオペレーションが、ローカルファイルにアクセスするように機能することになります。

NFS サービスには次の利点があります。

複数のコンピュータで同一のファイルを使用するため、ネットワーク上の誰もが同じデータにアクセスできる
各ユーザーアプリケーションがローカルのディスクスペースを占めるのではなく、複数のコンピュータでアプリケーションを共有するため、記憶領域を有効利用できる
すべてのユーザーが同一セットのファイルを読み出すので、データの整合性と信頼性が向上する
ファイルシステムをユーザーに透過的な形でマウントできる
リモートファイルに透過的にアクセスできる
さまざまな環境をサポートする
システム管理の手間を省ける

NFS サービスを使用すると、ファイルシステムの実際の場所をユーザーとは無関係に決めることができます。ユーザーは場所を気にすることなく、すべての適切なファイルにアクセスできるということです。NFS サービスでは、共通して使用するファイルのコピーをすべてのシステムに置くのではなく、コピーを 1 つのコンピュータのディスクに置き、他のシステムからネットワークを通じてアクセスできるようにします。NFS オペレーションでは、リモートファイルシステムとローカルファイルシステムの区別がありません。

autofs について

NFS サービスで共有されるファイルシステムは、「自動マウント」と呼ばれる方法によってマウントできます。クライアント側のサービスである autofs は、自動マウントを実現するファイルシステム構造です。autofs のファイルシステムは、automount で作成されます。automount は、システムを起動すると自動的に実行されます。automountd という常駐型の自動マウントデーモンが、必要に応じてリモートディレクトリのマウントとアンマウントを行います。

automountd を実行しているクライアントコンピュータがリモートのファイルまたはディレクトリにアクセスしようとすると、リモートのファイルシステムがデーモンによってマウントされます。このリモートファイルシステムは、必要な間はマウントされたままです。リモートファイルシステムが一定時間アクセスされないと、自動的にアンマウントされます。

ブート時にマウントする必要はなく、ユーザーはディレクトリをマウントするためにスーパーユーザーのパスワードを知る必要はありません。ユーザーが mount と umount コマンドを使用する必要もありません。autofs は、ユーザーの介入なしに、必要に応じてファイルシステムをマウントまたはアンマウントします。

automountd によって一部のファイル階層をマウントするということは、mount によって他の階層をマウントしないということではありません。ディスクレスコンピュータは、mount と /etc/vfstab ファイルを使用して / (ルート)、/usr、および /usr/kvm をマウントしなければなりません。

autofs サービスについては、autofs 管理作業の概要と autofs のしくみで詳しく説明します。

NFS サービスの機能

ここでは、NFS サービスの重要な機能について説明します。

NFS バージョン 2 プロトコル

バージョン 2 は、一般に広く使用された初めての NFS プロトコルです。バージョン 2 は、引き続き広範囲のプラットフォームで使用できます。Solaris のすべてのリリースが NFS プロトコルのバージョン 2 をサポートし、Solaris 2.5 より以前のリリースはバージョン 2 だけをサポートします。

NFS バージョン 3 プロトコル

NFS バージョン 3 のプロトコルは、Solaris 2.5 で新機能として追加されたものです。相互運用性とパフォーマンスを向上させるために、いくつかの変更が行われました。これらをすべて有効に利用するには、NFS サーバーとクライアントの両方で、バージョン 3 プロトコルを使用する必要があります。

バージョン 3 では、サーバーで非同期の書き込みが可能になります。サーバーがクライアントの書き込み要求をメモリーに保存するので、効率が向上しました。クライアントは、サーバーが変更内容をディスクに反映させるのを待つ必要がないため、応答時間が短縮されます。サーバーは要求をバッチ処理することもできるので、サーバー上の応答時間も短縮されました。

NFS バージョン 3 では、多くの操作でローカルキャッシュに保存されているファイル属性が返されます。キャッシュの更新頻度が増えたため、ローカルキャッシュのデータを更新する操作を独立して行う必要性が少なくなります。したがってサーバーに対する RPC コールの回数が減少し、パフォーマンスが向上します。

ファイルアクセス権の確認処理も改善されました。バージョン 2 では、ユーザーが適切なアクセス権を持っていないリモートファイルをコピーしようとすると、「書き込みエラー」や「読み出しエラー」というメッセージが出力されました。バージョン 3 では、ファイルを開く前に権利がチェックされるので、「オープンエラー」というメッセージが出力されます。

NFS バージョン 3 プロトコルでは、8K バイトの転送サイズ制限が解除されました。クライアントとサーバーは、バージョン 2 の 8K バイトの制限を受けることなく、サポートされている転送サイズをネゴシエートできます。Solaris 2.5 では、デフォルトで、転送サイズが 32K バイトに設定されていることに注意してください。

NFS ACL サポート

Solaris 2.5 で、アクセス制御リスト (ACL) サポートが追加されました。ACL では、ファイルアクセス権を通常の UNIX よりも厳密に設定します。この追加機能では効率は改善されませんが、ファイルへのアクセスがより厳密に制限されるので、セキュリティが向上します。ACL の詳細は、『Solaris のシステム管理 (セキュリティサービス)』の「アクセス制御リスト (ACL) の使用」を参照してください。

NFS の TCP への依存

NFS プロトコルのデフォルトのトランスポートプロトコルは、Solaris 2.5 で TCP (Transmission Control Protocol) に変更されました。TCP は、低速ネットワークとワイドエリアネットワークのパフォーマンスの向上に役立ちます。TCP には、トラフィック抑制機能とエラー回復機能もあります。TCP を利用した NFS は、バージョン 2 でもバージョン 3 でも動作します。Solaris 2.5 より前のバージョンでは、NFS のデフォルトプロトコルは UDP (User Datagram Protocol) でした。

ネットワークロックマネージャと NFS

Solaris 2.5 からネットワークロックマネージャの改良版も含まれています。このため NFS ファイルに対して UNIX のレコードロックと PC のファイル共有を使用できます。NFS ファイルのロックメカニズムの信頼性の向上により、ロックを使用するコマンドのハングが起こりにくくなりました。

NFS 大規模ファイルのサポート

Solaris 2.6 の NFS バージョン 3 プロトコルから、2G バイトを超えるサイズのファイル (大規模ファイル) も正しく処理できるようになりました。NFS バージョン 2 プロトコル、および Solaris 2.5 に実装されているバージョン 3 プロトコルでは 2G バイトを超えるサイズのファイルは処理できませんでした。

NFS クライアントのフェイルオーバー機能

Solaris 2.6 では、読み取り専用ファイルシステムの動的フェイルオーバー機能が追加されました。フェイルオーバーによって、マニュアルページ、その他のドキュメント、共有バイナリなどのあらかじめ複製されている読み取り専用リソースを高度に利用できます。フェイルオーバー機能は、ファイルシステムがマウントされた後ならばいつでも実行可能です。手動マウントでは、今までのリリースのオートマウンタのように複数の複製をリストできるようになりました。オートマウンタは、フェイルオーバーの際にファイルシステムが再マウントされるまで待つ必要がなくなったこと以外は変更されていません。詳細は、クライアント側フェイルオーバーを使用する方法とクライアント側フェイルオーバー機能を参照してください。

NFS サービスのための Kerberos のサポート

Solaris 2.0 では、Kerberos V4 クライアントがサポートされていました。Solaris 2.6 では、mount と share コマンドが Kerberos V5 認証を使用する NFS バージョン 3 のマウントをサポートするように変更されました。share コマンドもクライアントごとに異なる複数の認証機能を使用できるように変更されました。各種のセキュリティ機能の詳細は、RPCSEC_GSS セキュリティ方式を参照してください。Kerberos V5 認証の詳細は、『Solaris のシステム管理 (セキュリティサービス)』の「SEAM NFS サーバーの構成」を参照してください。

WebNFS のサポート

Solaris 2.6 には、インターネット上のファイルシステムにファイアウォール経由でアクセスできるようにする機能も追加されました。この機能は、NFS プロトコルの拡張機能によって実現しました。インターネットアクセスに WebNFS^TM プロトコルを使用する利点の 1 つは、信頼性が高いことです。このサービスは、NFS バージョン 3 とバージョン 2 プロトコルの拡張として構築されています。さらに、WebNFS ではそうしたファイルを共有しても匿名 ftp サイトを管理するオーバーヘッドが生じません。WebNFS サービスのその他の変更については、WebNFS サービスのセキュリティネゴシエーションを参照してください。作業については、WebNFS の管理作業を参照してください。

RPCSEC_GSS セキュリティ方式

Solaris 7 から、新しいセキュリティ方式である RPCSEC_GSS がサポートされています。この方式では、標準的な GSS-API インタフェースを使用して、認証、一貫性、機密性を実現し、複数のセキュリティメカニズムをサポートしています。Kerberos V5 認証のサポートについての詳細は、NFS サービスのための Kerberos のサポートを参照してください。GSS-API についての詳細は、『GSS-API のプログラミング』を参照してください。

Solaris 7 の NFS に対する拡張機能

Solaris 7 で、mount コマンドと automountd コマンドが拡張され、マウント要求で MOUNT プロトコルの代わりに公開ファイルハンドルも使用できるようになりました。MOUNT プロトコルは、WebNFS サービスが使用するアクセス方法と同じです。公開ファイルハンドルを使用すると、ファイアウォールを越えたマウントが可能です。さらに、サーバーとクライアント間のトランザクションが少なくて済むため、マウントにかかる時間が短縮されます。

この機能拡張で、標準のパス名の代わりに NFS URL を使用することもできるようになりました。また、mount コマンドとオートマウンタのマップに public オプションを指定すると、必ず公開ファイルハンドルを使用するようになります。WebNFS サービスの変更の詳細は、WebNFS のサポートを参照してください。

WebNFS サービスのセキュリティネゴシエーション

Solaris 8 で、WebNFS クライアントが NFS サーバーとセキュリティメカニズムをネゴシエートするための新しいプロトコルが追加されました。このプロトコルの追加により、WebNFS サービスの使用時に、セキュリティ保護されたトランザクションを使用できます。詳細については、WebNFS セキュリティネゴシエーション機能のしくみを参照してください。

NFS サーバーロギング

Solaris 8 で、NFS サーバーはサーバーロギングによって、ファイルシステムに実行されたファイル操作の記録を提供できるようになりました。この記録には、どのファイルが、いつ、誰によってアクセスされたかという情報が含まれています。一連の構成オプションを使用して、これらの情報を含むログの場所を指定することができます。また、これらのオプションを使用して、ログに記録する処理を選択することもできます。この機能は、NFS クライアントや WebNFS クライアントで匿名 ftp を利用するサイトで特に便利です。詳細は、NFS サーバーログを有効にする方法を参照してください。

autofs の特徴

autofs は、ローカルの名前空間に指定したファイルシステムで動作します。この情報は、NIS、NIS+、およびローカルファイルに保存されます。

Solaris 2.6 から、完全にマルチスレッド化された automountd が含まれています。この拡張によって autofs はさらに信頼性が高まりました。また、複数のマウントを同時にサービスできるようになったため、サーバーが使用できないときにサービスが停止することも避けられます。

この新しい automountd には、オンデマンドマウント機能もあります。Solaris 2.6 より前のリリースでは、階層に含まれるすべてのファイルシステムがマウントされていました。現在は、いちばん上のファイルシステムしかマウントされません。そのマウントポイントに関係する他のファイルシステムは、必要に応じてマウントされます。

autofs サービスで、間接マップを表示できるようになりました。これによりユーザーは、どのディレクトリがマウントできるかを確認するためにファイルシステムを実際に 1 つずつマウントする必要がなくなります。autofs マップに -nobrowse オプションが追加されたので、/net や /home などの大きなファイルが自動的に表示されることはありません。また、automount に対して -n を使用することによって、autofs の表示機能を各クライアントでオフにすることもできます。詳細は、autofs のブラウズ機能を無効にするを参照してください。

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

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

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

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

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

ファイルシステムの共有開始と共有解除
管理ファイルを修正し、コンピュータが共有したり、自動的にマウントしたファイルシステムのリストを更新したりすること
ネットワークの状態のチェック
NFS に関連した問題の診断と解決
autofs のマップの設定

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

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

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

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

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

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

表 14–1 ファイルシステムの共有 (作業マップ)


作業	説明	参照先
自動ファイルシステムの共有を確立する	サーバーのリブート時、ファイルシステムが自動的に共有されるようにサーバーを設定する手順	ファイルシステム自動共有を設定する方法
WebNFS を有効にする	ユーザーが WebNFS でファイルにアクセスできるようにサーバーを設定する手順	WebNFS アクセスを有効にする方法
NFS サーバーログを有効にする	NFS ログが選択したファイルシステム上で動作するようにサーバーを設定する手順	NFS サーバーログを有効にする方法

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

スーパーユーザー、またはそれと同等の役割になります。

役割については、『Solaris のシステム管理 (セキュリティサービス)』の「特権付きアプリケーションの使用」を参照してください。

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

/etc/dfs/dfstab を編集します。自動的に共有する各ファイルシステムのファイルにエントリを 1 つ追加します。各エントリは、ファイル中に 1 行で記述する必要があり、次のような構文を使用します。
share [-F nfs] [-o specific-options] [-d description] pathname
/etc/dfs/dfstab ファイルについては、dfstab(4) のマニュアルページを、全オプションのリストについては、share_nfs(1M) のマニュアルページを参照してください。

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

share コマンドまたは share コマンドセットをはじめて実行する場合、NFS サービスが動作していないことがあります。次のコマンドを使用して、NFS デーモンのどれかが動作していることをチェックします。
# pgrep nfsd 318
この例では、318 は nfsd のプロセス ID です。 ID が表示されない場合は、サービスが動作していないことを意味します。次に、mountd が動作していることをチェックします。

(省略可能) NFS サービスを起動します。

前の手順を実行しても nfsd のプロセス ID が表示されない場合は、次のコマンドを使用して、NFS サービスを起動します。
# /etc/init.d/nfs.server start
このコマンドを実行すると、NFS サービスがサーバーで実行されます。リブート時にサーバーが実行レベル 3 であるときには、NFS サービスが自動的に再起動されます。

(省略可能) ファイルシステムを共有します。

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

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

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 アクセスの計画を参照してください。

スーパーユーザー、またはそれと同等の役割になります。

役割については、『Solaris のシステム管理 (セキュリティサービス)』の「特権付きアプリケーションの使用」を参照してください。

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) のマニュアルページを参照してください。

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

share コマンドまたは share コマンドセットをはじめて実行する場合、NFS デーモンが動作していないことがあります。次のコマンドを使用して、NFS デーモンのどれかが動作していることをチェックします。
# pgrep nfsd 318
この例では、318 は nfsd のプロセス ID です。 ID が表示されない場合は、サービスが動作していないことを意味します。次に、mountd が動作していることをチェックします。

(省略可能) NFS サービスを起動します。

前の手順を実行しても nfsd のプロセス ID が表示されない場合は、次のコマンドを使用して、NFS サービスを起動します。
# /etc/init.d/nfs.server start
このコマンドを実行すると、NFS サービスがサーバーで実行されます。ブート時にサーバーが実行レベル 3 になったときには、NFS サービスが自動的に再起動されます。

(省略可能) ファイルシステムを共有します。

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

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

share コマンドを実行し、適切なオプションが表示されていることを確認します。
# share - /export/share/man ro "" - /usr/src rw=eng "" - /export/ftp ro,public,index=index.html ""

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

スーパーユーザー、またはそれと同等の役割になります。

役割については、『Solaris のシステム管理 (セキュリティサービス)』の「特権付きアプリケーションの使用」を参照してください。

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

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

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) のマニュアルページを参照してください。

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

share コマンドまたは share コマンドセットをはじめて実行する場合、NFS デーモンが動作していないことがあります。次のコマンドを使用して、NFS デーモンのどれかが動作していることをチェックします。
# pgrep nfsd 318
この例では、318 は nfsd のプロセス ID です。 ID が表示されない場合は、サービスが動作していないことを意味します。次に、mountd が動作していることをチェックします。

(省略可能) NFS サービスを起動します。

前の手順を実行しても nfsd のプロセス ID が表示されない場合は、次のコマンドを使用して、NFS サービスを起動します。
# /etc/init.d/nfs.server start
このコマンドを実行すると、NFS サービスがサーバーで実行されます。ブート時にサーバーが実行レベル 3 になったときには、NFS サービスが自動的に再起動されます。

(省略可能) ファイルシステムを共有します。

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

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

share コマンドを実行し、適切なオプションが表示されていることを確認します。
# share - /export/share/man ro "" - /usr/src rw=eng "" - /export/ftp ro,log=global ""

(省略可能) NFS ログデーモン nfslogd がすでに実行されていなければ、起動します。

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

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

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

表 14–2 ファイルシステムのマウントの作業マップ


作業	説明	参照先
ブート時にファイルシステムをマウントする	システムがリブートされるときに必ずファイルシステムがマウントされるようにする手順	ブート時のファイルシステムのマウント方法
コマンドを使用してファイルシステムをマウントする	システムの動作時にファイルシステムをマウントする手順。この手順はテストに有効	コマンド行からファイルシステムをマウントする方法
オートマウンタによりマウントする	コマンド行を使用せずに、要求に応じてファイルシステムにアクセスする手順	オートマウンタによるマウント
大規模ファイルを避ける	ファイルシステム上に大規模ファイルが作成されないようにする手順	NFS サーバー上で大規模ファイルを無効にする方法
クライアント側フェイルオーバーを開始する	サーバーの不良時、動作中のファイルシステムへの自動切り換えを有効にする手順	クライアント側フェイルオーバーを使用する方法
クライアントに対するマウントアクセスを無効にする	任意のクライアントがリモートシステムにアクセスする機能を無効にする手順	1 つのクライアントに対するマウントのアクセスを無効にする方法
ファイアウォールを越えてファイルシステムにアクセスを提供する	WebNFS プロトコルを使用してファイアウォールを越えてファイルシステムへのアクセスを許可する手順	ファイアウォールを越えて NFS ファイルシステムをマウントする方法
NFS URL を使ってファイルシステムをマウントする	NFS URL を使ってファイルシステムへのアクセスを許可する手順。このプロセスによって、MOUNT プロトコルを使用しないでファイルシステムへのアクセスが可能になる	NFS URL を使用して NFS ファイルシステムをマウントする方法

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

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

スーパーユーザー、またはそれと同等の役割になります。

役割については、『Solaris のシステム管理 (セキュリティサービス)』の「特権付きアプリケーションの使用」を参照してください。

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

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

special  fsckdev  mountp  fstype  fsckpass  mount-at-boot  mntopts

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

注意 –

NFS サーバーに NFS vfstab ファイルのエントリを作成するとデッドロックが発生する可能性があるため、作成しないでください。/etc/vfstab のエントリが確認された後、NFS サービスが起動します。次のようなことが考えられます。互いにファイルシステムをマウントしている 2 つのサーバーが同時に停止した場合、リブート時にハングアップする可能性があります。

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

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

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

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

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

スーパーユーザー、またはそれと同等の役割になります。

役割については、『Solaris のシステム管理 (セキュリティサービス)』の「特権付きアプリケーションの使用」を参照してください。

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

次のコマンドを入力します。
# 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 以降のリリースで動作していることを確認してください。

スーパーユーザー、またはそれと同等の役割になります。

役割については、『Solaris のシステム管理 (セキュリティサービス)』の「特権付きアプリケーションの使用」を参照してください。

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

次の例は、大規模ファイルを検索するためのコマンドです。
# cd /export/home1 # find . -xdev -size +2000000 -exec ls -l {} \;
システム上に大規模ファイルが存在する場合には、削除するか、他のファイルシステムに移動する必要があります。

ファイルシステムをアンマウントします。
# umount /export/home1

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

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

nolargefiles を使用して、ファイルシステムをマウントします。
# mount -F ufs -o nolargefiles /export/home1
コマンド行からマウントすることができますが、オプションをさらに固定的にするには、/etc/vfstab に次のようなエントリを追加してください。
/dev/dsk/c0t3d0s1 /dev/rdsk/c0t3d0s1 /export/home1 ufs 2 yes nolargefiles

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

スーパーユーザー、またはそれと同等の役割になります。

役割については、『Solaris のシステム管理 (セキュリティサービス)』の「特権付きアプリケーションの使用」を参照してください。

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

コマンド行からも、オートマウンタを使用しても、または /etc/vfstab ファイルに次のようなエントリを追加することによってもマウントできます。
bee,wasp:/export/share/local - /usr/local nfs - no ro
この構文はオートマウンタでも指定できました。しかし、フェイルオーバー機能が使用できるのはサーバーが選択されているときだけで、ファイルシステムがマウントされるときには使用できませんでした。

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

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

スーパーユーザー、またはそれと同等の役割になります。

役割については、『Solaris のシステム管理 (セキュリティサービス)』の「特権付きアプリケーションの使用」を参照してください。

/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) のマニュアルページを参照してください。

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

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

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

スーパーユーザー、またはそれと同等の役割になります。

役割については、『Solaris のシステム管理 (セキュリティサービス)』の「特権付きアプリケーションの使用」を参照してください。

次のコマンドを使用して、ファイルシステムを手動でマウントします。
# 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 ファイルシステムをマウントする方法

スーパーユーザー、またはそれと同等の役割になります。

役割については、『Solaris のシステム管理 (セキュリティサービス)』の「特権付きアプリケーションの使用」を参照してください。

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

NFS サービスの設定

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

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

表 14–3 NFS サービスの作業マップ


作業	説明	参照先
NFS サーバーを起動する	NFS サービスが自動的に起動されていない場合に、NFS サービスを起動する手順	NFS サービスの起動方法
NFS サーバーを停止する	NFS サービスを停止する手順。通常は、サービスを停止する必要はない	NFS サービスの停止方法
オートマウンタを起動する	オートマウンタを起動する手順。オートマウンタマップが変更された場合、この手順が必要	オートマウンタの起動方法
オートマウンタを停止する	オートマウンタを停止する手順。オートマウンタマップが変更された場合、この手順が必要	オートマウンタの停止方法

NFS サービスの起動方法

スーパーユーザー、またはそれと同等の役割になります。

役割については、『Solaris のシステム管理 (セキュリティサービス)』の「特権付きアプリケーションの使用」を参照してください。

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

次のコマンドを入力します。
# /etc/init.d/nfs.server start
/etc/dfs/dfstab にエントリがあると、このコマンドはデーモンを起動します。

NFS サービスの停止方法

スーパーユーザー、またはそれと同等の役割になります。

役割については、『Solaris のシステム管理 (セキュリティサービス)』の「特権付きアプリケーションの使用」を参照してください。

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

次のコマンドを入力します。
# /etc/init.d/nfs.server stop

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

スーパーユーザー、またはそれと同等の役割になります。

役割については、『Solaris のシステム管理 (セキュリティサービス)』の「特権付きアプリケーションの使用」を参照してください。

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

次のコマンドを入力します。
# /etc/init.d/autofs start

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

スーパーユーザー、またはそれと同等の役割になります。

役割については、『Solaris のシステム管理 (セキュリティサービス)』の「特権付きアプリケーションの使用」を参照してください。

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

次のコマンドを入力します。
# /etc/init.d/autofs stop

Secure NFS システムの管理

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

NFS サービスでは、Kerberos バージョン 5 認証もサポートされています。Kerberos サービスについては、『Solaris のシステム管理 (セキュリティサービス)』の「SEAM について」で説明しています。

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

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

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

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

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

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

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

ネームサービスが応答していることを確認します。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 デーモンが動作していることを確認してください。

キーサーバーの 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

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

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

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

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

Diffie-Hellman 認証を使用するには、/etc/dfs/dfstab ファイルを編集し、該当するエントリに sec=dh オプションを追加します。
share -F nfs -o sec=dh /export/home
/etc/dfs/dfstab については、dfstab(4) のマニュアルページを参照してください。

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

auto_master データを編集し、Diffie-Hellman 認証のエントリ内にマウントオプションとして sec=dh を含めます。
/home auto_home -nosuid,sec=dh
注 –
Solaris 2.5 以前のリリースでは、その機能が制限されています。クライアントが、セキュリティ保護されている共有ファイルシステムにセキュリティモードでマウントしない場合、ユーザーは、そのユーザー自身ではなく、nobody ユーザーとしてアクセスすることになります。Solaris 2.5 以降の NFS バージョン 2 では、セキュリティモードが一致しないと、share コマンド行に -sec=none が指定されていないかぎり、NFS サーバーによってアクセスが拒否されます。NFS のバージョン 3 では、セキュリティ保護されていることを示すモードが NFS サーバーから引き継がれるので、クライアントが sec=dh を指定する必要はありません。ユーザーは、そのユーザー自身としてファイルにアクセスできます。

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

WebNFS の管理作業

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

表 14–4 WebNFS 管理の作業マップ


作業	説明	参照先
WebNFS に関する計画を作成する	WebNFS サービスを有効にする前に考慮する項目	WebNFS アクセスの計画
WebNFS を有効にする	WebNFS プロトコルを使用して NFS ファイルシステムのマウントを有効にする手順	WebNFS アクセスを有効にする方法
ファイアウォール経由で WebNFS を有効にする	WebNFS プロトコルを使用して、ファイアウォール経由でファイルへのアクセスを許可する手順	ファイアウォール経由で WebNFS アクセスを有効にする方法
NFS URL を使ってブラウズする	Web ブラウザ内での NFS URL の使用についての説明	NFS URL を使ってブラウズする方法
autofs で公共ファイルハンドルを使用する	オートマウンタでファイルシステムをマウントする場合に、公共ファイルハンドルの使用を強制するための手順	autofs で公共ファイルハンドルを使用する方法
autofs で NFS URL を使用する	オートマウンタマップに NFS URL を追加するための手順	autofs で NFS URL を使用する方法
ファイアウォールを越えてファイルシステムにアクセスを提供する	WebNFS プロトコルでファイアウォールを越えてファイルシステムへのアクセスを許可する手順	ファイアウォールを越えて NFS ファイルシステムをマウントする方法
NFS URL を使ってファイルシステムをマウントする	NFS URL を使ってファイルシステムへのアクセスを許可する手順。このプロセスによって、MOUNT プロトコルを使用しないファイルシステムへのアクセスが可能になる	NFS URL を使用して NFS ファイルシステムをマウントする方法

WebNFS アクセスの計画

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

各サーバーには公共ファイルハンドルが 1 つずつあり、このハンドルはデフォルトではサーバーのルートファイルシステムに結び付けられています。NFS URL に示されたパスは、この公共ファイルハンドルが結び付けられているディレクトリからの相対パスとして評価されます。その結果としてパスが示す先のファイルまたはディレクトリが、エクスポートされたファイルシステムの中にあると、サーバーによってアクセスが実現されます。share コマンドの public オプションを使用すると、エクスポートされる特定のディレクトリにこの公開ファイルハンドルを結び付けることができます。このオプションを使用すると、URL はサーバーのルートファイルシステムではなく公共ファイルシステムからの相対パスになります。ルートファイルシステムを共有しないと、ルートファイルシステムへの Web アクセスはできません。
WebNFS 環境では、すでにマウント権限を持っているユーザーは、ブラウザからファイルにアクセスできます。ファイルシステムが public オプションを使ってエクスポートされているかどうかには関係ありません。ユーザーは NFS の設定によってファイルへのアクセス権を持っているため、ブラウザからのアクセスを許すことによって新たにセキュリティが損なわれる恐れはありません。ファイルシステムをマウントできないユーザーは、public オプションを使ってファイルシステムを共有するだけで、WebNFS アクセスを使用できるようになります。
すでに公開されているファイルシステムは、public オプションを使用するのに適しています。たとえば、ftp アーカイブの最上位のディレクトリや Web サイトのメイン URL ディレクトリなどです。
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 を読み込んだ場合は、前のトランザクションで使用した URL サービスのタイプが使われることがあります。NFS URL を使用した後に、HTTP URL に対する参照が読み込まれることがあります。その場合、次のページは、NFS プロトコルではなく HTTP プロトコルを使って読み込まれます。

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

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

autofs 管理作業の概要

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

autofs 管理の作業マップ

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

表 14–5 autofs 管理の作業マップ


作業	説明	参照先
autofs を起動する	システムをリブートすることなくオートマウントサービスを起動する	オートマウンタの起動方法
autofs を停止する	他のネットワークサービスを使用不可にすることなくオートマウントサービスを停止する	オートマウンタの停止方法
autofs でファイルシステムにアクセスする	オートマウントサービスを使ってファイルシステムにアクセスする	オートマウンタによるマウント
autofs マップを修正する	他のマップをリストするために使用されるマスターマップの修正を行う手順	マスターマップの修正方法
	ほとんどのマップに対して使用される間接マップの修正を行う手順	間接マップの修正方法
	クライアント上のマウントポイントとサーバー間の直接の関係が必要な場合に使用される直接マップの修正を行う手順	直接マップの修正方法
非 NFS ファイルシステムにアクセスするために autofs マップを修正する	CD-ROM アプリケーション用のエントリで autofs マップを設定する手順	autofs で CD-ROM アプリケーションにアクセスする
	PC-DOS フロッピーディスク用のエントリで autofs マップの設定を行う手順	autofs で PC-DOS データフロッピーディスクにアクセスする方法
	autofs を使用して CacheFS ファイルシステムにアクセスする手順	CacheFS を使用して NFS ファイルシステムにアクセスする方法
`/home` を使用する	共通の `/home` マップの設定方法の例	`/home` の共通表示の設定
	複数のファイルシステムを参照する `/home` マップを設定する手順	複数のホームディレクトリファイルシステムで `/home` を設定する方法
新しい autofs マウントポイントを使用する	プロジェクト関連の autofs マップを設定する手順	`/ws` 下のプロジェクト関連ファイルを統合する方法
	異なるクライアントアーキテクチャをサポートする autofs マップを設定する手順	共有名前空間にアクセスするために異なるアーキテクチャを設定する方法
	異なるオペレーティングシステムをサポートする autofs マップを設定する手順	非互換のクライアントオペレーティングシステムのバージョンをサポートする方法
autofs でファイルシステムを複製する	フェイルオーバーしたファイルシステムへのアクセスを提供する	複数のサーバーを通じて共用ファイルを複製する方法
autofs でセキュリティ制限を使用する	ファイルへのリモート `root` アクセスを制限する一方でファイルシステムへのアクセスを提供する	autofs セキュリティ制限を適用する方法
autofs で公共ファイルハンドルを使用する	ファイルシステムのマウント時に公共ファイルハンドルの使用を強制する	autofs で公共ファイルハンドルを使用する方法
autofs で NFS URL を使用する	オートマウンタが使用できるように、NFS URL を追加する	autofs で NFS URL を使用する方法
autofs のブラウズ機能を無効にする	autofs マウントポイントが 1 つのクライアント上で自動的に生成されないように、ブラウズ機能を無効にする手順	1 つの NFS クライアントの autofs ブラウズ機能を完全に無効にする方法
	autofs マウントポイントがすべてのクライアント上で自動的に生成されないように、ブラウズ機能を無効にする手順	すべてのクライアントの autofs ブラウズ機能を無効にする方法
	特定の autofs マウントポイントがある 1 つのクライアント上で自動的に生成されないように、ブラウズ機能を無効にする手順	選択したファイルシステムの autofs ブラウズ機能を無効にする方法

マップの管理作業

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

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

表 14–6 autofs マップのタイプとその使用方法


マップのタイプ	使用方法
マスター	ディレクトリをマップに関連付ける
直接	autofs を特定のファイルシステム向けにする
間接	autofs をリファレンス指向のファイルシステム向けにする

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

表 14–7 マップの保守


ネームサービス	メソッド
ローカルファイル	テキストエディタ
NIS	`make` ファイル
NIS+	`nistbladm`

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

表 14–8 automount コマンドを実行する場合


マップのタイプ	`automount` を再実行するか否か
	追加または削除	修正
`auto_master`	`Y`	`Y`
`direct`	`Y`	`N`
`indirect`	`N`	`N`

マップの修正

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

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

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

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

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

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

役割については、『Solaris のシステム管理 (セキュリティサービス)』の「特権付きアプリケーションの使用」を参照してください。

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

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

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

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

間接マップの修正方法

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

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

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

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

直接マップの修正方法

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

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

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

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

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

他のユーザーがコンピュータ上でスーパーユーザーとして 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 など、削除可能な媒体上のファイルをマウントします。通常は、ボリュームマネージャを使って削除可能な媒体上のファイルをマウントすることになります。次の例では、autofs を利用してこのマウントがどのように行われるかを示します。ボリュームマネージャと autofs は同時に動作することができないため、まずボリュームマネージャを終了してから次に示すエントリを使用する必要があります。

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

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

注 –

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

スーパーユーザー、またはそれと同等の役割になります。

役割については、『Solaris のシステム管理 (セキュリティサービス)』の「特権付きアプリケーションの使用」を参照してください。

autofs マップを更新します。

次のような CD-ROM のファイルシステム用のエントリを追加します。
hsfs -fstype=hsfs,ro :/dev/sr0
マウントする CD-ROM 装置の名前が、コロンの後に続けて表示されます。

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

注 –

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

スーパーユーザー、またはそれと同等の役割になります。

役割については、『Solaris のシステム管理 (セキュリティサービス)』の「特権付きアプリケーションの使用」を参照してください。

autofs マップを更新します。

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

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

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

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

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

スーパーユーザー、またはそれと同等の役割になります。

役割については、『Solaris のシステム管理 (セキュリティサービス)』の「特権付きアプリケーションの使用」を参照してください。

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

任意のオートマウンタマップに 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` を設定する方法

スーパーユーザー、またはそれと同等の役割になります。

役割については、『Solaris のシステム管理 (セキュリティサービス)』の「特権付きアプリケーションの使用」を参照してください。

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

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

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 がさらにディスクスペースを必要とし、rusty 自身のホームディレクトリを他のサーバーに再配置する必要がある場合には、auto_home マップ内の rusty のエントリを新しい場所を反映するように変更することだけが必要になります。他のユーザーは、/home/rusty パスを継続して使用することができます。

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

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

/ws ディレクトリに対するエントリを、サイトの NIS または NIS+ の auto_master マップに追加します。
/ws auto_ws -nosuid
auto_ws マップが、/ws ディレクトリの内容を決定します。

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

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

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 マウントではなく、ループバックマウントを通じてのローカルファイルへの直接アクセスが提供されます。

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

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

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

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

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

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

ユーザーのコミュニティ識別を簡単にするため、autofs 間接マップを作成します。autofs 間接マップを /usr/local にマウントします。NIS (または NIS+) の auto_master マップ内で、次のエントリを設定します。
/usr/local auto_local -ro
なお、-ro マウントオプションは、クライアントがファイルやディレクトリのすべてに対して書き込みができないことを示します。

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

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

ディレクトリ構造は、次のようになります。
bin aa:/export/local/bin

(省略可能) 異なるアーキテクチャのクライアントを処理するため、autofs CPU 変数を加えて、エントリの変更を行います。
bin aa:/export/local/bin/$CPU
- SPARC クライアント – 実行可能ファイルを /export/local/bin/sparc に配置する
- x86 クライアント – 実行可能ファイルを /export/local/bin/i386 に配置する

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

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

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

次のようなマップエントリを作成します。
bin aa:/export/local/bin/$CPU$OSREL
SunOS 5.6 を動作させているクライアントについて、次のファイルシステムをエクスポートします。
- SPARC クライアント – /export/local/bin/sparc5.6 をエクスポートする
- x86 クライアント – 実行可能ファイルを /export/local/bin/i3865.6 に配置する

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

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

スーパーユーザー、またはそれと同等の役割になります。

役割については、『Solaris のシステム管理 (セキュリティサービス)』の「特権付きアプリケーションの使用」を参照してください。

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

すべての複製サーバーのリストを、コンマ区切りのリストとして、次のように作成します。
bin aa,bb,cc,dd:/export/local/bin/$CPU
autofs は、最も近いサーバーを選択します。サーバーが複数のネットワークインタフェースを持っている場合は、各インタフェースのリストを作成してください。autofs はクライアントに最も近接したインタフェースを選択し、NFS トラフィックの不必要なルーティングを避けるようにしています。

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

スーパーユーザー、またはそれと同等の役割になります。

役割については、『Solaris のシステム管理 (セキュリティサービス)』の「特権付きアプリケーションの使用」を参照してください。

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 で公共ファイルハンドルを使用する方法

スーパーユーザー、またはそれと同等の役割になります。

役割については、『Solaris のシステム管理 (セキュリティサービス)』の「特権付きアプリケーションの使用」を参照してください。

autofs マップに、次のようなエントリを作成します。
/usr/local -ro,public bee:/export/share/local
public オプションは、公共ハンドルの使用を強制します。NFS サーバーが公共ファイルハンドルをサポートしない場合、マウントは失敗します。

autofs で NFS URL を使用する方法

スーパーユーザー、またはそれと同等の役割になります。

役割については、『Solaris のシステム管理 (セキュリティサービス)』の「特権付きアプリケーションの使用」を参照してください。

次のような 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 ブラウズ機能を完全に無効にする方法

NFS クライアント上で、スーパーユーザー、またはそれと同等の役割になります。

役割については、『Solaris のシステム管理 (セキュリティサービス)』の「特権付きアプリケーションの使用」を参照してください。

次のいずれかの手順を実行します。
1. (省略可能) Solaris 9 以前のリリースを使用している場合は、-n オプションを起動スクリプトに追加します。
  
  root として、/etc/init.d/autofs スクリプトを編集して、automountd デーモンを開始する行に -n オプションを次のように追加します。
  /usr/lib/autofs/automountd -n \ < /dev/null> /dev/console 2>&1 # start daemon

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

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

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

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

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

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

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

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

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

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

優先するローカルファイルエントリについては、ネームサービススイッチファイル内のエントリがネームサービスの前に files をリストする必要があります。たとえば：
automount: files nisplus
これは、標準的な Solaris にインストールされるデフォルトの構成を示します。

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

名前空間内のエントリに優先するローカルファイルへの追加については、+auto_master エントリが /net の下に移動されている必要があります。
# Master map for automounter # /net -hosts -nosuid /home auto_home /xfn -xfn +auto_master
標準的な構成では、+auto_master エントリがファイルの先頭に配置されます。このように配置することにより、ローカルな変更が使用されなくなります。

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

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

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

NFS の障害追跡の方法

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

上記の項目をチェックする過程で、ネットワークの他の部分が機能していないことに気づく場合があります。たとえば、ネームサービスやネットワークのハードウェアが機能していない場合があります。複数のネームサービスでのデバッグ手順については、『Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)』で説明しています。また、上記の項目をチェックする過程で、クライアント側には問題がないことが判明することもあります。たとえば、作業領域のすべてのサブネットから、少なくとも 1 つの障害が発生したことが通知された場合などです。このような場合は、問題がサーバーかサーバー周辺のネットワークハードウェアで発生しているとみなし、クライアントではなく、サーバーでデバッグを開始する必要があります。

NFS クライアントの接続性を確認する方法

クライアントから NFS サーバーに到達できることを確認します。クライアントで次のコマンドを入力します。
% /usr/sbin/ping bee bee is alive
コマンドを入力した結果、サーバーが動作していることがわかったら、NFS サーバーをリモートで確認します。NFS サーバーをリモートで確認する方法を参照してください。

クライアントからサーバーに到達できない場合は、ローカルネームサービスが動作していることを確認します。

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

ネームサービスが実行されている場合は、クライアントが正しいホスト情報を受け取るために次のように入力します。
% /usr/bin/getent hosts bee 129.144.83.117 bee.eng.acme.com

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

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

別のクライアントからサーバーに到達できる場合は、ping コマンドを使って元のクライアントとローカルネット上の他のシステムとの接続性を確認します。

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

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

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

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

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 サービスを再起動する方法を参照してください。

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

クライアント上で、次のコマンドを入力し、サーバーからの UDP NFS 接続をテストします。
% /usr/bin/rpcinfo -u bee nfs program 100003 version 2 ready and waiting program 100003 version 3 ready and waiting
サーバーが動作している場合、プログラムとバージョン番号が表示されます。-t オプションを使用すると、TCP 接続を検査できます。上記コマンドでエラーになる場合は、サーバーで NFS サービスを確認する方法に進んでください。

サーバーで 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 サービスを確認する方法に進んでください。

ローカル autofs サービスを使用していた場合は、そのサービスを確認します。
% cd /net/wasp
/net か /home マウントポイントのうち、適切に動作する方を確認します。エラーになる場合は、次のコマンドを root としてクライアントから入力し、autofs サービスを再起動します。
# /etc/init.d/autofs stop # /etc/init.d/autofs start

サーバーのファイルシステムの共有が正常に行えることを確認します。
% /usr/sbin/showmount -e bee /usr/src eng /export/share/man (everyone)
サーバーの項目とローカルマウントエントリにエラーがないことをチェックします。名前空間も確認します。この例で最初のクライアントが eng ネットグループの中にない場合、/usr/src ファイルシステムはマウントできません。

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

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

スーパーユーザー、またはそれと同等の役割になります。

役割については、『Solaris のシステム管理 (セキュリティサービス)』の「特権付きアプリケーションの使用」を参照してください。

サーバーがクライアントに到達できることを確認します。
# ping lilac lilac is alive

サーバーからクライアントに到達できない場合は、ローカルネームサービスが動作していることを確認します。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

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

次のコマンドを入力し、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 がハングしている場合は、サーバーをリブートするか、rpcbind をウォームスタートする方法に示す作業を行なってください。

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

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

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

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

スーパーユーザー、またはそれと同等の役割になります。

役割については、『Solaris のシステム管理 (セキュリティサービス)』の「特権付きアプリケーションの使用」を参照してください。

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

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

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

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

実行中の処理があるために NFS サーバーをリブートできなかった場合に、RPC を使用するすべてのサービスを再起動することなく rpcbind を再実行できます。この手順に従ってウォームスタートを完了します。

スーパーユーザー、またはそれと同等の役割になります。

役割については、『Solaris のシステム管理 (セキュリティサービス)』の「特権付きアプリケーションの使用」を参照してください。

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

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

以下の例では、送信するシグナルは term で、プログラムの PID は 115 です (kill(1) のマニュアルページを参照)。このコマンドより、rpcbind は /tmp/portmap.file と /tmp/rpcbind.file に現在登録されているサービスのリストを作成します。
# kill -s term 115
注 –
-s term オプションを使用して rpcbind プロセスを終了させないと、rpcbind のウォームスタートを完了できません。その場合は、サーバーをリブートすることによってサービスを再開する必要があります。

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

次のコマンドを実行し、オプションを確認します。
% 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 コマンドを使用しても、一部のオプションの情報は表示されませんが、オプションを確認するにはこれが最も正確な方法です。

/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 により (1 つまたは複数) 指定されます。サーバー上のエクスポートテーブルを確認してください。

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: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 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.6 より前の Solaris では、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

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

error checking lock file : error

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

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 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 バージョン 2 プロトコルでは、大規模ファイルを処理できません。大規模ファイルを扱う必要がある場合は、バージョン 3 を使用してください。

NFS server hostname not responding still trying

ファイル関連の作業中にプログラムがハングすると、NFS サーバーは停止します。このメッセージは、NFS サーバー (hostname) がダウンしているか、サーバーかネットワークに問題があることを示すものです。フェイルオーバー機能を使用している場合、hostname はサーバー名のリストになります。NFS クライアントの接続性を確認する方法を参照してください。

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

第 15 章ネットワークファイルシステムへのアクセス (リファレンス)

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

NFS ファイル

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

表 15–1 NFS ファイル


ファイル名	機能
`/etc/default/fs`	ローカルファイルシステムにおけるデフォルトファイルシステムのタイプを示す
`/etc/default/nfs`	`lockd` および `nfsd` の構成情報を示す
`/etc/default/nfslogd`	NFS サーバーログデーモン (`nfslogd`) の構成情報を示す
`/etc/dfs/dfstab`	共有するローカルリソースを示す
`/etc/dfs/fstypes`	リモートファイルシステムにおけるデフォルトファイルシステムのタイプを示す
`/etc/dfs/sharetab`	共有されるローカルとリモートのリソースを示す。`sharetab(4)` のマニュアルページを参照。このファイルは編集しないこと
`/etc/mnttab`	自動マウントしたディレクトリを含む、現在マウントしているファイルシステムを示す。`mnttab(4)` のマニュアルページを参照。このファイルは編集しないこと
`/etc/netconfig`	トランスポートプロトコルのリスト。このファイルは編集しないこと
`/etc/nfs/nfslog.conf`	NFS サーバーログのための一般的な構成情報を示す
`/etc/nfs/nfslogtab`	`nfslogd` によるログ後処理のための情報を示す。このファイルは編集しないこと
`/etc/nfssec.conf`	NFS のセキュリティサービスのリスト
`/etc/rmtab`	NFS クライアントがリモートでマウントしたファイルシステムを示す。`rmtab(4)` のマニュアルページを参照。このファイルは編集しないこと
`/etc/vfstab`	ローカルにマウントするファイルシステムを定義する。`vfstab(4)` のマニュアルページを参照

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

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

`/etc/default/nfslogd` ファイル

このファイルは、NFS サーバーログ機能を使用するときに使用されるいくつかのパラメータを定義します。次のパラメータを定義することができます。

CYCLE_FREQUENCY: ログファイルを元の状態に戻す前に経過させる必要がある時間数を決めるパラメータです。デフォルト値は 24 時間です。このパラメータはログファイルが大きくなり過ぎないように使用します。
IDLE_TIME: nfslogd が、バッファーファイル内にさらに情報があるかどうかを確認するまでに休眠しなければならない秒数を設定するパラメータです。このパラメータは、構成ファイルの確認頻度も決定します。このパラメータと MIN_PROCESSING_SIZE によりバッファーファイルの処理頻度が決まります。デフォルト値は 300 秒です。この数値を増加させると、確認の回数が減ってパフォーマンスが向上します。
MAPPING_UPDATE_INTERVAL: ファイルハンドルパスマッピングテーブル内でレコードを更新する間隔を秒数で指定します。デフォルト値は 86400 秒つまり 1 日です。このパラメータを使用すると、ファイルハンドルパスマッピングテーブルを常時更新しないで最新の状態に保つことができます。
MAX_LOG_PRESERVE: 保存するログファイル数を決めます。デフォルト値は 10 です。
MIN_PROCESSING_SIZE: バッファーファイルが処理してログファイルに書き込むための最小限のバイト数を設定します。このパラメータと IDLE_TIME によりバッファーファイルの処理頻度が決まります。デフォルト値は 524,288 バイトです。この数値を大きくするとバッファーファイルの処理回数が減ってパフォーマンスが向上します。
PRUNE_TIMEOUT: ファイルハンドルパスマッピングレコードを中断して除去できるようになるまでに経過しなければならない時間数を選択するパラメータです。デフォルト値は 168 時間、つまり 7 日間です。
UMASK: nfslogd によって作成されるログファイルのファイルモード生成マスクを指定します。デフォルト値は 0137 です。

`/etc/nfs/nfslog.conf` ファイル

このファイルは nfslogd で使用するログのパス、ファイル名、およびタイプを定義します。各定義はタグと関連付けられています。NFS サーバーのログを開始するためには、各ファイルシステムについてタグを付ける必要があります。広域タグはデフォルト値を定義します。必要に応じて、各タグに、次のパラメータを使用することができます。

defaultdir=path: ログファイルのデフォルトのディレクトリパスを指定するパラメータです。特に指定しない限り、デフォルトは /var/nfs です。
log=path/filename: ログファイルのパスとファイル名を指定するパラメータです。デフォルトは /var/nfs/nfslog です。
fhtable=path/filename: ファイルハンドルパスデータベースのパスとファイル名を選択するパラメータです。デフォルトは /var/nfs/fhtable です。
buffer=path/filename: バッファーファイルのパスとファイル名を決定するパラメータです。デフォルトは /var/nfs/nfslog_workbuffer です。
logformat=basic| extended: ユーザーから読み取り可能なログファイルを作成するときに使用するフォーマットを選択します。基本フォーマットは、ftpd デーモンと同様なログファイルが作成されます。拡張フォーマットは、より詳細に表示されます。

パスが指定されていない場合は、defaultdir が定義するパスが使用されます。絶対パスを使用すると defaultdir を無効にすることができます。

ファイルを識別しやすくするために、ファイルを別々のディレクトリに入れておきます。次に、必要な変更の例を示します。

% cat /etc/nfs/nfslog.conf
#ident  "@(#)nfslog.conf        1.5     99/02/21 SMI"
#
  .
  .
# NFS server log configuration file.
#

global  defaultdir=/var/nfs \
        log=nfslog fhtable=fhtable buffer=nfslog_workbuffer

publicftp log=logs/nfslog fhtable=fh/fhtables buffer=buffers/workbuffer

この例では、log=publicftp と共有するファイルはすべて、次の値を使用します。

デフォルトのディレクトリは /var/nfs である
ログファイルは、/var/nfs/logs/nfslog* に保存される
ファイルハンドルパスデータベーステーブルは、/var/nfs/fh/fhtables に保存される
バッファーファイルは、/var/nfs/buffers/workbuffer に保存される

手順については、NFS サーバーログを有効にする方法を参照してください。

NFS デーモン

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

この節では、次のデーモンについて説明します。

`automountd` デーモン

このデーモンは autofs サービスからのマウントおよびデマウント要求を処理します。このコマンドの構文は次のとおりです。

automountd [ -Tnv ] [ -D name= value ]

このコマンドは、次のように動作します。

-T は、トレースを有効にする
-n は、すべての autofs ノード上で、ブラウズを無効にする
-v は、コンソールへのすべての状態メッセージを記録する
-D name= value は、name によって示されたオートマウントマップ変数の値を value に置き換える

自動マウントマップのデフォルト値は /etc/auto_master です。障害追跡には -T オプションを使用してください。

`lockd` デーモン

このデーモンは NFS ファイルのレコードロックをサポートします。lockd デーモンは、ネットワークロックマネージャ (NLM) プロトコルについて、クライアントとサーバー間の RPC 接続を管理します。通常は、パラメータを指定しないで起動します。使用できるオプションは 3 つあります。lockd(1M) のマニュアルページを参照してください。これらのオプションは、コマンド行からも、/etc/default/nfs 内の任意の文字列を編集することによっても使用することができます。 /etc/default/nfs を変更すると、システムを再起動してもその変更は維持されます。この機能は、Solaris 9 リリースでのみサポートされています。その他の Solaris リリースでこれらの変更を維持するには、/etc/init.d/nfs.client を変更します。

/etc/default/nfs に LOCKD_GRACE_PERIOD=graceperiod パラメータを追加すると、クライアントがサーバーのリブート後にロックを再要求する秒数を選択できます。NFS サーバーはこの秒数の間、それまでのロックの再要求処理しか実行しません。サービスに対する他の要求は、この時間が経過するまで待たされます。このオプションは NFS サーバーの応答性に関係するため、NFS サーバーでしか変更できません。デフォルト値は 45 秒です。この値を小さくすることにより、NFS クライアントは、サーバーのリブート後に、より迅速に処理を再開できます。ただし、この値を小さくすると、クライアントがすべてのロックを復元できない可能性が増します。デーモンに -g graceperiod オプションを指定して開始すると、コマンド行から同じ動作を実行することができます。

/etc/default/nfs に LOCKD_RETRANSMIT_TIMEOUT=timeout パラメータを追加すると、ロックの要求をリモートサーバーに再転送するまでの秒数を選択できます。このオプションは NFS クライアントのサービスに関係します。デフォルト値は 15 秒です。この値を小さくすると、トラフィックの多いネットワーク上の NFS クライアントに対する応答時間を改善できます。ただし、ロック要求が増えることによってサーバーの負荷が増す可能性があります。デーモンに -t timeout オプションを指定して開始すると、コマンド行から同じパラメータを使用できます。

/etc/default/nfs に LOCKD_SERVERS=nthreads パラメータを追加すると、サーバーが同時に処理できる各接続ごとのスレッドの最大数を指定できます。この値は、NFS サーバーに対して予想される負荷に基づいて決定してください。デフォルト値は 20 です。TCP を使用する各 NFS クライアントは、NFS サーバーとの間で 1 つの接続を使用するため、各クライアントは、サーバー上で、最大 20 のスレッドを同時に使用することができます。UDP を使用するすべての NFS クライアントは、NFS サーバーと 1 つの接続を共有します。その場合、UDP 接続が使用できるスレッドの数を増やさなければならないことがあるかもしれません。各 UDP クライアントには、少なくとも 2 つのスレッドを許可します。ただし、この数は、クライアントの負荷により違います。そのため、クライアントごとに 2 つのスレッドを許可しても、十分ではない場合があります。多くのスレッドを使用する場合の不利な点は、これらのスレッドを使用すると、NFS サーバー上で使用するメモリーの容量が増えるという点です。ただし、スレッドを使用しない場合は、nthreads の値を増やしても影響がありません。デーモンに nthreads オプションを指定して開始すると、コマンド行から同じパラメータを使用できます。

`mountd` デーモン

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

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

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

`nfsd` デーモン

これは、他のクライアントからのファイルシステム要求を処理するデーモンです。このコマンドに対してはいくつかのオプションを指定できます。オプションをすべて確認するには nfsd(1M) のマニュアルページを参照してください。これらのオプションは、コマンド行からも、/etc/default/nfs 内の任意の文字列を編集することによっても使用することができます。 /etc/default/nfs を変更すると、システムをリブートしてもその変更は維持されます。この機能は、Solaris 9 リリースでのみサポートされています。他のリリースで、これらの変更を維持するには、/etc/init.d/nfs.server を変更します。

/etc/default/nfs に NFSD_LISTEN_BACKLOG=length パラメータを追加すると、接続型トランスポートを使用した NFS および TCP の接続キューの長さを設定できます。デフォルト値は 32 エントリです。nfsd に -l オプションを指定して開始すると、コマンド行から同じ項目を選択できます。

/etc/default/nfs に NFSD_MAX_CONNECTIONS=#_conn パラメータを追加すると、接続型トランスポートごとの最大接続数を選択できます。#_conn のデフォルト値はありません。コマンド行から -c #_conn オプションを指定してデーモンを開始すると、同じパラメータを使用できます。

/etc/default/nfs に NFSD_SERVER=nservers パラメータを追加すると、サーバーが一度に処理する要求の最大数を選択できます。デフォルト値は 1 ですが、起動スクリプトでは 16 が選択されます。コマンド行から nservers オプションを指定してnfsd を開始すると、同じように最大数を選択できます。

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

`nfslogd` デーモン

このデーモンは実行された処理のログ機能を提供します。NFS オペレーションは、/etc/default/nfslogd で定義した構成オプションに基づいてサーバーのログに記録されます。NFS サーバーのログ機能がオンになると、選択されたファイルシステム上でのすべての RPC 操作の記録がカーネルによりバッファーファイルに書き込まれます。次に nfslogd がこれらの要求を後処理します。ログインおよび IP アドレスへの UID をホスト名に割り当てやすくするために、ネームサービススイッチが使用されます。識別されたネームサービスで一致するものが見つからない場合は、その番号が記録されます。

パス名へのファイルハンドルの割り当ても nfslogd により行われます。このデーモンは、ファイルハンドルパスマッピングテーブル内でこれらの割り当てを追跡します。/etc/nfs/nfslogd で識別される各タグについて 1 つのマッピングテーブルが存在します。後処理の後に、レコードが ASCII ログファイルに書き込まれます。

`statd` デーモン

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

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

# ls -l /var/statmon/sm
lrwxrwxrwx   1 daemon          11 Apr 29 16:32 ipv4.192.9.200.1 -> myhost
lrwxrwxrwx   1 daemon          11 Apr 29 16:32 ipv6.fec0::56:a00:20ff:feb9:2734 -> v6host
--w-------   1 daemon          11 Apr 29 16:32 myhost
--w-------   1 daemon          11 Apr 29 16:32 v6host

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

NFS コマンド

次のコマンドは、スーパーユーザーとして実行しなければ、十分な効果がでません。しかし情報の要求は、すべてのユーザーが行うことができます。

`automount` コマンド

このコマンドは autofs マウントポイントをインストールし、オートマスターファイル内の情報を各マウントポイントに関連付けます。このコマンドの構文は次のとおりです。

automount [ -t duration ] [ - v ]

-t duration はファイルシステムがマウントされた状態でいる時間 (秒) で、-v は詳細形式モードを選択します。詳細形式モードでこのコマンドを実行すると障害追跡が容易になります。

継続時間の値は、特に設定しないと 5 分に設定されます。通常はこの値が適切です。しかし、自動マウントされたファイルシステムの多いシステムでは、この値を増やす必要がある場合もあります。特に、サーバーを多くのユーザーが使用中の場合は、自動マウントされたファイルシステムを 5 分ごとにチェックするのは能率的でない場合があります。autofs ファイルシステムは 1800 秒 (30 分) ごとにチェックする方が適しています。5 分おきにファイルシステムのマウントを解除しないと、/etc/mnttab が大きくなることがあります。df が /etc/mnttab にある各エントリをチェックした時の出力を減らすには、-F オプション (df(1M) マニュアルページを参照) または egrep を使用して、df の出力にフィルタをかけます。

この継続時間を調節すると、オートマウンタマップへの変更が反映される速さを変更できるということも考慮すべきです。変更はファイルシステムがアンマウントされるまでは見ることができません。オートマウンタマップの変更方法については、マップの修正を参照してください。

`clear_locks` コマンド

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

# clear_locks tulip

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

# clear_locks -s bee

注意 –

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

`mount` コマンド

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

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

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

注意 –

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

NFS ファイルシステムでの `mount` オプション

NFS ファイルシステムをマウントするときに -o フラグの後に指定できるオプションの一部を以下に示します。オプションの完全なリストについては、 mount_nfs(1M) のマニュアルページを参照してください。

bg|fg

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

forcedirectio

このオプションは大規模ファイル上で連続した読み取りをする際にパフォーマンスを向上させます。データは直接ユーザーバッファにコピーされます。クライアント上のカーネル内ではキャッシュへの書き込みは行なわれません。この機能はデフォルトではオフです。このオプションの使用例については、mount コマンドの使用を参照してください。

largefiles

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

nolargefiles

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

public

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

rw|ro

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

sec=mode

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

表 15–2 NFS セキュリティモード


モード	選択した認証サービス
`krb5`	Kerberos バージョン 5
`krb5i`	Kerberos バージョン 5 で完成性を指定
`krb5i`	Kerberos バージョン 5 で機密性を指定
`none`	認証なし
`dh`	Diffie-Hellman (DH) 認証
`sys`	UNIX の標準認証

soft|hard

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

`mount` コマンドの使用

次の例を参照してください。

NFS バージョン 2 またはバージョン 3 では、次のコマンドはどちらもサーバー beeから NFS ファイルシステムを読み取り専用としてマウントします。
# mount -F nfs -r bee:/export/share/man /usr/man
# mount -F nfs -o ro bee:/export/share/man /usr/man
NFS バージョン 2 またはバージョン 3 では、次のコマンドは -O オプションを使用しているため、すでに /usr/man がマウントされている場合でも、強制的にマニュアルページをサーバー bee からローカルシステムにマウントします。次を参照してください。
# mount -F nfs -O bee:/export/share/man /usr/man
NFS バージョン 2 またはバージョン 3 では、次のコマンドはクライアント側フェイルオーバー機能を使用します。
# mount -F nfs -r bee,wasp:/export/share/man /usr/man
注 –
コマンド行から使用する場合、リスト内のサーバーがサポートしている NFS プロトコルは同じバージョンでなければなりません。コマンド行から mount を実行するときは、バージョン 2 とバージョン 3 のサーバーを混在させないでください。autofs を実行するときは、これらのサーバーを混在させることができます。autofs により、バージョン 2 またはバージョン 3 のサーバーの最適な組み合わせが自動的に選択されます。
次に、NFS バージョン 2 またはバージョン 3 において、mount コマンドに NFS URL を使用する例を示します。
# mount -F nfs nfs://bee//export/share/man /usr/man

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

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

`umount` コマンド

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

-f オプションを指定すると、使用中のファイルシステムがアンマウントされます。このオプションを使用して、マウントできないファイルシステムのマウントを試みたためにハングしたクライアントを復帰させることができます。

注意 –

ファイルシステムのアンマウントを強制的に解除すると、ファイルへの書き込み中だった場合には、データを損失することがあります。

`umount` コマンドの使用

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

# umount /usr/man

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

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

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

`mountall` コマンド

このコマンドを使用すると、ファイルシステムテーブルに指定したすべてのファイルシステム、または特定グループのファイルシステムをマウントできます。このコマンドを実行すると、次の操作を実行することができます。

-F FSType オプションを使用して、ファイルシステムのタイプを選択する
-r オプションを使用して、ファイルシステムテーブル中にリストされたリモートファイルシステムをすべて選択する
-l オプションを使用して、ローカルファイルシステムをすべて選択する

NFS ファイルシステムタイプと指定されているファイルシステムはすべてリモートファイルシステムなので、これらのオプションは余分な指定になることがあります。詳細は、mountall(1M) のマニュアルページを参照してください。

`mountall` コマンドの使用

次の 2 つの例を実行すると、同じ結果になります。

# mountall -F nfs

# mountall -F nfs -r

`umountall` コマンド

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

`umountall` コマンドの使用

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

# umountall -r

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

# umountall -h bee

`share` コマンド

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

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

すでに共有している大規模なファイルシステムの一部であるファイルシステムを共有することはできません。たとえば、/usr および /usr/local が同じディスクスライスにある場合は、/usr または /usr/local を共有できます。ただし、異なる共有オプションを指定してこれらのディレクトリを共有するには、/usr/local を別のディスクスライスに移動する必要があります。

読み取り専用で共有しているファイルシステムに、読み取りと書き込みが可能な状態で共有しているファイルシステムのファイルハンドルでアクセスすることができます。ただし、両方のファイルシステムが同じディスクスライスにある必要があります。より安全にこれらのファイルシステムを使用するには、読み取りと書き込みが設定されているファイルシステムを、読み取り専用で共有しているファイルシステムとは別のパーティションまたはディスクスライスに配置します。

非ファイルシステム用 `share` オプション

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

rw|ro: pathname に指定したファイルシステムを、読み取りと書き込みの両方が可能な状態で共有するか、読み取り専用で共有するかを指定します。
rw=accesslist: ファイルシステムは、リストに記述されているクライアントに対してだけ、読み取り書き込みの両方が可能な状態で共有されます。それ以外の要求は拒否されます。accesslist に定義されるクライアントのリストは、Solaris 2.6 から拡張されました。詳細については、share コマンドを使ってアクセスリストを設定するを参照してください。このオプションは -ro オプションよりも優先されます。

NFS 用 `share` オプション

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

aclok

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

注 –

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

anon=uid

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

index=filename

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

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

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

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

log=tag

このオプションは、ファイルシステム用の NFS サーバーレコード構成情報の入った /etc/nfs/nfslog.conf 内のタグを指定します。NFS サーバーログ機能を使用可能にするにはこのオプションを選択する必要があります。

nosuid

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

public

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

root=accesslist

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

注意 –

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

sec=mode[:mode ]

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

window=value

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

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

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

次のコマンドでは、rose と lilac では読み取りと書き込みの両方のアクセスが認められますが、その他では、読み取りだけが許可されます。

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

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

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

注 –

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

複数のクライアントが 1 つのファイルシステムを共有するには、同じ行にすべてのオプションを入力する必要があります。同じオブジェクトに対して share コマンドを何度も実行しても、最後に実行されたコマンドだけが有効になります。以下のコマンドでは、3 つのクライアントシステムで読み取りと書き込みができますが、rose と tulip では、ファイルシステムに root でアクセスできます。

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

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

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

デフォルトのセキュリティモードは UNIX 認証ですが、-sec オプションを使用している場合、この UNIX 認証は含まれなくなります。そのため、UNIX 認証を他の認証メカニズムとともに使用する場合は、-sec=sys オプションを指定する必要があります。

実際のドメイン名の前にドットを付けると、アクセスリスト中で DNS ドメイン名を使用できます。ドットの後の文字列はドメイン名です。完全指定のホスト名ではありません。次のエントリは、マウントから eng.sun.com ドメイン内のすべてのホストへのアクセスを許可するためのものです。

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

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

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

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

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

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

# share -f nfs -o ro=@eng/17 /export/share/man
# share -F nfs -o ro=@129.144.132/17 /export/share/man

この例で、「/17」はアドレスの先頭から 17 ビットがマスクとして使用されることを表します。CIDR の詳細は、RFC 1519 を参照してください。

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

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

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

`unshare` コマンド

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

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

`unshare` コマンドの使用

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

# unshare /usr/src

`shareall` コマンド

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

`shareall` コマンドの使用

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

# shareall /etc/dfs/special_dfstab

`unshareall` コマンド

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

`unshareall` コマンドの使用

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

# unshareall -F nfs

`showmount` コマンド

このコマンドは、次のいずれかを表示します。

NFS サーバーから共有している、リモートマウントされたファイルシステムを持つすべてのクライアント
クライアントによってマウントされたファイルシステムのみ
共有されたファイルシステムおよびクライアントのアクセス情報

コマンドは、次のような構文になります。

showmount [ -ade ] [ hostname ]

-a: すべてのリモートマウントのリストを出力する。各エントリには、クライアント名とディレクトリが含まれる
-d: クライアントがリモートマウントしたディレクトリのリストを表示する
-e: 共有されているファイル、またはエクスポートされたファイルのリストを表示する
hostname: 表示する情報の取得元 NFS サーバーを指定する

hostname を指定しないと、ローカルホストを入力するように要求されます。

`showmount` コマンドの使用

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

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

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

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

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

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

`setmnt` コマンド

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

その他のコマンド

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

`nfsstat` コマンド

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

nfsstat [ -cmnrsz ]

-c: クライアント側の情報を表示する
-m: NFS マウントされた各ファイルシステムの統計を表示する
-n: クライアント側とサーバー側の両方で、NFS の情報が表示されるように指定する
-r: RPC 統計を表示する
-s: サーバー側の情報を表示する
-z: 統計をゼロに設定するように指定する

コマンド行にオプションを指定しないと、-cnrs が使用されます。

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

`nfsstat` コマンドの使用

# nfsstat -s

Server rpc:
Connection oriented:
calls      badcalls   nullrecv   badlen      xdrcall    dupchecks  dupreqs
11420263   0          0          0           0          1428274    19
Connectionless:
calls      badcalls   nullrecv   badlen      xdrcall    dupchecks  dupreqs
14569706   0          0          0           0          953332     1601

Server nfs:
calls      badcalls
24234967   226
Version 2: (13073528 calls)
null       getattr    setattr    root        lookup     readlink   read
138612 1%  1192059 9% 45676 0%   0 0%        9300029 71% 9872 0%   1319897 10%
wrcache    write      create     remove      rename     link       symlink
0 0%       805444 6%  43417 0%   44951 0%    3831 0%    4758 0%    1490 0%
mkdir      rmdir      readdir    statfs
2235 0%    1518 0%    51897 0%   107842 0%
Version 3: (11114810 calls)
null       getattr    setattr    lookup      access     readlink   read
141059 1%  3911728 35% 181185 1% 3395029 30% 1097018 9% 4777 0%   960503 8%
write      create     mkdir      symlink     mknod      remove     rmdir
763996 6%  159257 1%  3997 0%    10532 0%    26 0%      164698 1%  2251 0%
rename     link       readdir    readdirplus fsstat     fsinfo     pathconf
53303 0%   9500 0%    62022 0%   79512 0%    3442 0%    34275 0%   3023 0%
commit    
73677 0%  

Server nfs_acl:
Version 2: (1579 calls)
null       getacl     setacl     getattr     access    
0 0%       3 0%       0 0%       1000 63%    576 36%   
Version 3: (45318 calls)
null       getacl     setacl    
0 0%       45318 100% 0 0%

このリストは、NFS サーバーの統計の例です。最初の 5 行は RPC に関するもので、残りの部分は NFS のアクティビティのレポートです。どちらの統計でも、badcalls または calls の平均値、および各週の calls の数がわかるので、問題を特定するのに役立ちます。badcalls 値は、クライアントからの不良メッセージ数を示しています。この値は、ネットワークのハードウェアに問題が発生したことを示す場合があります。

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

`pstack` コマンド

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

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

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

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

`rpcinfo` コマンド

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

rpcinfo [ -m | -s ] [ hostname ]

rpcinfo -T transport hostname [ progname ]

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

-m: rpcbind 処理の統計テーブルを表示する
-s: 登録されているすべての RPC プログラムを簡易リストで表示する
-T: 特定のトランスポートまたはプロトコルを使用するサービスの情報を表示する
-t: TCP を使用する RPC プログラムを検索する
-u: UDP を使用する RPC プログラムを検索する
transport: サービスに使用するトランスポートまたはプロトコルを選択する
hostname: 必要な情報の取得元のサーバーのホスト名を選択する
progname: 情報の取得対象の RPC プログラムを選択する

hostname を指定しないと、ローカルホスト名が使用されます。progname の代わりに RPC プログラム番号が使用できますが、ユーザーが覚えやすいのは番号よりも名前です。NFS バージョン 3 が実行されていないシステムでは、-s オプションの代わりに -p オプションを使用できます。

このコマンドを実行すると、次の項目を含むデータを生成することができます。

RPC プログラム番号
特定プログラムのバージョン番号
使用されているトランスポートプロトコル
RPC サービス名
RPC サービスの所有者

`rpcinfo` コマンドの使用

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

% rpcinfo -s bee |sort -n
   program version(s) netid(s)                         service     owner
    100000  2,3,4     udp6,tcp6,udp,tcp,ticlts,ticotsord,ticots rpcbind     superuser
    100001  4,3,2     ticlts,udp,udp6                  rstatd      superuser
    100002  3,2       ticots,ticotsord,tcp,tcp6,ticlts,udp,udp6 rusersd     superuser
    100003  3,2       tcp,udp,tcp6,udp6                nfs         superuser
    100005  3,2,1     ticots,ticotsord,tcp,tcp6,ticlts,udp,udp6 mountd      superuser
    100007  1,2,3     ticots,ticotsord,ticlts,tcp,udp,tcp6,udp6 ypbind      superuser
    100008  1         ticlts,udp,udp6                  walld       superuser
    100011  1         ticlts,udp,udp6                  rquotad     superuser
    100012  1         ticlts,udp,udp6                  sprayd      superuser
    100021  4,3,2,1   tcp,udp,tcp6,udp6                nlockmgr    superuser
    100024  1         ticots,ticotsord,ticlts,tcp,udp,tcp6,udp6 status      superuser
    100029  3,2,1     ticots,ticotsord,ticlts          keyserv     superuser
    100068  5         tcp,udp                          cmsd        superuser
    100083  1         tcp,tcp6                         ttdbserverd superuser
    100099  3         ticotsord                        autofs      superuser
    100133  1         ticots,ticotsord,ticlts,tcp,udp,tcp6,udp6 -           superuser
    100134  1         ticotsord                        tokenring   superuser
    100155  1         ticots,ticotsord,tcp,tcp6        smserverd   superuser
    100221  1         tcp,tcp6                         -           superuser
    100227  3,2       tcp,udp,tcp6,udp6                nfs_acl     superuser
    100229  1         tcp,tcp6                         metad       superuser
    100230  1         tcp,tcp6                         metamhd     superuser
    100231  1         ticots,ticotsord,ticlts          -           superuser
    100232  10        udp,udp6                         sadmind     superuser
    100234  1         ticotsord                        gssd        superuser
    100235  1         tcp,tcp6                         -           superuser
    100242  1         tcp,tcp6                         metamedd    superuser
    100249  1         ticots,ticotsord,ticlts,tcp,udp,tcp6,udp6 -           superuser
    300326  4         tcp,tcp6                         -           superuser
    300598  1         ticots,ticotsord,ticlts,tcp,udp,tcp6,udp6 -           superuser
    390113  1         tcp                              -           unknown
 805306368  1         ticots,ticotsord,ticlts,tcp,udp,tcp6,udp6 -           superuser
1289637086  1,5       tcp                              -           26069

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

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

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

`snoop` コマンド

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

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

-d device: ローカルネットワークのインタフェースを指定する
-o filename: 受信したすべてのパケットを指定したファイルに保存する
hostname: 特定のホストが送受信したパケットを表示する

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

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

`truss` コマンド

このコマンドを使用すると、プロセスがハングしたかどうかを確認できます。truss コマンドは、必ずプロセスの所有者、または root として実行してください。このコマンドに指定できるオプションは多数あります。truss(1) のマニュアルページを参照してください。以下で、このコマンドの構文を説明します。

truss [ -t syscall ] -p pid

-t syscall: 追跡するシステムコールを選択する
-p pid: 追跡するプロセスの PID を指定する

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

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

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

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

NFS サービスのしくみ

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

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

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

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

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

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

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

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

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

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

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

ファイルシステムがどのようにマウントされるか

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

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

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

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

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

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

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

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

public オプションと NFS URL – 公共ファイルハンドルが使用されます。公共ファイルハンドルがサポートされていないと、マウントは失敗します。

public オプションと通常のパス – 公共ファイルハンドルが使用されます。公共ファイルハンドルがサポートされていないと、マウントは失敗します。

NFS URL のみ – NFS サーバーでサポートされていれば、公共ファイルハンドルを使用します。公共ファイルハンドルを使用するとマウントが失敗する場合は、MOUNT プロトコルを使ってマウントします。

通常のパスのみ – 公共ファイルハンドルは使用しないでください。MOUNT プロトコルが使用されます。

クライアント側フェイルオーバー機能

クライアント側のフェイルオーバー機能を使用すると、NFS クライアントは同じデータを利用できる複数のサーバーを知ることができるため、現在のサーバーが使用不能になっても、ほかのサーバーに切り替えることができます。ファイルシステムが使用不能になる原因には次のものがあります。

ファイルシステムが接続しているサーバーのクラッシュ
サーバーの過負荷
ネットワーク障害

通常、このような場合のフェイルオーバー機能はユーザーにはわかりません。つまり、フェイルオーバー機能はクライアント上のプロセスを中断することなく実行されます。

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

同じ NFS マウント上では、CacheFS 機能とクライアント側のフェイルオーバー機能の両方は使用できません。CacheFS ファイルシステムは、それぞれについて追加情報が格納されています。この情報はフェイルオーバーの際に更新できないため、ファイルシステムをマウントするときにはフェイルオーバー機能と CacheFS のどちらか片方の機能しか使用できません。

各ファイルシステムについて用意すべき複製の数を決める要素はさまざまです。理想的には、サーバーを 2 台以上設置します。それぞれのサーバーが複数のサブネットをサポートする必要があります。これは、各サブネットに一意のサーバーを設置するよりもよい方法です。フェイルオーバー処理の際にはリストにある各サーバーが確認されます。そのため、サーバーの台数を増やすと、それぞれのマウント処理が遅くなります。

フェイルオーバー機能に関する用語

フェイルオーバー機能のプロセスを完全に理解するには、次の 2 つの用語を理解する必要があります。

フェイルオーバー – 複製されたファイルシステムをサポートしているサーバーのリストから、1 つのサーバーを選択するプロセス。通常、ソートされたリストの順番を元に、次のサーバーが応答するならばそのサーバーが使用される
再マッピング – 新しいサーバーを使用すること。クライアントは、正常な状態のときにリモートファイルシステム上のアクティブなファイルのそれぞれのパス名を格納する。再マッピング時には、そのパス名に基づいて新しいサーバー上のファイルを検出する

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

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

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

新しいバージョンのファイルをインストールするときは、あらかじめ古いバージョンのファイル名を変更する
クライアントによる使用が少ない夜間に更新を実行する
更新は小規模にとどめる
コピーの数を最小限にする

フェイルオーバー機能と NFS ロック

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

大規模ファイル

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

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

NFS サーバーログ機能のしくみ

NFS サーバーログ機能は NFS の読み取りと書き込み、およびこのファイルシステムを変更する操作の記録を提供します。このデータは情報へのアクセスを追跡するのに利用できます。さらに、この記録は、情報へのアクセスを測定する定量的な方法を提供します。

ログ機能が有効になっているファイルシステムにアクセスすると、カーネルが raw データをバッファーファイルに書き込みます。このデータには、次の内容が含まれています。

タイムスタンプ
クライアントの IP アドレス
要求者の UID
アクセスされているファイルまたはディレクトリオブジェクトのファイルハンドル
発生した処理のタイプ

nfslogd デーモンはこの raw データを、ログファイルに保存される ASCII レコードに変換します。使用可能なネームサービス機能が一致しているものを見つけると、その変換中に IP アドレスはホスト名に変更され、UID はログインに変更されます。ファイルハンドルはパス名にも変換されます。デーモンはファイルハンドルを追跡し、情報を別のファイルハンドルパステーブルに保存して、変換を完了します。このようにすると、ファイルハンドルにアクセスされるたびに、パスを識別し直す必要がなくなります。nfslogd をオフにするとファイルハンドルパステーブルのマッピングが変更されなくなるため、デーモンは常に実行させておく必要があります。

WebNFS サービスのしくみ

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

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

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

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

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

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

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

WebNFS セキュリティネゴシエーション機能のしくみ

Solaris 8 リリースから、WebNFS クライアントが WebNFS サーバーと、選択されたセキュリティメカニズムについてネゴシエーションできるようにする新しいプロトコルがあります。この新しいプロトコルは、セキュリティネゴシエーションマルチコンポーネントルックアップを使用しています。これは、WebNFS プロトコルの以前のバージョンで使用されていたマルチコンポーネントルックアップの拡張版です。

WebNFS クライアントは、公共ファイルハンドルを使って通常のマルチコンポーネントルックアップ要求を行うことにより、このプロセスを開始します。このクライアントには、サーバーがどのようにしてこのパスを保護しているかについての知識がないため、デフォルトのセキュリティメカニズムが使用されます。デフォルトのセキュリティメカニズムでは不十分な場合は、サーバーは AUTH_TOOWEAK エラーを返します。このメッセージは、そのデフォルトメカニズムが有効ではなく、クライアントはより強力なメカニズムを使用する必要があることを意味しています。

クライアントは、AUTH_TOOWEAK エラーを受信すると、サーバーに対してどのセキュリティメカニズムが必要か決定するように要求します。この要求が成功すると、サーバーは、指定されたパスに必要なセキュリティメカニズムの配列を返します。このセキュリティメカニズムの配列のサイズによっては、クライアントは完全な配列を得るためにさらに要求を出さなければならない場合があります。サーバーが WebNFS セキュリティネゴシエーションをサポートしていない場合は、この要求は失敗します。

要求が成功すると、WebNFS クライアントは、クライアントがサポートしている最初のセキュリティメカニズムを配列から選択します。その後、クライアントは、選択したセキュリティメカニズムを使用して、通常のマルチコンポーネントルックアップ要求を発行し、ファイルハンドルを獲得します。この後に続くすべての NFS 要求は、選択されたセキュリティメカニズムとファイルハンドルを使って出されます。

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

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

NFS によるブラウズでは CGI スクリプトは実行されません。したがって、CGI スクリプトを多用している Web サイトを含むファイルシステムは、NFS によるブラウズに適していない可能性があります。
ブラウザからは、形式の異なるファイルを扱うために別のビューアを起動されることがあります。NFS URL からそうしたファイルにアクセスすると、ファイル名からファイルタイプが判別できるならば外部のビューアが起動されます。ブラウザは、NFS URL が使用されている場合、標準の MIME タイプで決まっているファイル名拡張子をすべて認識します。WebNFS ソフトウェアは、ファイルの内容からファイルタイプを判別しません。したがって、ファイルタイプはファイル名の拡張子だけから判別されます。
NFS によるブラウズでは、サーバー側のイメージマップ (クリック可能なイメージ) は使用できません。ただし、クライアント側のイメージマップ (クリック可能なイメージ) は、場所とともに URL が定義されているため使用できます。文書サーバーからの応答は不要です。

Secure NFS システム

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

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

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

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

Secure RPC

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

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

RPC の認証機能は拡張が可能で、UNIX、DH、および KERB などのさまざまな認証システムを組み込むことができます。

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

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

DH 認証

DH 認証は、Data Encryption Standard (DES) と Diffie-Hellman 公開鍵暗号手法を使ってネットワーク上のユーザーとコンピュータの両方を認証します。DES は、標準の暗号化メカニズムです。Diffie-Hellman 公開鍵暗号手法は、2 つの鍵、つまり公開鍵と秘密鍵を持つ暗号方式です。公開鍵と秘密鍵は名前空間に格納されます。NIS では、これらのキーは public-key マップに保存されています。これらのマップにはすべての認証の候補ユーザーの公開鍵と秘密鍵が入っています。このマップの設定方法については、『Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)』を参照してください。

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

2 つのエージェントの現在時刻が一致している。
送信側と受信側が同じ暗号化鍵を使用する。

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

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

KERB 認証

Kerberos は、マサチューセッツ工科大学 (MIT) で開発された認証システムです。Kerberos での暗号化は DES に基づいています。Kerberos サポートは、現在では Secure RPC の一部としては供給されていませんが、Solaris 9 リリースには、サーバー側とクライアント側の実装が含まれています。Solaris 9 に実装されている Kerberos 認証については、『 Solaris のシステム管理 (セキュリティサービス)』の「SEAM について」を参照してください。

NFS での Secure RPC の使用

Secure RPC を使用する場合は、次の点に注意してください。

サーバーがクラッシュしたとき周囲に誰もいない場合 (停電の後など) には、システムに格納されていた秘密鍵はすべて消去されます。そのためどのプロセスからも、セキュリティ保護されたネットワークサービスにアクセスしたり NFS ファイルシステムをマウントしたりできません。リブート中の重要な処理は、通常 root として実行されます。そのため、root の秘密鍵を別に保存していればこれらのプロセスを実行できますが、その秘密鍵を復号化するパスワードを入力することはできません。keylogin -r を使用すると root の秘密鍵がそのまま /etc/.rootkey に格納され、keyserv がそれを読み取ります。
システムによっては、シングルユーザーモードで起動し、コンソールには root のログインシェルが表示されてパスワードの入力が要求されないことがあります。このような場合は、物理的なセキュリティが不可欠です。
ディスクレスコンピュータのブートは、完全に安全とはいえません。ブートサーバーになりすましてリモートコンピュータに対する秘密鍵の入力を記録するような、不正なカーネルを誰かがブートすることが考えられます。Secure NFS システムによって保護されているのはカーネルとキーサーバーが起動した後だけです。そうでないと、ブートサーバーからの応答を認証することができません。このような制限は重大な問題につながる可能性がありますが、この部分を攻撃するにはカーネルのソースコードを使用した高度な技術が必要です。また、不法行為の痕跡が残ります。つまり、ネットワークを通じてブートサーバーにポーリングすれば、不正なブートサーバーの場所がわかります。
ほとんどの setuid プログラムは root が所有者です。root の秘密鍵が /etc/.rootkey に格納されていれば、これらのプログラムは正常に動作します。しかし、ユーザーが所有者である setuid プログラムは動作しない可能性があります。たとえば、ある setuid プログラムの所有者が dave であり、ブート後 dave が 1 度もログインしていないとします。このプログラムはセキュリティ保護されたネットワークサービスにはアクセスできません。
リモートコンピュータに (login、rlogin、または telnet を使用して) ログインし、keylogin を使ってアクセスすると、自分のアカウントへのアクセスを許したことになります。これは、秘密鍵が相手側のコンピュータのキーサーバーに渡され、キーサーバーがその秘密鍵を格納したためです。このプロセスが問題になるのは、相手側のリモートコンピュータを信用できない場合だけです。しかし、疑いがある場合は、パスワードを要求するリモートコンピュータにはログインしないでください。代わりに NFS 環境を使用して、そのリモートコンピュータから共有されているファイルシステムをマウントします。または、keylogout を使ってキーサーバーから秘密鍵を消去します。
ホームディレクトリが共有されていて -o sec=dh オプションが指定されていると、リモートログインによって問題が生じる可能性があります。/etc/hosts.equiv ファイルまたは ~/.rhosts ファイルに、パスワードを要求するように設定されていない場合は、ログインが成功します。ただし、ローカルで認証されていないため、ユーザーは自分のホームディレクトリにアクセスできません。パスワードを要求され、入力したパスワードがネットワークパスワードと一致すれば、自分のホームディレクトリにアクセスできます。

autofs マップ

autofs は 3 種類のマップを使用します。

マスターマップ
直接マップ
間接マップ

autofs マスターマップ

auto_master マップでは、ディレクトリからマップへの関連付けを行います。このマップは、すべてのマップを指定するマスターリストであり、autofs が参照します。auto_master ファイルの内容の例を次に示します。

例 15–1 `/etc/auto_master` ファイルの例

# Master map for automounter 
# 
+auto_master 
/net            -hosts           -nosuid,nobrowse 
/home           auto_home        -nobrowse 
/-              auto_direct     -ro

この例では、汎用の auto_master ファイルに auto_direct マップのための追加が行われています。マスターマップ /etc/auto_master の各行は、次の構文に従っています。

mount-point map-name [ mount-options ]

mount-point

mount-point は、ディレクトリのフル (絶対) パス名です。このディレクトリが存在しない場合、可能ならば autofs はこのディレクトリを作成します。このディレクトリが存在し、しかも空ではない場合、マウントすることによってその内容が隠されます。この場合、autofs は警告を出します。

マウントポイントとして /- を指定すると、マップが直接マップであり、このマップ全体に関連付けられている特定のマウントポイントがないことを表します。

map-name

map-name 名は、位置に対する指示またはマウント情報を検出するために、autofs が使用するマップです。この名前がスラッシュ (/) で始まる場合、autofs はこの名前をローカルファイルとして解釈します。そうでない場合、autofs はネームサービススイッチ構成ファイル (/etc/nsswitch.conf) で指定される検索によりマウント情報を検索します。また、/net には、特別なマップを使用します。詳細は、マウントポイント /netを参照してください。

mount-options

mount-options は省略できます。map-name のエントリに他のオプションがある場合を除き、map-name で指定されたエントリのマウントに適用されるオプションをコンマで区切って並べます。特定のファイルシステムのマウントオプションについては、各ファイルシステムについてのマニュアルページを参照してください。たとえば、NFS 固有のマウントオプションについては、mount_nfs(1M) のマニュアルページを参照してください。 NFS 固有のマウントポイントの場合、bg (バックグラウンド) オプションと fg (フォアグラウンド) オプションは適用されません。

# で始まる行はコメント行です。その行のテキストの最後まですべて無視されます。

長い行を短い行に分割するには、行末にバックスラッシュ (\) を入力します。入力できる文字数の上限は 1024 です。

注 –

2 つのエントリで同じマウントポイントが使用されるときは、1 番目のエントリは automount コマンドが使用します。2 番目のエントリは無視されます。

マウントポイント `/home`

マウントポイント /home は、/etc/auto_home (間接マップ) に記述されたエントリがマウントされるディレクトリです。

注 –

autofs はすべてのコンピュータで動作し、デフォルトでは /net と /home (自動マウントされるホームディレクトリ) をサポートします。このデフォルトは、NIS ならば auto.master マップ、NIS+ ならば auto_master テーブルを使用して、またはローカルの /etc/auto_master ファイルを編集することによって変更できます。

マウントポイント `/net`

autofs は、特別なマップ -hosts 内の全エントリをディレクトリ /net の下にマウントします。これは hosts データベースだけを使用する組み込みマップです。たとえば、hosts データベースにあるコンピュータ gumbo が、ファイルシステムのどれかをエクスポートするとします。次のコマンドを入力すると、現在のディレクトリがコンピュータ gumbo のルートディレクトリに変更されます。

% cd /net/gumbo

なお、autofs はホスト gumbo のエクスポートされたファイルシステムだけをマウントできます。つまり、ローカルディスク上のファイルシステムではなく、ネットワークユーザーが使用できるサーバー上のファイルシステムです。したがって、gumbo にあるすべてのファイルとディレクトリは、/net/gumbo では利用できない場合があります。

/net を使用したアクセスでは、サーバー名はパスの中に指定されるため、位置に依存します。したがって、エクスポートされるファイルシステムを別のサーバーに移動すると、そのパスは使用できなくなります。このような場合は /net を使用しないで、そのファイルシステムに対応するエントリをマップの中に設定します。

注 –

autofs はマウント時だけサーバーのエクスポートリストを調べます。サーバーのファイルシステムが一度マウントされると、そのファイルシステムがアンマウントされ、次にマウントされるまで autofs はそのサーバーをチェックしません。したがって、新たにエクスポートされたファイルシステムは、それがサーバーからアンマウントされ、再度マウントされるまでは見えません。

直接マップ

直接マップは自動マウントポイントです。つまり、直接マップによって、クライアント上のマウントポイントとサーバー上のディレクトリが直接対応付けられます。直接マップには完全パス名があり、明示的に関係を示します。次に一般的な /etc/auto_direct マップを示します。

/usr/local          -ro \
   /bin                   ivy:/export/local/sun4 \
   /share                 ivy:/export/local/share \
   /src                   ivy:/export/local/src
/usr/man            -ro   oak:/usr/man \
                          rose:/usr/man \
                          willow:/usr/man 
/usr/games          -ro   peach:/usr/games 
/usr/spool/news     -ro   pine:/usr/spool/news \
                          willow:/var/spool/news

直接マップの行は、次の構文に従っています。

key [ mount-options ] location

key

key は直接マップでのマウントポイントのパス名です。

mount-options

mount-options は、このマウントに適用するオプションです。これらのオプションが必要なのは、マップのデフォルトと異なる場合だけです。特定のファイルシステムのマウントオプションについては、各ファイルシステムについてのマニュアルページを参照してください。たとえば、CacheFS 固有のマウントオプションについては、mount_cachefs(1M) のマニュアルページを参照してください。

location

location はファイルシステムの位置を示します。NFS ファイルシステムならば server:pathname、High Sierra ファイルシステム (HSFS) ならば :devicename という形式で 1 つまたは複数のファイルシステムを指定します。

注 –

pathname にオートマウントされたマウントポイントを含めることはできません。 pathname は、実際のファイルシステムの絶対パスでなければなりません。たとえば、ホームディレクトリの位置は、server:/home/username ではなく、server:/export/home/username として指定する必要があります。

マスターマップと同様、# で始まる行はコメントです。その行のテキストの最後まですべて無視されます。長い行を短い行に分割するには、行の最後にバックスラッシュを入力します。

すべてのマップにおいて、直接マップ内のエントリは、/etc/vfstab 内の対応するエントリにもっともよく似ています。/etc/vfstab のエントリは、次のようになっているとします。

dancer:/usr/local - /usr/local/tmp nfs - yes ro

直接マップ内では、同じエントリが次のようになります。

/usr/local/tmp     -ro     dancer:/usr/local

注 –

オートマウンタマップの間では、オプションの連結はされません。オートマウンタマップに追加されたどのオプションも、前に検索されたマップに表示されているすべてのオプションを上書きします。たとえば、auto_master マップに指定されているオプションは、他のマップの中の対応するエントリによって上書きされます。

この種類のマップについては、他にも重要な機能があります。autofs がクライアント用のもっとも近い読み取り専用ファイルを選択する方法 (複数ロケーション) を参照してください。

マウントポイント `/-`

例 15–1 にある /- というマウントポイントは、auto_direct の中のエントリを具体的なマウントポイントに関連付けないように autofs に指示します。間接マップの場合は、auto_master ファイルに定義されたマウントポイントを使います。直接マップの場合は、名前付きマップ内で指定したマウントポイントを使用します。直接マップ内では、キー、つまりマウントポイントは完全パス名であることに注意してください。

NIS または NIS+ の auto_master ファイルには、直接マップのエントリは 1 つしか存在できません。マウントポイントは 1 つの名前空間の中で一意でなければならないためです。auto_master がローカルファイルならば、重複しないかぎり直接マップのエントリがいくつあってもかまいません。

間接マップ

間接マップは、キーの置換値を使ってクライアント上のマウントポイントとサーバー上のディレクトリとを対応させます。間接マップは、ホームディレクトリなどの特定のファイルシステムをアクセスするのに便利です。auto_home マップは間接マップの一例です。

間接マップ内の行は次の一般的な構文になります。

key [ mount-options ] location

key

key は間接マップでの単純名 (スラッシュなし) です。

mount-options

mount-options は、このマウントに適用するオプションです。これらのオプションが必要なのは、マップのデフォルトと異なる場合だけです。特定のファイルシステムのマウントオプションについては、各ファイルシステムについてのマニュアルページを参照してください。たとえば、NFS 固有のマウントオプションについては、mount_nfs(1M) のマニュアルページを参照してください。

location

location はファイルシステムの位置を示します。server:pathname の形式により 1 つまたは複数のファイルシステムを指定します。

注 –

pathname にオートマウントされたマウントポイントを含めることはできません。 pathname は、実際のファイルシステムの絶対パスでなければなりません。たとえば、ディレクトリの位置は、server:/net/server/usr/local ではなく、server :/usr/local として指定する必要があります。

マスターマップと同様、# で始まる行はコメントです。その行のテキストの最後まですべて無視されます。長い行を短い行に分割するには、行の最後にバックスラッシュ (\) を入力します。例 15–1 に、次のエントリを含む auto_master マップを示します。

/home      auto_home        -nobrowse

auto_home は、/home のもとでマウントされるエントリを含む間接マップの名前です。通常、 auto_home マップには、次のパスが含まれています。

david                  willow:/export/home/david
rob                    cypress:/export/home/rob
gordon                 poplar:/export/home/gordon
rajan                  pine:/export/home/rajan
tammy                  apple:/export/home/tammy
jim                    ivy:/export/home/jim
linda    -rw,nosuid    peach:/export/home/linda

例として、前のマップがホスト oak にあると想定します。パスワードデータベースに、ユーザー linda のホームディレクトリが /home/linda であることを示すエントリがあるとします。linda がコンピュータ oak にログインするたびに、autofs は、コンピュータ peach にあるディレクトリ /export/home/linda をマウントします。彼女のホームディレクトリは、読み書き可能な nosuid にマウントされます。

次のような状況が発生したと想定してください。ユーザー linda のホームディレクトリがパスワードデータベースに、/home/linda として表示されます。Linda も含め誰でも、前の例のマップを参照するマスターマップで設定されたどのコンピュータからでも、このパスにアクセスできます。

こうした状況のもとでは、ユーザー linda はこれらのどのコンピュータでも login や rlogin を実行し、代わりに彼女用のホームディレクトリをマウントさせることができます。

さらに、これで Linda は次のコマンドも入力できます。

% cd ~david

autofs は彼女のために David のホームディレクトリをマウントします (すべてのアクセス権で許可されている場合)。

注 –

オートマウンタマップの間では、オプションの連結はされません。オートマウンタマップに追加されたどのオプションも、前に検索されたマップに表示されているすべてのオプションを上書きします。たとえば、auto_master マップに含まれているオプションは、他のいずれかのマップの対応するエントリによって上書きされます。

ネームサービスのないネットワークで、Linda が自分のファイルにアクセスするには、ネットワーク上のすべてのシステムで、すべての関連ファイル (/etc/passwd など) を変更する必要があります。NIS では、NIS マスターサーバーで変更を行い、関連するデータベースをスレーブのデータベースに伝達します。NIS+ を稼働中のネットワークでは、変更後に関連データベースがスレーブサーバーに自動的に伝達されます。

autofs のしくみ

autofs は、自動的に適切なファイルシステムをマウントするためのクライアント側のサービスです。クライアントが現在マウントされていないファイルシステムをアクセスしようとすると、autofs ファイルシステムはその要求に介入し、automountd を呼び出して要求されたディレクトリをマウントします。automountd はディレクトリを検索してマウントし、応答します。応答を受け取ると、autofs は待たせてあった要求の処理を続行させます。以降にそのマウントを参照すると、その要求は autofs によってリダイレクトされます。ファイルシステムに最後にアクセスしてから一定時間が経過し、autofs がそのファイルシステムを自動的にアンマウントするまで、automountd の介入は不要となります。

自動マウントを行うのに、次のコンポーネントが相互に動作します。

automount コマンド
autofs ファイルシステム
automountd デーモン

automount コマンドは、システム起動時に呼び出され、マスターマップファイル auto_master を読み取って autofs マウントの最初のセットを作成します。これらの autofs のマウントは起動時に自動的にはマウントされません。後でファイルシステムがマウントされるポイントです。このようなポイントをトリガーノードと呼ぶこともあります。

autofs マウントが設定されると、要求があったときにファイルシステムをマウントすることができます。たとえば、autofs が、現在マウントされていないファイルシステムをアクセスする要求を受け取ると、automountd を呼び出して要求されたファイルシステムを実際にマウントさせます。

autofs マウントをマウントしたら、必要に応じて automount コマンドを実行し、autofs マウントを更新します。このコマンドは、auto_master マップにあるマウントのリストと、マウントテーブルファイル /etc/mnttab (前のバージョンでは /etc/mtab) にあるマウントされたファイルシステムのリストを比較します。その後、automount によって、適切な変更が加えられます。このプロセスにより、システム管理者は auto_master 内のマウント情報を変更し、autofs デーモンを停止したり再起動したりすることなく、それらの変更結果を autofs プロセスに使用させることができます。ファイルシステムがマウントされれば、以後のアクセスに automountd は不要になります。次に automountd が必要になるのは、ファイルシステムが自動的にアンマウントされたときです。

mount とは異なり、automount はマウントすべきファイルシステムを調べるために /etc/vfstab ファイル (これは各コンピュータごとに異なる) を参照しません。automount コマンドは、ドメイン内とコンピュータ上で名前空間とローカルファイルを通して制御されます。

次の図では、autofs のしくみの概要を簡単に説明します。

自動マウントデーモンである automountd は、ブート時に /etc/init.d/autofs スクリプトによって起動されます (図 15–1 を参照)。このスクリプトは automount コマンドも実行します。このコマンドはマスターマップを読み取り、autofs のマウントポイントをインストールします。詳細は、autofs のナビゲーションプロセス開始法 (マスターマップ) を参照してください。

図 15–1 `/etc/init.d/autofs` スクリプトによる `automount` の起動

autofs は、自動マウント操作とアンマウント操作をサポートするカーネルファイルシステムの 1 つです。

autofs マウントポイントで、ファイルシステムへのアクセスが要求された場合は、次の動作が行われます。

autofs がその要求に介入します。
autofs は要求されたファイルシステムをマウントするよう、automountd にメッセージを送信します。
automountd がマップからファイルシステム情報を見つけ、マウントを実行します。
autofs は、介入した要求の実行を続行させます。
一定時間そのファイルシステムがアクセスされないと、autofs はそのファイルシステムをアンマウントします。

注 –

autofs サービスによって管理されるマウントは、手動でマウントまたはアンマウントは行わないでください。たとえこの操作がうまくいったとしても、autofs サービスはオブジェクトがアンマウントされたことを認識しないので、一貫性が損なわれる恐れがあります。リブートによって、autofs のマウントポイントがすべて消去されます。

autofs のネットワークナビゲート (マップ)

autofs は一連のマップを探索することによって、ネットワークをナビゲートします。マップは、ネットワーク上の全ユーザーのパスワードエントリや、ネットワーク上の全ホストコンピュータの名前などの情報を含むファイルです。マップには UNIX の管理ファイルに相当するネットワーク規模の管理ファイルも含まれています。マップはローカルに使用するか、あるいは NIS や NIS+ のようなネットワークネームサービスを通じて使用できます。ユーザーは Solaris 管理コンソールツールを使用して、自分の環境ニーズに適合するマップを作成します。autofs のネットワークナビゲート法の変更 (マップの変更) を参照してください。

autofs のナビゲーションプロセス開始法 (マスターマップ)

automount コマンドはシステムの起動時にマスターマップを読み取ります。図 15–2 に示すように、マスターマップ内の各エントリは、直接または間接のマップ名、そのパス、およびそのマウントオプションです。エントリの順序は重要ではありません。automount は、マスターマップ内のエントリとマウントテーブル内のエントリを比較して、現在のリストを生成します。

図 15–2 マスターマップによるナビゲーション

autofs マウントプロセス

マウント要求が発生したときに autofs サービスが何を実行するかは、オートマウンタマップの設定によって異なります。マウントプロセスの基本はすべてのマウントで同じですが、指定されているマウントポイントとマップの複雑さによって結果が変わります。Solaris 2.6 ではマウントプロセスも変更され、トリガーノードも作成されるようになりました。

単純な autofs マウント

autofs マウントプロセスの説明のために、以下のファイルがインストールされていると仮定します。

$ cat /etc/auto_master
# Master map for automounter
#
+auto_master
/net        -hosts        -nosuid,nobrowse
/home       auto_home     -nobrowse
/share      auto_share
$ cat /etc/auto_share
# share directory map for automounter
#
ws          gumbo:/export/share/ws

/share ディレクトリがアクセスされると、autofs サービスは /share/ws に対するトリガーノードを作成します。これは、/etc/mnttab の中では以下のようなエントリになります。

-hosts  /share/ws     autofs  nosuid,nobrowse,ignore,nest,dev=###

/share/ws ディレクトリがアクセスされると、autofs サービスは以下の手順を実行します。

サーバーのマウントサービスが有効かどうかを確認するために、そのサービスに対して ping を行います。
要求されたファイルシステムを、/share の下にマウントします。これで、/etc/mnttab ファイルには以下のエントリが追加されます。
-hosts /share/ws autofs nosuid,nobrowse,ignore,nest,dev=### gumbo:/export/share/ws /share/ws nfs nosuid,dev=#### #####

階層型マウント

オートマウンタファイルに複数の層が定義されていると、マウントプロセスは多少複雑になります。前の例の /etc/auto_shared ファイルを拡張して、次の行を追加したとします。

# share directory map for automounter
#
ws       /       gumbo:/export/share/ws
         /usr    gumbo:/export/share/ws/usr

この場合、/share/ws マウントポイントがアクセスされたときのマウントプロセスは基本的に最初の例と同じです。また、/share/ws ファイルシステムの中に次のレベル (/usr) へのトリガーノードを作成することにより、そのレベルがアクセスされたときにマウントできるようにします。この例でトリガーノードが作成されるためには、NFS に /export/share/ws/usr が存在している必要があります。

注意 –

階層的にマウントを指定する場合は、-soft オプションは使用しないでください。この制限についての説明は、autofs アンマウントを参照してください。

autofs アンマウント

一定時間アクセスがないためにアンマウントされるときは、マウントと反対の順序で実行されます。あるディレクトリより上位のディレクトリが使用中であれば、それより下のディレクトリだけがアンマウントされます。アンマウントすると、トリガーノードがすべて削除され、ファイルシステムがアンマウントされます。ファイルシステムが使用中であれば、アンマウントは失敗してトリガーノードは再インストールされます。

注意 –

階層的にマウントを指定する場合は、-soft オプションは使用しないでください。-soft オプションを使用すると、トリガーノードを再インストールする要求がタイムアウトすることがあります。トリガーノードを再インストールできないと、マウントの次の階層にアクセスできません。この問題を解決するには、オートマウンタを使用して、階層にあるすべてのコンポーネントのマウントを解除します。オートマウンタでマウントを解除するには、ファイルシステムのマウントが自動的に解除されるのを待つか、システムをリブートします。

autofs がクライアント用のもっとも近い読み取り専用ファイルを選択する方法 (複数ロケーション)

以下は、直接マップの例です。

/usr/local          -ro \
   /bin                   ivy:/export/local/sun4\
   /share                 ivy:/export/local/share\
   /src                   ivy:/export/local/src
/usr/man            -ro   oak:/usr/man \
                          rose:/usr/man \
                          willow:/usr/man
/usr/games          -ro   peach:/usr/games
/usr/spool/news     -ro   pine:/usr/spool/news \
                          willow:/var/spool/news

マウントポイント /usr/man および /usr/spool/news には複数の場所があり、/usr/man のマウントポイントは 3 つ、/usr/spool/news のマウントポイントは 2 つの場所が記述されています。このような場合、複製された場所のどこからマウントしてもユーザーは同じサービスを受けられます。ユーザーの書き込みまたは変更が可能ならば、その変更をロケーション全体で管理しなければならなくなるので、この手順は、読み取り専用のファイルシステムをマウントするときにだけ意味があります。あるときに、あるサーバー上のファイルを変更し、またすぐに別のサーバー上で「同じ」ファイルを変更しなければならないとしたら、たいへん面倒な作業になります。この利点は、もっとも利用しやすいサーバーが、そのユーザーの手をまったく必要としないで自動的にマウントされるということです。

ファイルシステムを複製として設定してあると (複製されたファイルシステムとはを参照)、クライアントはフェイルオーバー機能を使用できます。最適なサーバーが自動的に決定されるだけでなく、そのサーバーが使用できなくなるとクライアントは自動的に 2 番目に適したサーバーを使います。フェイルオーバー機能は、Solaris 2.6 の新機能です。

複製として設定するのに適しているファイルシステムの例は、マニュアルページです。大規模なネットワークでは、複数のサーバーがマニュアルページをエクスポートできます。どのサーバーからマニュアルページをマウントしても、そのサーバーが動作しており、しかもそのファイルシステムをエクスポートしているかぎり、問題ありません。上の例では、複数のマウント位置は、マップエントリ内のマウント位置のリストになっています。

/usr/man -ro oak:/usr/man rose:/usr/man willow:/usr/man

この例では、サーバー oak、rose、willow のどれからでもマニュアルページをマウントできます。どのサーバーが最適であるかは、次のいくつかの要素によって決まります。

特定レベルの NFS プロトコルをサポートしているサーバーの数
サーバーとの距離
重み付け

順位を決定するときには、NFS バージョン 2 と NFS バージョン 3 のプロトコルをサポートしているサーバーの数が数えられます。サポートしているサーバーの数が多いプロトコルがデフォルトになります。これによって、クライアントにとっては利用できるサーバーの数が最大になります。

プロトコルのバージョンが同じサーバーの組の中で数がもっとも多いものがわかると、サーバーのリストが距離によってソートされます。ローカルサブネット上のサーバーには、リモートサブネット上のサーバーよりも高い優先順位が付けられます。もっとも近いサーバーが優先されることにより、待ち時間が短縮されネットワークトラフィックは軽減されます。図 15–3 に、サーバーとの距離を示します。

図 15–3 サーバーとの距離

ローカルサブネット上に同じプロトコルをサポートしているサーバーが複数あるときは、それぞれのサーバーに接続する時間が計測され、速いものが使用されます。優先順位には、重み付けも関係します (autofs と重み付けを参照してください)。

バージョン 3 のサーバーの方が多いと、優先順位の決定は複雑になります。通常、ローカルサブネット上のサーバーはリモートサブネット上のサーバーよりも優先されます。バージョン 2 のサーバーがあり、それがもっとも近いバージョン 3 サーバーよりも近いと状況が複雑になる可能性があります。ローカルサブネットにバージョン 2 サーバーがあり、もっとも近いバージョン 3 サーバーがリモートサブネット上にあると、バージョン 2 サーバーが優先されます。このことは、バージョン 3 サーバーの方がバージョン 2 サーバーよりも多い場合にしかチェックされません。バージョン 2 サーバーの方が多いと、バージョン 2 サーバーしか選択されません。

フェイルオーバー機能を指定していると、この優先順位はマウント時に 1 回、マウントするサーバーを選択するときにチェックされ、その後は選択されたサーバーが使用できなくなるたびにチェックされます。複数の場所を指定しておくと、個々のサーバーが一時的にファイルシステムをエクスポートできないときに便利です。

多くのサブネットを持つ大規模なネットワークでは、この機能は特に便利です。autofs は最も近いサーバーを選択するため、NFS のネットワークトラフィックをローカルネットワークセグメントに制限します。複数のネットワークインタフェースを持つサーバーの場合は、それぞれのインタフェースが別々のサーバーであるとみなして、各ネットワークインタフェースに対応付けられているホスト名を指定します。autofs はそのクライアントにいちばん近いインタフェースを選択します。

autofs と重み付け

距離のレベルが同じサーバーから 1 つを選択するために、autofs マップに重み付けの値を追加することができます。例として、次の状況が考えられます。

/usr/man -ro oak,rose(1),willow(2):/usr/man

括弧内の数値が重み付けを表します。重み付けのないサーバーの値はゼロであり、選択される可能性が最高になります。重み付けの値が大きいほど、そのサーバーが選択される可能性は低くなります。

注 –

重み付けは、サーバーの選択に関係する要素の中でもっとも小さい影響力しかありません。ネットワーク上の距離が同じサーバーの間で選択を行う場合に考慮されるだけです。

マップエントリ内の変数

変数名の前にドル記号 ($) を付けることによって、クライアント固有の変数を作成できます。この変数は、同じファイルシステムの位置にアクセスする異なるアーキテクチャタイプの調整に役立ちます。変数名を括弧で囲むことで、その後に続く文字や数字と変数とを区切ることができます。表 15–3 に定義済みのマップ変数を示します。

表 15–3 定義済みのマップ変数


変数	意味	提供元	例
`ARCH`	アーキテクチャタイプ	`uname -m`	`sun4u`
`CPU`	プロセッサタイプ	`uname -p`	`sparc`
`HOST`	ホスト名	`uname -n`	`dinky`
`OSNAME`	オペレーティングシステム名	`uname -s`	`SunOS`
`OSREL`	オペレーティングシステムのリリース	`uname -r`	`5.8`
`OSVERS`	オペレーティングシステムのバージョン (リリースのバージョン)	`uname -v`	`GENERIC`

キーとして使用する場合を除いて、変数はエントリ行内のどこにでも使用できます。たとえば、/usr/local/bin/sparc および /usr/local/bin/x86 から、SPARC アーキテクチャと x86 アーキテクチャのバイナリをそれぞれエクスポートするファイルサーバーがあるとします。クライアントは、次のようなマップエントリを使ってマウントすることができます。

/usr/local/bin	   -ro	server:/usr/local/bin/$CPU

これで、すべてのクライアント上の同じエントリがすべてのアーキテクチャに適用されます。

注 –

どの sun4 アーキテクチャ向けに書かれたアプリケーションでも、ほとんどはすべての sun4 プラットフォームで実行できます。したがって、-ARCH 変数は sun4m ではなく、sun4 に固定されています。

他のマップを参照するマップ

ファイルマップで使用されたマップエントリ +mapname により、automount は指定されたマップを、あたかも現在のマップに組み込まれているかのように読み取ります。mapname の前にスラッシュがない場合、autofs はそのマップ名を文字列として扱い、ネームサービススイッチ方式を使用してマップ名を検出します。パス名が絶対パス名の場合、automount はその名前のローカルマップを捜します。マップ名がダッシュ (-) で始まる場合、automount は hosts などの適切な組み込みマップを参照します。

このネームサービススイッチファイルには、automount と指定された autofs 用のエントリが収められています。そしてそのエントリには、ネームサービスが検索される順序が収められています。ネームサービススイッチファイルの例を次に示します。

#
# /etc/nsswitch.nis:
#
# An example file that could be copied over to /etc/nsswitch.conf;
# it uses NIS (YP) in conjunction with files.
#
# "hosts:" and "services:" in this file are used only if the /etc/netconfig
# file contains "switch.so" as a nametoaddr library for "inet" transports.
# the following two lines obviate the "+" entry in /etc/passwd and /etc/group.
passwd:         files nis
group:          files nis

# consult /etc "files" only if nis is down.
hosts:          nis [NOTFOUND=return] files
networks:       nis [NOTFOUND=return] files
protocols:      nis [NOTFOUND=return] files
rpc:            nis [NOTFOUND=return] files
ethers:         nis [NOTFOUND=return] files
netmasks:       nis [NOTFOUND=return] files
bootparams:     nis [NOTFOUND=return] files
publickey:      nis [NOTFOUND=return] files
netgroup:       nis
automount:      files nis
aliases:        files nis
# for efficient getservbyname() avoid nis
services:       files nis

この例では、ローカルマップが NIS マップよりも先に検索されます。そのため、ローカルマップ /etc/auto_home に、もっとも頻繁にアクセスするホームディレクトリ用のエントリを含めることができます。他のエントリについては、スイッチを使用して NIS マップにフォールバックすることができます。

bill               cs.csc.edu:/export/home/bill
bonny              cs.csc.edu:/export/home/bonny

組み込まれたマップを参照した後、一致するものがなければ、automount は現在のマップのスキャンを続けます。そのため、+ エントリの後にさらにエントリを追加できます。

bill               cs.csc.edu:/export/home/bill
bonny              cs.csc.edu:/export/home/bonny
+auto_home

組み込まれたマップは、ローカルファイルまたは組み込みマップとすることができます。ローカルファイルだけが + エントリを持つことができることに注意してください。

+auto_home_finance      # NIS+ map
+auto_home_sales        # NIS+ map
+auto_home_engineering  # NIS+ map
+/etc/auto_mystuff      # local map
+auto_home              # NIS+ map
+-hosts                 # built-in hosts map

注 –

NIS+ または NIS のマップでは「+」エントリを使用できません。

実行可能な autofs マップ

autofs マウントポイントを生成するコマンドを実行する autofs マップを作成することもできます。データベースやフラットファイルから autofs 構造を作成しなければならない場合は、実行可能な autofs マップが有効なことがあります。短所は、マップをすべてのホストにインストールしなければならないことです。実行可能なマップは、NIS と NIS+ のどちらのネームサービスにも含めることができません。

実行可能マップは、auto_master ファイルにエントリが必要です。

/execute    auto_execute

実行可能マップの例を示します。

#!/bin/ksh
#
# executable map for autofs
#

case $1 in
	         src)  echo '-nosuid,hard bee:/export1' ;;
esac

この例が機能するためには、ファイルが /etc/auto_execute としてインストールされ、実行可能ビットがオンになっている必要があります。アクセス権は 744 に設定します。この場合、次のコマンドを実行すると、bee のファイルシステム /export1 がマウントされます。

% ls /execute/src

autofs のネットワークナビゲート法の変更 (マップの変更)

マップへのエントリを変更、削除、または追加して、ユーザーの環境ニーズに合わせることができます。ユーザーが必要とするアプリケーションやその他のファイルシステムがその位置を変更すると、マップはこれらの変更を反映しなければなりません。autofs のマップは、いつでも変更できます。automountd が次にファイルシステムをマウントしたときにその変更内容が有効になるかどうかは、変更したマップと変更内容によって決まります。

ネームサービスに対する autofs のデフォルトの動作

ブート時に、autofs は /etc/init.d/autofs にあるスクリプトを使って起動され、マスターマップ auto_master が検索されます。次に説明する規則が適用されます。

autofs は、/etc/nsswitch.conf ファイルの自動マウントエントリで指定されたネームサービスを使用します。ローカルファイルや NIS ではなく NIS+ が指定された場合、マップ名はすべてそのまま使用されます。NIS を選択し、autofs が必要なマップを検出できない場合で、1 つまたは複数の下線を含むマップ名を検出したときには、それらの下線がドットに変更されます。こうすることにより、NIS の古いファイル名を利用することができます。次に autofs はもう 1 度マップを調べます。この手順を図 15–4 に示します。

図 15–4 autofs によるネームサービスの使用

このセッションでは、画面は次の例のようになります。

$ grep /home /etc/auto_master
/home           auto_home

$ ypmatch brent auto_home
Can't match key brent in map auto_home.  Reason: no such map in
server's domain.

$ ypmatch brent auto.home
diskus:/export/home/diskus1/&

ネームサービスとして「ファイル」が選択された場合、すべてのマップは /etc ディレクトリ内のローカルファイルとみなされます。autofs は、使用するネームサービスとは無関係に、スラッシュ (/) で始まるマップ名をローカルとして解釈します。

autofs リファレンス

これ以降の節では、autofs の高度な機能を取り上げます。

メタキャラクタ

autofs は一部の文字を、特別な意味を持つものとして認識します。置き換えに使用する文字や、autofs のマップ構文解析機能から他の文字を保護するために使用する文字もあります。

アンパサンド (`&`)

たとえば次のように、多数のサブディレクトリを指定したマップがある場合は、文字列置換を使用できます。

john        willow:/home/john
mary        willow:/home/mary
joe         willow:/home/joe
able        pine:/export/able
baker       peach:/export/baker

この場合、アンパサンド文字 (&) を使用して、任意の位置に記述されたこのキーを置換することができます。アンパサンド文字を使用すると、前述のマップは次のようになります。

john        willow:/home/&
mary        willow:/home/&
joe         willow:/home/&
able        pine:/export/&
baker       peach:/export/&

キー置換はまた、次のような直接マップでも使用できます。

/usr/man						willow,cedar,poplar:/usr/man

また、このエントリは、次のようにさらに簡単にすることができます。

/usr/man						willow,cedar,poplar:&

アンパサンド文字による置換では、キー文字列全体を使用していることに注意してください。そのため、直接マップ内のキーの最初の文字が / である場合は、そのスラッシュ (/) も引き継がれます。たとえば、次のように指定することはできません。

/progs				&1,&2,&3:/export/src/progs

これは、autofs が、この例を次のように解釈するためです。

/progs 				/progs1,/progs2,/progs3:/export/src/progs

アスタリスク (`*`)

任意のキーを一致させるのに、任意の文字を表す置換文字であるアスタリスク (*) を使用できます。このマップエントリを使用して、すべてのホストから /export ファイルシステムをマウントできます。

*						&:/export

ここでは、各アンパサンドは特定のキーの値によって置換されています。autofs はこのアスタリスクをファイルの終わりとして解釈します。

特殊文字

特殊文字が含まれているマップエントリがある場合、autofs のマップ構文解析機能を混乱させるような名前のディレクトリについてはマウントする必要があります。autofs の構文解析機能は、名前に含まれるコロン、コンマ、スペースなどを認識します。これらの名前は二重引用符で囲んでください。

/vms    -ro    vmsserver: -  -  - "rc0:dk1 - "
/mac    -ro    gator:/ - "Mr Disk - "

パート III ネットワークファイルシステムへのアクセス (トピック)

第 13 章 ネットワークファイルシステムの管理 (概要)

NFS の用語

NFS サーバーとクライアント

NFS ファイルシステム

NFS サービスについて

autofs について

NFS サービスの機能

NFS バージョン 2 プロトコル

NFS バージョン 3 プロトコル

NFS ACL サポート

NFS の TCP への依存

ネットワークロックマネージャと NFS

NFS 大規模ファイルのサポート

NFS クライアントのフェイルオーバー機能

NFS サービスのための Kerberos のサポート

WebNFS のサポート

RPCSEC_GSS セキュリティ方式

Solaris 7 の NFS に対する拡張機能

WebNFS サービスのセキュリティネゴシエーション

NFS サーバーロギング

autofs の特徴

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

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

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

次に進む手順

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

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

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

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

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

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

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

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

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

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

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

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

NFS サービスの設定

NFS サービスの起動方法

NFS サービスの停止方法

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

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

Secure NFS システムの管理

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

WebNFS の管理作業

WebNFS アクセスの計画

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

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

autofs 管理作業の概要

autofs 管理の作業マップ

マップの管理作業

マップの修正

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

間接マップの修正方法

直接マップの修正方法

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

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

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

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

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

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

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

/home の共通表示の設定

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

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

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

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

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

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

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

autofs で NFS URL を使用する方法

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

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

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

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

NFS の障害追跡の方法

NFS の障害追跡の手順

NFS クライアントの接続性を確認する方法

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

第 13 章ネットワークファイルシステムの管理 (概要)

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

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

`/home` の共通表示の設定

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

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

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

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

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

第 15 章ネットワークファイルシステムへのアクセス (リファレンス)

`/etc/default/nfslogd` ファイル

`/etc/nfs/nfslog.conf` ファイル

`automountd` デーモン

`lockd` デーモン

`mountd` デーモン

`nfsd` デーモン

`nfslogd` デーモン

`statd` デーモン

`automount` コマンド

`clear_locks` コマンド

`mount` コマンド

NFS ファイルシステムでの `mount` オプション

`mount` コマンドの使用

`umount` コマンド

`umount` コマンドの使用

`mountall` コマンド

`mountall` コマンドの使用

`umountall` コマンド

`umountall` コマンドの使用

`share` コマンド

非ファイルシステム用 `share` オプション

NFS 用 `share` オプション

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

`unshare` コマンド

`unshare` コマンドの使用

`shareall` コマンド

`shareall` コマンドの使用

`unshareall` コマンド

`unshareall` コマンドの使用

`showmount` コマンド

`showmount` コマンドの使用

`setmnt` コマンド

`nfsstat` コマンド

`nfsstat` コマンドの使用

`pstack` コマンド

`rpcinfo` コマンド

`rpcinfo` コマンドの使用

`snoop` コマンド

`truss` コマンド

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