Provided by: manpages-ja_0.5.0.0.20221215+dfsg-1_all 
名前
exports - (カーネルベースの 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