exports(5) (カーネルベースの NFS で) エクスポート (export) される NFS ファイルシステム

書式

/etc/exports

説明

/etc/exports ファイルは、 NFS のクライアントにどのファイルシステムをエクスポート (export) してよいか、 というアクセスコントロールリストを与える。 これは exportfs(8) によって使用され、NFS マウントデーモン mountd(8) と、カーネルベースの NFS ファイルサーバデーモン nfsd(8) とに情報を与える。

このファイルの書式は SunOS の exports ファイルと似ている。 それぞれの行には、エクスポートポイントと、 そのポイントにあるファイルシステムをマウントできるクライアントを スペースで区切って指定したリストが書かれている。 リストされたクライアントの直後には、 そのクライアント向けのエクスポートオプションをコンマで区切ってリスト指定し、 リスト全体を括弧で括って置くこともできる。 クライアント名とこのオプションリストとの間にはスペースを入れてはいけない。

空行は無視され、# 以降行末まではコメントとみなされる。 行末にバックスラッシュをおけば、エントリは次の行に継続できる。 エクスポート名に空白が含まれる場合は、ダブルクォートで括る。 エクスポートパス名には、 空白やその他通常は使われない文字を指定することもできる。 このような文字を使う場合は、バックスラッシュの後に 3 桁の 8 進数で文字コードを指定する。

マシン名のフォーマット

