test

NFS の管理

第 4 章 autofs の管理

この章では、autofs 管理タスクの実行方法について説明します。具体的には、オートマウンタマップの変更、オートマウンタから非 NFS タイプのデバイスに対するアクセス、マップの設定などです。

autofs の設定

この節では、autofs サービスの起動および停止の手順について説明します。

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

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


# /etc/init.d/autofs start

これでデーモンが起動します。

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

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


# /etc/init.d/autofs stop

一般的な作業と手順

この節では、ユーザの環境で遭遇する可能性のある最も一般的な問題について、そのいくつかを説明します。クライアントのニーズに最適な autofs を構成する際に役立つよう、各問題ごとに推奨する解決策を記載しています。

注 -

この節で説明されている作業を実行するには、Solstice システム管理ツールを使用するか、または『Solaris ネーミングの管理』を参照してください。

マップを含む管理作業

次のリストは、autofs 環境を変更するために実行する必要が生じる可能性のある、マップに関する各種の管理作業です。

表 4-1 autofs のマップの種類とその使用方法

マップの種類 

使用方法 

マスタ

ディレクトリとマップを対応付ける 

直接

autofs を特定のファイルシステムに割り当てる 

間接

autofs を参照だけを行うファイルシステムに割り当てる 

ネームサービスを基にして、ユーザの autofs 環境を変更する方法を表 4-2 に示します。

表 4-2 マップ管理

ユーザのネームサービス 

変更用のツール 

ローカルファイル 

テキストエディタ 

NIS 

make ファイル

NIS+ 

nistbladm

表 4-3 は、変更後に automount コマンドを実行すべきかどうかを、変更したマップの種類別に示しています。たとえば、直接マップに追加または削除を行なった場合には、その変更を反映させるためにローカルシステムで automount コマンドを実行する必要があります。しかし、既存のエントリに変更を行なった場合には、automount コマンドを実行してその変更を反映させる必要はありません。

表 4-3 automount コマンド実行タイミング

マップの種類 

automountを再起動する ?

 

追加または削除 

既存のエントリを変更 

auto_master

実行する

実行する

direct

実行する

実行しない

indirect

実行しない

実行しない

マップの変更

以下の手順では、ネームサービスとして NIS+ を使っていることが前提です。

マスタマップを変更する

  1. nistbladm コマンドを使って、マスタマップに必要な変更をします。

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

  2. 各クライアントに対して、プロンプトで su を入力し、スーパーユーザのパスワードを入力してスーパーユーザになります。

  3. 各クライアントに対して、automount コマンドを実行して、行った変更を確実に有効にします。

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

    ユーザでも自分のコンピュータ上でスーパーユーザとして automount コマンドを実行できることを通知してください。

automount コマンドが実行されると、マスタマップを参照します。

間接マップを変更する

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

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

次にこのマップが使用されると、マウントが行われ、変更内容が有効となります。

直接マップを変更する

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

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

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

  3. ユーザに変更を通知します。

    ユーザでも自分のコンピュータ上でスーパーユーザとして automount コマンドを実行できることを、通知してください。

    注 -

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

    たとえば、マップ auto_direct を変更し、ディレクトリ /usr/src は異なるサーバからマウントされると仮定します。このとき /usr/src がマウントされていない場合、ユーザが /usr/src をアクセスしようとすると、この新しいエントリはすぐに有効となります。/usr/src が現在マウントされている場合、自動アンマウントが行われるまで待ってから、アクセスすることができます。

    注 -

    これらの余分な手順が必要な上、間接マップではマウントテーブル内で直接マップほどのメモリ領域を占有しないため、できるだけ間接マップを使用してください。間接マップは作成が簡単で、コンピュータファイルシステムに関する条件も直接マップほど厳しくありません。

マウントポイント衝突の回避

ローカルディスクパーティションを /src にマウントし、しかも autofs サービスを使用して他のソースディレクトリもマウントしたい場合、問題が発生することがあります。ユーザがマウントポイント /src を指定した場合、ユーザがローカルパーティションを参照しようとすると、autofs サービスがこれを隠します。

