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