NFS クライアントはいろいろな方法で指定できる。
single host
これはもっとも普通のフォーマットである。ホストの指定には、 レゾルバが認識できる省略形、FQDN、IP アドレスのどれを用いてもよい。
netgroups
NIS のネットグループを @group のように与えることができる。ネットグループの各メンバーは、 ホストの部分だけが取り出され、メンバーに入れられる。 ホストの部分が空だったり、単一のダッシュ (-) だったものは無視される。
ワイルドカード
マシン名の指定には、ワイルドカード文字として * と ? を 用いることができる。これらを使うと exports ファイルをコンパクトにできる。 例えば *.cs.foo.edu はドメイン cs.foo.edu にあるすべての ホストにマッチする。 これらのワイルドカード文字はドメイン名のドット (.) にもマッチするので、 ここで指定されたパターンは cs.foo.edu の任意のサブドメイン内の 全てのホストにマッチする。
IP networks
ディレクトリを IP の (サブ) ネットワークに存在するすべてのホストに 同時にエクスポートすることもできる。 これには IP アドレスとネットマスクのペアを address/netmask のように指定すればよい。 ここで netmask は 10 進数をドットで区切って指定することもできるし、 連続するマスクの長さで指定することもできる (例えば、ネットワークベースアドレスに `/255.255.252.0' を追加した場合でも、 `/22' を追加した場合でも、ホスト部が 10 ビットの同じサブネットワークになる)。 ワイルドカード文字は、通常 IP アドレスに対しては動作しない。 ただし DNS の逆引きが失敗すると、たまたま動作してしまうこともあり得る。

RPCSEC_GSS セキュリティ

エクスポートへのアクセスを rpcsec_gss セキュリティを使って制限するには、 クライアントとして特別な文字列 "gss/krb5" を使うこと。 rpcsec_gss とクライアントの IP アドレスによる資格を 同時に要求することはできない。

一般的なオプション

exportfs は以下のエクスポートオプションを受け付ける。
secure
このオプションを指定すると、IPPORT_RESERVED (1024) より小さな internet ポートから発したリクエストしか受けつけない。 このオプションはデフォルトで有効になっている。 無効にするには insecure と指定する。
rw
この NFS ボリュームに対して、書き込みと読み出しリクエストの両方を許可する。 デフォルトではファイルシステムを変更する全ての書き込みを拒否する (これは ro オプションで明示した場合も同じ)。
async
このオプションは NFS サーバを NFS プロトコルに違反させ、 あるリクエストによってなされた変更が安定した保存場所 (例えばディスクドライブ) に渡される前に、 そのリクエストに応えるようにする。

このオプションを用いると通常は性能が向上するが、 クリーンでないサーバの再起動 (つまりクラッシュ) によってデータが失われたり破壊されうるという代償を伴う。

nfs-utils の 1.0.0 まででは、このオプションがデフォルトであった。 このリリース以降は sync がデフォルトとなり、 async は必要な場合は明示的に指定しなければならない。 システム管理者にこの変更を知らせるため、 sync と async のいずれも指定されていない場合、`exportfs' は警告を発する。

no_wdelay
このオプションは同時に async が設定されていると効果を持たない。 NFS サーバは、書き込み要求を受けたとき、 関連した別の書き込み要求が実行中である (または近々到着する) と予想した場合、 その要求のディスクへの反映を少し遅らせる。 これにより一度の操作で複数の書き込み要求が ディスクに反映されるので、性能が向上する。 NFS サーバが受け取るデータの書き込み要求が、 主として関連性のない小さなものの場合には、 この動作は実際には性能を低下させてしまうので、 no_wdelay を指定して無効にできる。 デフォルトの動作を wdelay オプションで明示的に指定することもできる。
nohide
このオプションは IRIX NFS で提供される同名のオプションを元にしている。 サーバが 2 つのファイルシステムをエクスポートし、 そのうちの 1 つが他方にマウントされている場合、 クライアントが両者にアクセスを行うには、 両方のファイルシステムを明示的にマウントしなければならない。 親の方をマウントしただけでは、 もう一方のファイルシステムがマウントされているディレクトリは空に見える。 このようなファイルシステムは "hidden" といわれる。

hidden にしたくないファイルシステムに nohide オプションを設定すれば、 適切な権限のあるクライアントは変更を知らされることなく、 親から子のファイルシステムに移動できる。

しかし NFS クライアントのなかには、 このような状況 (例えば、見かけ上 1 つのファイルシステムで 2 つのファイルが同じ inode 番号を持つような状況) ではうまく動作しないものもある。

nohide オプションは現在のところ single host エクスポートでしか効果がない。 このオプションの動作は、 netgroup, subnet, wildcard などによるエクスポートでは信頼性がない。

このオプションは状況によってはとても便利であるが、よく注意して、 かつクライアントシステムがその状況下で効果的に動作することを確認した後で 使うべきである。

このオプションは hide で明示的に無効にできる。

no_subtree_check
このオプションのサブツリーのチェックを無効にする。 これには簡単なセキュリティの意味もあるが、 環境によっては信頼性を向上させることもできる。

ファイルシステムのサブディレクトリがエクスポートされているが、 ファイルシステム全体がエクスポートされていない場合、 NFS リクエストがくると、サーバは対応するファイルシステムに アクセスされたファイルがあるかをチェックするだけでなく (これは簡単)、 エクスポートされたツリーのなかにあるかもチェックしなければならない (これは難しい)。 このチェックは subtree_check とよばれる。

このチェックを行うには、サーバはクライアントに渡す 「ファイルハンドル」に、ファイルの場所に関する情報を入れなければならない。 こうすると、クライアントがファイルをオープンしている間に、 アクセスしているファイルの名前が変更されると問題が起こる (ただし多くの簡単なケースでは動作する)。

サブツリーのチェックは、 ファイルシステムが no_root_squash (下記参照) でエクスポートされていて、 ファイル自身にはより一般的なアクセス権がある場合に、 root しかアクセスできないディレクトリ内のファイルが root によってのみアクセスされているかを確認するのにも使える。

一般的な指針として、ホームディレクトリは サブツリーのチェックを無効にしてエクスポートすべきである (通常各ユーザの親ディレクトリのレベルでエクスポートされ、 かつファイル名の変更が多いため)。 大抵は読み込みのみで、ほとんどファイル名の変更が行われない ファイルシステム (たとえば /usr や /var) で、 それらのサブディレクトリがエクスポートされるような場合には、 サブツリーのチェックを有効にしてエクスポートした方がよいかもしれない。

サブツリーのチェックを行うデフォルトの動作は、 subtree_check で明示的に指定することもできる。

insecure_locks
no_auth_nlm
このオプション (2 つのオプション名は同じ意味) を指定すると、 NFS はロック要求 (NLM プロトコルを使った要求) の際に認証を必要としなくなる。 通常 NFS サーバは、ファイルの読み取りアクセス権限を持つユーザに対し、 信用証明 (credential) を保持するために、ロック要求を必要とする。 このフラグを指定すると、アクセスチェックが行われない。

初期の NFS クライアントの実装ではロック要求の際に信用証明を送らなかったが、 現在でもこのような昔の実装を元にした多くの NFS クライアントが存在する。 全ての人が読み込み可能なファイルのみをロックしたい場合は、 このフラグを使うこと。

NLM 要求の際に認証を求めるデフォルトの動作は、 同じ意味をもつ auth_nlm または secure_locks のどちらか (意味は全く同じ) で明示的に指定できる。

mountpoint=path
mp
このオプションを使うと、マウントに成功した場合にのみ、 そのディレクトリをエクスポートできる。 パスが指定されない場合 (たとえば mountpoint または mp の場合)、エクスポートポイントはマウントポイントでなければならない。 そうでなければ、エクスポートポイントはエクスポートされない。 これにより、マウントポイント以下のディレクトリが、 事故によってエクスポートされてしまわないようにすることができる。 ここでいう事故とは、例えばディスクエラーによって ファイルシステムがマウントに失敗するような場合である。

パスが指定される場合 (たとえば mountpoint=/path または mp=/path の場合)、マウントされるパスは、 エクスポートされるエクスポートポイントに対応する マウントポイントでなければならない。

fsid=num
このオプションは、通信で使用されるファイルハンドルとファイル属性の ファイルシステム識別部として、 ファイルシステムがマウントされているブロックデバイスの メジャー番号とマイナー番号から導き出された数ではなく、 num を使う。 任意の 32 ビットの数値が使えるが、 エクスポートされるファイルシステム間で一意 (unique) でなければならない。

これは NFS のフェイルオーバー (failover, 代替引き継ぎ) で役立つ。 フェイルオーバーのペアとなる両方のサーバーが、 共有されるファイルシステムに対して 同じ NFS ファイルハンドルを使うことが保証されるので、 フェイルオーバー後にファイルハンドルが失効するのを避けることができる。

Linux のファイルシステムの中には、 ブロックデバイスにマウントされていないものもある。 これらのファイルシステムを NFS でエクスポートするには、 fsid オプションを使う必要がある (ただし、このオプションはまだ充分ではない)。

値 0 は NFSv4 で使う場合には特別な意味を持つ。 NFSv4 にはエクスポートされるファイルシステム全体のルートという概念がある。 fsid=0 でエクスポートされたエクスポートポイントは、 このルートとして使用される。

ユーザ ID のマッピング

サーバマシン上のファイルに対する nfsd によるアクセスコントロールは、 それぞれの NFS RPC request の際に与えられる uid と gid に基づいている。 ユーザは通常、 サーバ上にある自分のファイルには、それが普通のファイルシステム上に あるのと同様にアクセス可能であることを期待している。 これにはクライアントとサーバ上で用いられる uid と gid がそれぞれ 同じである必要があるが、 これは常に真であるとは限らず、望ましいとも限らない。

クライアントマシンの root が NFS サーバのファイルにアクセスするとき、 サーバの root として扱われてしまうのは、ほとんどの場合は望ましくない。 このため uid 0 は普通は別の id (anonymous や nobody uid) にマッピングされる。 この動作は `root squashing' と呼ばれるが、これがデフォルトである。 no_root_squash を使えばオフにすることができる。

デフォルトでは、 exportfs は squash アクセスに -2 (つまり 65534) という uid と gid を用いる。 これらの数値は anonuid と anongid オプションによって変更できる。 最後に、 all_squash オプションを指定すれば、 全ての user request を anonymous uid に割り当てることもできる。

以下にマッピングオプションの完全なリストをあげる:

root_squash
uid/gid が 0 のリクエストを annonymous uid/gid にマッピングする。 このオプションは、 root 以外の uid には適用されない。他にも 注意すべき uid は存在する (例えば bin など) ので、注意する必要がある。
no_root_squash
root squashing を無効にする。 このオプションは主にディスクレスクライアントにとって便利である。
all_squash
全ての uid とgid を anonymous にマッピングする。 これは NFS エクスポートされた公開 FTP ディレクトリや、 news のスプールディレクトリ等に便利である。 これと逆のオプションは no_all_squash であり、こちらがデフォルトになっている。
anonuid および anongid
これらのオプションは anonymous アカウントの uid と gid を明示的にセット する。これは、全てのリクエストが一人のユーザからになるような PC/NFS clients にとって主に有効である。 例えば、 以下の「例」のセクションでの /home/joe なるエクスポートエントリを見てほしい。 この例では、(joe からのものであると思われる) 全てのリクエストが uid 150 に マッピングされる。

例

# sample /etc/exports file
/               master(rw) trusty(rw,no_root_squash)
/projects       proj*.local.domain(rw)
/usr            *.local.domain(ro) @trusted(rw)
/home/joe       pc001(rw,all_squash,anonuid=150,anongid=100)
/pub            (ro,insecure,all_squash)

1 行目は、 master と trusty に対してすべてのファイルシステムの マウント許可を出している。 書き込みの許可に加え、さらに trusty に対しては、すべての uid squashing も無効にしている。 2 行目と 3 行目は、ホスト名へのワイルドカードの利用と、ネットグループ (@trusted のエントリ) の例である。 4 行目は、上で述べた PC/NFS クライアント用エントリの例である。 5 行目は、公開 FTP ディレクトリを世界中の全てのホストにエクスポートしている。 すべてのリクエストは nobody アカウントで実行される。 またこのエントリ中の insecure オプションによって、 NFS 用 port を使わないように実装された NFS クライアントからのアクセスも許可している。

ファイル

/etc/exports

翻訳

最後に検索