このパーティションをどこか他 (たとえば、/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 アプリケーションにアクセスする

注 -

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

    次のように CD-ROM ファイルシステムの種類を指定してください。


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

    マウントする CD-ROM 装置の名前には、先頭にコロンを付けてください。

autofs を使って PC-DOS データのフロッピーディスクにアクセスする

注 -

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

    フロッピーファイルシステムタイプを次のように指定します。 


     pcfs -fstype=pcfs :/dev/diskette

CacheFS による NFS ファイルシステムへのアクセス

キャッシュファイルシステム (CacheFS) は、小型で高速なローカルディスクを使用することによって、特定のファイルシステムの性能を向上させるための、汎用の不揮発性キャッシュ機能です。

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

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

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


    # cfsadmin -c /var/cache

  2. オートマウンタマップに 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 の下に存在していることです。この /home 以下のディレクトリは、クライアントであれサーバであれすべてのコンピュータで共通になるようにしてください。

Solaris ソフトウェアをインストールすると、マスタマップ /etc/auto_master が設定されます。 


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

auto_home 用のマップも、/etc の下に設定されます。 


# Home directory map for autofs
#
+auto_home

外部の auto_home マップへの参照を除けば、このマップは空です。/home の下にあるディレクトリをすべてのコンピュータに共通とする場合、この /etc/auto_home マップを変更しないでください。すべてのホームディレクトリエントリは、NIS または NIS+ のネームサービスマップに登録されていなければなりません。

注 -

制限がなければ、どんなユーザでも任意のコンピュータ上でスーパーユーザ特権を持つことができるため、ユーザが自分のホームディレクトリから実行可能ファイル set uid を実行することを許可しないでください。

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

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

    複数のパーティションがある場合、それらを別個のディレクトリ、たとえば /export/home1、/export/home2 などの下にインストールします。

  2. Solstice System Management Tools を使用して auto_home マップの作成と管理を行います。

    新規のユーザアカウントを作成するときには、ユーザのホームディレクトリの位置を auto_home マップに入力します。マップエントリは、たとえば次のように簡単な形式になっています。

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

    アンパサンド「&」を使用してマップキーを置換することに注意してください。これは次の例での rusty を 2 回入力する場合の省略表記です。


    rusty 	dragon:/export/home1/rusty

auto_home マップを適切な場所に配置することによって、ユーザはパス /home/user で任意のホームディレクトリ (自分のものを含む) を参照できます。ここで、user はユーザのログイン名で、マップのキーでもあります。他のユーザのコンピュータにログインするとき、全ホームディレクトリが共通の構造になっていると便利です。autofs は、そこにユーザのホームディレクトリをマウントします。同様に、リモートのウィンドウクライアントを他のコンピュータ上で実行する場合、そのクライアントプログラムは、ユーザがウィンドウ表示を提供するコンピュータ上で持つのと同じ /home ディレクトリの構造を持っています。

この共通の構造は、サーバにも影響します。上の例を使用し、rusty がサーバ dragon にログインした場合、autofs は、/export/home1/rusty を /home/rusty にループバックマウントすることによって、ローカルディスクへの直接アクセスを可能にします。

ユーザは、自分のホームディレクトリの実際の位置を知る必要がありません。rusty がより多くのディスク空き容量を必要とし、自分のホームディレクトリを他のサーバに再配置する必要がある場合、この新しい位置を反映するためには、auto_home マップ内の rusty のエントリを変更するだけですみます。すべてのユーザがパス /home/rusty を継続して使用できます。

プロジェクト関連ファイルの統合方法 (/ws ディレクトリ構造)

あなたが大規模なソフトウェア開発プロジェクトの管理者だとします。プロジェクトに関連するすべてのファイルを /ws (Work Space の略) と呼ばれるディレクトリの下で使用できるようにしたいとします。このディレクトリは、そのサイトのすべてのワークステーション間で共通となります。

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


    /ws auto_ws -nosuid

    auto_ws マップによって、/ws ディレクトリの内容が決まります。

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

    このオプションを指定すると、ユーザは、ワークスペースに存在する setuid を実行できなくなります。

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

    この auto_ws マップは、各エントリがサブプロジェクトを指定するように作成されます。最初の試みによって、次のようなマップが得られます。

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

    各エントリの最後にあるアンパサンド (&) は、エントリキーの単なる省略です。たとえば、最初のエントリは次のものと等しくなります。


    compiler		alpha:/export/ws/compiler

    この段階で得られるマップは単純で、まだ不十分なものです。プロジェクト責任者は、man エントリ内のドキュメントを各サブプロジェクトの下にあるサブディレクトリとして提供することを決定します。また各サブプロジェクトは、複数バージョンのソフトウェアを指定するためにサブディレクトリを必要とします。これらのサブディレクトリは、それぞれサーバ上のディスクパーティション全体に割り当てられなければなりません。

    マップ内のエントリを次のように変更します。


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

マップはとても大きくなったように見えますが、それでも 5 つのエントリが含まれているだけです。各エントリには多重マウントが含まれるため、大きくなっています。たとえば /ws/compiler への参照には、vers1.0、vers2.0、および man ディレクトリ用の 3 つのマウントが必要です。各行の最後にあるバックスラッシュは、エントリが次の行に続いていることを示します。このエントリは 1 行なのですが、行ブレークとインデントを使用して読み易くなっています。tools ディレクトリには全サブプロジェクト用のソフトウェア開発支援ツールが収められているため、これは同じサブディレクトリ構造になっていません。tools ディレクトリは依然として単一のマウントです。

この配置によって、管理者には高い柔軟性が与えられます。ソフトウェアプロジェクトは、大量のディスク領域を消費することが知られています。このプロジェクトの有効期間中には、さまざまなディスクパーティションの再配置と拡張が要求されます。これらの変更内容が auto_ws マップに反映される限り、/ws のもとのディレクトリ階層は変更されないため、ユーザに通知する必要はありません。

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

さまざまなアーキテクチャによる共有名前空間へのアクセスを設定する方法

ローカルの実行可能ファイル、また、表計算ツールやワードプロセッシングのパッケージなどのアプリケーション用に、共有名前空間を 1 つにまとめる必要があります。この名前空間のクライアントは、異なる実行可能形式を必要とするさまざまなワークステーションアーキテクチャを使用します。また、一部のワークステーションはオペレーティングシステムの異なるバージョンを実行しています。

  1. nistbladm コマンドを使用して auto_local マップを作成します。

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

  2. 共有名前空間に対して 1 つのサイト名を選択し、この空間に属するファイルとディレクトリを容易に識別できるようにします。

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

  3. ユーザを簡単に認識できるよう、autofs の間接マップを作成して、/usr/local にマウントします。NIS+ (または NIS) の auto_master マップ内に次のエントリを設定します。


    /usr/local      auto_local      -ro

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

  4. 適切なディレクトリをサーバ上にエクスポートします。

  5. bin のエントリを auto_local マップに作成します。

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


     bin      aa:/export/local/bin

    異なるアーキテクチャのクライアントに対応するというニーズを満足するため、この bin ディレクトリに対する参照は、クライアントのアーキテクチャタイプに応じて、サーバ上の異なるディレクトリに対して行う必要があります。

  6. 異なるアーキテクチャのクライアントに対応するため、autofs の「CPU」変数を追加することによって、エントリを変更します。


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

    SPARCstationTM クライアントの場合は、実行可能ファイルはサーバ上の /export/local/bin/sparc のもとで使用できるようにしてください。x86 クライアントの場合、/export/local/bin/i386 です。

互換性のないクライアントオペレーティングシステムをサポートする

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

    autofs の「OSREL」変数を CPU 変数と結合することによって、CPU タイプと OS リリースの両方を決める名前を作成することができます。

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


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

バージョン 5.6 のオペレーティングシステムを実行している SPARC クライアントの場合、サーバから /export/local/bin/sparc5.6 をエクスポートし、同様に他のリリースもエクスポートする必要があります。オペレーティングシステムは実行可能形式での下方互換性を維持しようとするため、OS のリリースについては問題ないと想定し、このあとの例では、OS のリリースによる区別は省略します。

これまで、1 つのサーバ「aa」用のエントリを設定しました。大規模ネットワークでは、これらの共有ファイルを複数のサーバ間で複写したいという要望があります。NFS のトラフィックがローカルネットワークセグメントに限定されるよう、各サーバは、サービスを提供するクライアントに近いネットワークにある必要があります。

複数のサーバ間で共有ファイルを複写する

複製された読み取り専用のファイルシステムを共有する最良の方法は、障害時回避機能を使うことです。障害時回避機能については、「クライアント側障害時回避機能」 を参照してください

    エントリを変更して、次のようにすべての複製サーバのリストをカンマで区切って作成します。 


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

autofs は最も近いサーバを選択します。サーバに複数のネットワークインタフェースがある場合、各インタフェースを指定します。autofs はクライアントに最も近いインタフェースを選択し、NFS トラフィックの不必要な経路指定を回避します。

セキュリティを適用する

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

    次のようなエントリを作成します。 


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

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

autofs で NFS URL を使う方法

    次のようなエントリを作成します。 


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

    autofs は NFS サーバ上の公共ファイルハンドルを使おうとしますが、サーバが公共ファイルハンドルをサポートしていないと、MOUNT プロトコルが使用されます。

autofs の表示機能の無効化

Solaris 2.6 およびその互換バージョンでインストールされる /etc/auto_master では、/home と /net のエントリに -nobrowse オプションが追加されています。また、/etc/auto_master の中の /home と /net のエントリが変更されていなければ、アップグレードによってこれらのエントリに -nobrowse オプションが追加されます。しかし、これらの変更を手動で行なったり、各サイトの autofs マウントポイントの表示機能を無効にしなければならないこともあります。

表示機能を無効にする方法はいくつかあります。1 つは automountd に対してコマンド行オプションを使用して無効にする方法です。この場合、クライアントに対する autofs の表示機能は完全に無効になります。もう 1 つは、NIS または NIS+ 名前空間の autofs マップを使っているクライアントすべてに対して、またはネットワーク全体で使用している名前空間がない場合にはローカルの autofs マップを使っている各クライアントごとに、マップエントリで表示機能を無効にする方法です。

単一の NFS クライアントに対して autofs の表示機能を完全に無効にする方法

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

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


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

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


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

すべてのクライアントに対して autofs の表示機能を無効にする

すべてのクライアントに対して表示機能を無効にするには、NIS や NIS+ といったネームサービスを使用している必要があります。使用していない場合は、クライアントごとにオートマウンタマップを手動で編集する必要があります。この例では、/home ディレクトリの表示機能を無効にします。この手順を、無効にする間接 autofs ノードそれぞれについて実行します。

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


    /home     auto_home     -nobrowse

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

    変更は、このクライアントで automount コマンドを実行するかクライアントをリブートすると反映されます。


    # /usr/sbin/automount

1 台の NFS クライアントに対して autofs の表示機能を無効にする

この例では、/net ディレクトリの表示機能を無効にします。同様の手順は、/home などの autofs マウントポイントにも適用できます。

  1. /etc/nsswitch.conf の automount エントリを調べます。

    ローカルファイルエントリを優先させるためには、ネームサービスの切り替えファイルでネームサービスより前に files を指定します。たとえば次のようにします。


    automount: files nisplus

    これは、Solaris をインストールしたときのデフォルト設定です。

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

    ローカルファイルへの追加を名前空間のエントリよりも優先させるために、+auto_master エントリを /net よりも下の位置に移動します。


    # Master map for automounter
#
/net	-hosts	-nosuid
/home	auto_home
/xfn	-xfn
+auto_master
    標準の設定では、+auto_master エントリはファイルの先頭に置かれます。そのため、ローカルの変更は一切できません。

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


    /net     -hosts     -nosuid,nobrowse

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

    変更は、このクライアントで automount コマンドを実行するかクライアントをリブートすると反映されます。


    # /usr/sbin/automount

autofs での問題発生時の対処

autofs を使用していて問題が発生することもあります。この節の目的は、問題解決のプロセスを容易にすることです。これは 2 つの節に分かれています。

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

それぞれのエラーメッセージには説明が続き、考えられる原因を示します。

問題を解決する際は、詳細 (-v) オプションを使って起動してください。そうしないと、問題が発生しても原因がわからない可能性があります。

以下では Autofs で問題が発生したときに表示される可能性のあるエラーメッセージを取り上げ、問題の内容について説明します。

自動マウンタで生成されるエラーメッセージ


bad key key in direct map mapname

直接マップの走査中、autofs は「/」が付いていないエントリキーを検出しました。直接マップ内のキーはフルパス名でなければなりません。


bad key key in indirect map mapname

間接マップの走査中、autofs が「/」を含むエントリキーを検出しました。間接マップのキーは、パス名ではなく、単純な名前でなければなりません。


can't mount server:pathname: reason

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


couldn't create mount point mountpoint: reason

マウントに必要なマウントポイントを autofs が作成できませんでした。このメッセージが最もよく表示されるのは、サーバのエクスポートされたファイルシステムをすべて階層的にマウントしようとしたときです。必要なマウントポイントが、マウントできない (エクスポートできない) ファイルシステムにだけ存在する可能性があります。しかもエクスポートされた親ファイルシステムが読み取り専用でエクスポートされているため、これを作成できません。


leading space in map entry entry text in mapname

autofs は、先頭にスペースが含まれるエントリを自動マウントマップ内に発見しました。これは通常、たとえば次のように誤って続けて入力したマップエントリが原因です。


fake
/blat 		frobz:/usr/frotz

上の例では、最初の行はバックスラッシュ (¥) で終了しなければならないため、autofs が 2 番目の行を検出したとき、この警告が生成されます。


mapname: Not found

必要なマップを検出できません。このメッセージは、-v オプションが指定された場合にだけ出力されます。マップ名のスペルとパス名をチェックしてください。


remount server:pathname on mountpoint: server not responding

autofs は、以前にアンマウントしたファイルシステムの再マウントに失敗しました。このメッセージは、ファイルシステムが正常に再マウントされるまで、一定間隔ごとに表示されます。


WARNING: mountpoint already mounted on

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

一般的なエラーメッセージ


dir mountpoint must start with `/'

自動マウンタのマウントポイントはフルパス名で指定しなければなりません。マウントポイントのスペルとパス名をチェックしてください。


hierarchical mountpoints: pathname1 and pathname2

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


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 は、マウントポイントがディレクトリではないため、これにそれ自身をマウントできません。マウントポイントのスペルとパス名をチェックしてください。


nfscast: cannot send packet: reason

autofs は、複写されたファイルシステム位置のリストにあるサーバに対して、問い合わせパケットを送信できません。


nfscast: cannot receive reply: reason

autofs は、複写されたファイルシステム位置のリストにあるどのサーバからも応答を受信できません。


nfscast:select: reason

これらのエラーメッセージは、複写されたファイルシステム用のサーバに対し ping を実行しようとしていることを示します。ネットワークに問題がある可能性があります。


pathconf: no info for server:pathname

autofs は、pathname 用の pathconf を獲得できませんでした。


pathconf: server: server not responding

autofs は、(POSIX) pathconf() 情報を提供するサーバ上のマウントデーモンと通信できません。

autofs に関するその他のエラー

/etc/auto* ファイルに実行ビットセットがある場合、自動マウンタはマップを実行しようとして、次のようなメッセージを作成します。

/etc/auto_home: +auto_home: not found

この場合、auto_home ファイルには間違ったパーミッションが入ることになります。ファイルの各エントリはほぼ上記のようなエラーメッセージを生成します。以下のコマンドを入力して、ファイルへのパーミッションをリセットする必要があります。


# chmod 644 /etc/auto_home