.\" .\" Japanese Version Copyright (c) 1997 ISHIOKA Takashi .\" all rights reserved. .\" Translated Mon Sep 8 14:02:18 1997 .\" by ISHIOKA Takashi .\" Mon Feb 9 15:16:20 1998: correction .\" Modified Wed 11 Nov 1998 by NAKANO Takeo .\" Updated & Modified Sat Jan 12 19:02:55 JST 2002 .\" by Yuichi SATO .\" Modified Wed 9 Oct 2002 by NAKANO Takeo .\" Updated & Modified Sun 26 Mar 2006 by Yuichi SATO .\" .TH EXPORTS 5 "28 October 1999" .UC 5 .SH 名前 exports \- (カーネルベースの NFS で) エクスポート (export) される NFS ファイルシステム .SH 書式 .B /etc/exports .SH 説明 .I /etc/exports ファイルは、 NFS のクライアントにどのファイルシステムをエクスポート (export) してよいか、 というアクセスコントロールリストを与える。 これは .BR exportfs (8) によって使用され、NFS マウントデーモン .BR mountd (8) と、カーネルベースの NFS ファイルサーバデーモン .BR nfsd (8) とに情報を与える。 .PP このファイルの書式は SunOS の .I exports ファイルと似ている。 それぞれの行には、エクスポートポイントと、 そのポイントにあるファイルシステムをマウントできるクライアントを スペースで区切って指定したリストが書かれている。 リストされたクライアントの直後には、 そのクライアント向けのエクスポートオプションをコンマで区切ってリスト指定し、 リスト全体を括弧で括って置くこともできる。 クライアント名とこのオプションリストとの間にはスペースを入れてはいけない。 .PP 空行は無視され、# 以降行末まではコメントとみなされる。 行末にバックスラッシュをおけば、エントリは次の行に継続できる。 エクスポート名に空白が含まれる場合は、ダブルクォートで括る。 エクスポートパス名には、 空白やその他通常は使われない文字を指定することもできる。 このような文字を使う場合は、バックスラッシュの後に 3 桁の 8 進数で文字コードを指定する。 .SS マシン名のフォーマット NFS クライアントはいろいろな方法で指定できる。 .IP "single host" これはもっとも普通のフォーマットである。ホストの指定には、 レゾルバが認識できる省略形、FQDN、IP アドレスのどれを用いてもよい。 .IP "netgroups" NIS のネットグループを .I @group のように与えることができる。ネットグループの各メンバーは、 ホストの部分だけが取り出され、メンバーに入れられる。 ホストの部分が空だったり、単一のダッシュ (\-) だったものは無視される。 .IP ワイルドカード マシン名の指定には、ワイルドカード文字として \fI*\fP と \fI?\fP を 用いることができる。これらを使うと \fIexports\fR ファイルをコンパクトにできる。 例えば \fI*.cs.foo.edu\fR はドメイン \fIcs.foo.edu\fR にあるすべての ホストにマッチする。 これらのワイルドカード文字はドメイン名のドット (.) にもマッチするので、 ここで指定されたパターンは \fIcs.foo.edu\fR の任意のサブドメイン内の 全てのホストにマッチする。 .IP "IP networks" ディレクトリを IP の (サブ) ネットワークに存在するすべてのホストに 同時にエクスポートすることもできる。 これには IP アドレスとネットマスクのペアを .I address/netmask のように指定すればよい。 ここで netmask は 10 進数をドットで区切って指定することもできるし、 連続するマスクの長さで指定することもできる (例えば、ネットワークベースアドレスに `/255.255.252.0' を追加した場合でも、 `/22' を追加した場合でも、ホスト部が 10 ビットの同じサブネットワークになる)。 ワイルドカード文字は、通常 IP アドレスに対しては動作しない。 ただし DNS の逆引きが失敗すると、たまたま動作してしまうこともあり得る。 '''.TP '''.B =public ''' これは特殊な意味を持つ「ホスト名」で、その前に与えられたディレクトリ ''' が public root ディレクトリであることを示す (WebNFS と ''' public root ハンドルの詳細に関しては ''' .BR nfsd (8) ''' の WebNFS のセクションを参照のこと)。この書式を用いる際には、 ''' .B =public ''' がその行での唯一のホスト名エントリでなければならない。また ''' エクスポートオプションを指定してはならない。この指定によって、 ''' ディレクトリが実際にエクスポートされるわけでは\fBない\fPことに ''' 注意すること。エクスポートオプションを、 ''' これとは別のエントリで指定する必要がある。 '''.PP ''' public root パスは ''' .I nfsd ''' を ''' .B \-\-public\-root ''' オプションを指定して起動することによっても指定できる。 ''' public root の複数指定は無視される。 .SS RPCSEC_GSS セキュリティ エクスポートへのアクセスを rpcsec_gss セキュリティを使って制限するには、 クライアントとして特別な文字列 "gss/krb5" を使うこと。 rpcsec_gss とクライアントの IP アドレスによる資格を 同時に要求することはできない。 .PP .SS 一般的なオプション .I exportfs は以下のエクスポートオプションを受け付ける。 .TP .IR secure "\*d このオプションを指定すると、IPPORT_RESERVED (1024) より小さな internet ポートから発したリクエストしか受けつけない。 このオプションはデフォルトで有効になっている。 無効にするには .I insecure と指定する。 .TP .I rw この NFS ボリュームに対して、書き込みと読み出しリクエストの両方を許可する。 デフォルトではファイルシステムを変更する全ての書き込みを拒否する (これは .I ro オプションで明示した場合も同じ)。 .TP .I async このオプションは NFS サーバを NFS プロトコルに違反させ、 あるリクエストによってなされた変更が安定した保存場所 (例えばディスクドライブ) に渡される前に、 そのリクエストに応えるようにする。 このオプションを用いると通常は性能が向上するが、 クリーンでないサーバの再起動 (つまりクラッシュ) によってデータが失われたり破壊されうるという代償を伴う。 nfs-utils の 1.0.0 まででは、このオプションがデフォルトであった。 このリリース以降は .I sync がデフォルトとなり、 .I async は必要な場合は明示的に指定しなければならない。 システム管理者にこの変更を知らせるため、 .I sync と .I async のいずれも指定されていない場合、`exportfs' は警告を発する。 .TP .I no_wdelay このオプションは同時に .I async が設定されていると効果を持たない。 NFS サーバは、書き込み要求を受けたとき、 関連した別の書き込み要求が実行中である (または近々到着する) と予想した場合、 その要求のディスクへの反映を少し遅らせる。 これにより一度の操作で複数の書き込み要求が ディスクに反映されるので、性能が向上する。 NFS サーバが受け取るデータの書き込み要求が、 主として関連性のない小さなものの場合には、 この動作は実際には性能を低下させてしまうので、 .I no_wdelay を指定して無効にできる。 デフォルトの動作を .I wdelay オプションで明示的に指定することもできる。 .TP .I nohide このオプションは IRIX NFS で提供される同名のオプションを元にしている。 サーバが 2 つのファイルシステムをエクスポートし、 そのうちの 1 つが他方にマウントされている場合、 クライアントが両者にアクセスを行うには、 両方のファイルシステムを明示的にマウントしなければならない。 親の方をマウントしただけでは、 もう一方のファイルシステムがマウントされているディレクトリは空に見える。 このようなファイルシステムは "hidden" といわれる。 hidden にしたくないファイルシステムに .I nohide オプションを設定すれば、 適切な権限のあるクライアントは変更を知らされることなく、 親から子のファイルシステムに移動できる。 しかし NFS クライアントのなかには、 このような状況 (例えば、見かけ上 1 つのファイルシステムで 2 つのファイルが同じ inode 番号を持つような状況) ではうまく動作しないものもある。 .I nohide オプションは現在のところ .I "single host" エクスポートでしか効果がない。 このオプションの動作は、 netgroup, subnet, wildcard などによるエクスポートでは信頼性がない。 このオプションは状況によってはとても便利であるが、よく注意して、 かつクライアントシステムがその状況下で効果的に動作することを確認した後で 使うべきである。 このオプションは .I hide で明示的に無効にできる。 .TP .I no_subtree_check このオプションのサブツリーのチェックを無効にする。 これには簡単なセキュリティの意味もあるが、 環境によっては信頼性を向上させることもできる。 ファイルシステムのサブディレクトリがエクスポートされているが、 ファイルシステム全体がエクスポートされていない場合、 NFS リクエストがくると、サーバは対応するファイルシステムに アクセスされたファイルがあるかをチェックするだけでなく (これは簡単)、 エクスポートされたツリーのなかにあるかもチェックしなければならない (これは難しい)。 このチェックは .I subtree_check とよばれる。 このチェックを行うには、サーバはクライアントに渡す 「ファイルハンドル」に、ファイルの場所に関する情報を入れなければならない。 こうすると、クライアントがファイルをオープンしている間に、 アクセスしているファイルの名前が変更されると問題が起こる (ただし多くの簡単なケースでは動作する)。 サブツリーのチェックは、 ファイルシステムが .I no_root_squash (下記参照) でエクスポートされていて、 ファイル自身にはより一般的なアクセス権がある場合に、 root しかアクセスできないディレクトリ内のファイルが root によってのみアクセスされているかを確認するのにも使える。 一般的な指針として、ホームディレクトリは サブツリーのチェックを無効にしてエクスポートすべきである (通常各ユーザの親ディレクトリのレベルでエクスポートされ、 かつファイル名の変更が多いため)。 大抵は読み込みのみで、ほとんどファイル名の変更が行われない ファイルシステム (たとえば /usr や /var) で、 それらのサブディレクトリがエクスポートされるような場合には、 サブツリーのチェックを有効にしてエクスポートした方がよいかもしれない。 サブツリーのチェックを行うデフォルトの動作は、 .I subtree_check で明示的に指定することもできる。 .TP .I insecure_locks .TP .I no_auth_nlm このオプション (2 つのオプション名は同じ意味) を指定すると、 NFS はロック要求 (NLM プロトコルを使った要求) の際に認証を必要としなくなる。 通常 NFS サーバは、ファイルの読み取りアクセス権限を持つユーザに対し、 信用証明 (credential) を保持するために、ロック要求を必要とする。 このフラグを指定すると、アクセスチェックが行われない。 初期の NFS クライアントの実装ではロック要求の際に信用証明を送らなかったが、 現在でもこのような昔の実装を元にした多くの NFS クライアントが存在する。 全ての人が読み込み可能なファイルのみをロックしたい場合は、 このフラグを使うこと。 NLM 要求の際に認証を求めるデフォルトの動作は、 同じ意味をもつ .I auth_nlm または .I secure_locks のどちらか (意味は全く同じ) で明示的に指定できる。 '''.TP '''.I noaccess ''' このオプションを付けたクライアントは、そのディレクトリ以下のすべての ''' ファイルに対してアクセスできなくなる。あるディレクトリ階層を ''' クライアントにエクスポートするとき、特定のサブディレクトリを除きたい ''' 場合などに便利である。 noaccess フラグが付いたディレクトリの ''' クライアントからの見え方は、非常に制限されたものとなる。 ''' ディレクトリ属性と、 `.' および `..' の閲覧だけが許される。 ''' readdir に対して返されるエントリもこの 2 つだけになる。 '''.TP '''.IR link_relative ''' 絶対パス形式のシンボリックリンクを相対パス形式のリンクに変換する ''' (絶対パス形式とは、リンクの内容が "/" で始まるものである)。 ''' 変換は次のように行われる。 ''' まずリンクが置かれているディレクトリの、サーバのルートからの ''' 深さを取得する。そしてその数だけ '../' を絶対リンクの前に付加する。 ''' マウントポイントのルートからの位置が異なる場合、 ''' この変換には微妙な (おそらく障害の原因となる) あいまいさが ''' 含まれる可能性がある。 '''.TP '''.IR link_absolute ''' 全てのシンボリックリンクをそのままにする。 これがデフォルトである。 .TP .IR mountpoint= path .TP .I mp このオプションを使うと、マウントに成功した場合にのみ、 そのディレクトリをエクスポートできる。 パスが指定されない場合 (たとえば .IR mountpoint " または " mp の場合)、エクスポートポイントはマウントポイントでなければならない。 そうでなければ、エクスポートポイントはエクスポートされない。 これにより、マウントポイント以下のディレクトリが、 事故によってエクスポートされてしまわないようにすることができる。 ここでいう事故とは、例えばディスクエラーによって ファイルシステムがマウントに失敗するような場合である。 パスが指定される場合 (たとえば .IR mountpoint= "/path または " mp= /path の場合)、マウントされるパスは、 エクスポートされるエクスポートポイントに対応する マウントポイントでなければならない。 .TP .IR fsid= num このオプションは、通信で使用されるファイルハンドルとファイル属性の ファイルシステム識別部として、 ファイルシステムがマウントされているブロックデバイスの メジャー番号とマイナー番号から導き出された数ではなく、 .I num を使う。 任意の 32 ビットの数値が使えるが、 エクスポートされるファイルシステム間で一意 (unique) でなければならない。 これは NFS のフェイルオーバー (failover, 代替引き継ぎ) で役立つ。 フェイルオーバーのペアとなる両方のサーバーが、 共有されるファイルシステムに対して 同じ NFS ファイルハンドルを使うことが保証されるので、 フェイルオーバー後にファイルハンドルが失効するのを避けることができる。 Linux のファイルシステムの中には、 ブロックデバイスにマウントされていないものもある。 これらのファイルシステムを NFS でエクスポートするには、 .I fsid オプションを使う必要がある (ただし、このオプションはまだ充分ではない)。 値 0 は NFSv4 で使う場合には特別な意味を持つ。 NFSv4 にはエクスポートされるファイルシステム全体のルートという概念がある。 fsid=0 でエクスポートされたエクスポートポイントは、 このルートとして使用される。 .SS ユーザ ID のマッピング .PP サーバマシン上のファイルに対する .I nfsd によるアクセスコントロールは、 それぞれの NFS RPC request の際に与えられる uid と gid に基づいている。 ユーザは通常、 サーバ上にある自分のファイルには、それが普通のファイルシステム上に あるのと同様にアクセス可能であることを期待している。 これにはクライアントとサーバ上で用いられる uid と gid がそれぞれ 同じである必要があるが、 これは常に真であるとは限らず、望ましいとも限らない。 .PP クライアントマシンの root が NFS サーバのファイルにアクセスするとき、 サーバの root として扱われてしまうのは、ほとんどの場合は望ましくない。 このため uid 0 は普通は別の id (anonymous や .I nobody uid) にマッピングされる。 この動作は `root squashing' と呼ばれるが、これがデフォルトである。 .I no_root_squash を使えばオフにすることができる。 .PP デフォルトでは、 ''' .I nfsd ''' は ''' 起動時に password ファイル中の ''' .I nobody ''' ユーザを参照して、 ''' anonymous の uid と gid を得ようとする。 ''' もしそれが見つからない場合には、 .I exportfs は squash アクセスに -2 (つまり 65534) という uid と gid を用いる。 これらの数値は .IR anonuid " と " anongid オプションによって変更できる。 '''.PP ''' これに加え、 ''' .I nfsd ''' によって nobody に割り当てるべき適当な ''' uid と gid とを指定することもできる。 最後に、 .I all_squash オプションを指定すれば、 全ての user request を anonymous uid に割り当てることもできる。 '''.PP ''' マシンごとに uid が異なるような場合への導入を容易にするため、 ''' .I nfsd ''' ではサーバの uid をクライアントの uid に (あるいはその逆に) ''' 動的にマッピングする手法をいくつか提供している。 ''' 静的なマッピングファイル、 NIS ベースのマッピング、 ''' .I ugidd ''' ベースのマッピング、である。 ''' .PP ''' .I ugidd ''' ベースのマッピングは ''' .I map_daemon ''' オプションを指定して UGID RPC プロトコルを使えば可能となる。 ''' このプロトコルを動かすにはクライアントで ''' .IR ugidd (8) ''' mapping デーモンを動作させる必要がある。 ''' これは 3 つある方法の中で、セキュリティ的には最悪である。 ''' なぜなら ''' .I ugidd ''' を動作させると、誰でもクライアントに問い合わせて、有効なユーザ名の ''' リストを入手できてしまうからである。 ''' .I ugidd ''' へのアクセスを特定のホストのみに制限して、身を守ることもできる。 ''' これには許可するホストのリストを ''' .I hosts.allow ''' または ''' .I hosts.deny ''' ファイルに記述すればよい。サービス名は ''' .I ugidd ''' である。これらのファイルの文法については、 ''' .IR hosts_access (5) ''' を参照してほしい。 '''.PP ''' 静的なマッピングは ''' .I map_static ''' オプションによって動作させることができる。このオプションは、マッピングを ''' 記述したファイルの名前を引数にとる。 ''' NIS ベースのマッピングは、クライアントの NIS サーバに問い合わせて、 ''' サーバのユーザ名・グループ名からクライアントのユーザ名・グループ名への ''' マッピング情報を入手する。 .PP 以下にマッピングオプションの完全なリストをあげる: .TP .I root_squash uid/gid が 0 のリクエストを annonymous uid/gid にマッピングする。 このオプションは、 root 以外の uid には適用されない。他にも 注意すべき uid は存在する (例えば .I bin など) ので、注意する必要がある。 .TP .I no_root_squash root squashing を無効にする。 このオプションは主にディスクレスクライアントにとって便利である。 '''.TP '''.IR squash_uids " and " squash_gids ''' このオプションは、annonymous にマッピングされる uid や gid のリストを ''' 明示するためのものである。 id のリストとしては以下のような指定が有効で ''' ある: '''.IP '''.IR squash_uids=0-15,20,25-50 '''.IP ''' 通常の squash リストはもっとずっと簡単なものになるだろうが。 .TP .I all_squash 全ての uid とgid を anonymous にマッピングする。 これは NFS エクスポートされた公開 FTP ディレクトリや、 news のスプールディレクトリ等に便利である。 これと逆のオプションは .I no_all_squash であり、こちらがデフォルトになっている。 '''.TP '''.IR map_daemon ''' このオプションは 動的な uid/gid のマッピングを有効にする。 ''' NFS request 中のそれぞれの uid はサーバ上の対応する uid に変換され、 ''' NFS reply 中の uid はそれぞれ逆に変換される。 ''' このオプションを用いるには、クライアントホストで ''' .BR rpc.ugidd (8) ''' が動作していることが必要である。 ''' デフォルトでは、全ての uid を変えない ''' .IR map_identity ''' となっている。 ''' 普通の squash オプションは、動的なマッピングか否かを気にすることなく ''' 適用できる。 ''' .TP ''' .IR map_static ''' このオプションを指定すると静的なマッピングが可能となる。 ''' uid/gid マッピングが記述されたファイル名を以下のように指定する。 '''.IP '''.IR map_static=/etc/nfs/foobar.map '''.IP ''' ファイルのフォーマットは以下のようなものである。 '''.IP '''.nf '''.ta +3i '''# Mapping for client foobar: '''# remote local '''uid 0-99 - # squash these '''uid 100-500 1000 # map 100-500 to 1000-1400 '''gid 0-49 - # squash these '''gid 50-100 700 # map 50-100 to 700-750 '''.fi '''.TP '''.IR map_nis ''' このオプションを指定すると NIS ベースの uid/gid マッピングが可能となる。 ''' 例えば、サーバが uid 123 の指定を受けると、サーバはまずその uid に ''' 対応するローカルのログイン名を調べる。次に NFS クライアントの NIS サーバに ''' 接続して、そのログイン名に対応する uid を取得する。 '''.IP ''' これを行うには、 NFS サーバがクライアントの NIS ドメインを ''' 知っていなければならない。このドメインは ''' .I map_nis ''' オプションの引数として以下のように指定する。 '''.IP '''.I map_nis=foo.com '''.IP ''' ただここに NIS ドメインを記述するだけでは、通常は充分ではない。 ''' .I nfsd ''' が NIS サーバにコンタクトできるようにするには、他の作業が必要と ''' なるだろう。利用しているディストリビューションが NYS ライブラリを ''' 使っている場合は、クライアントのドメインのサーバを ''' .I /etc/yp.conf ''' に一つ以上指定する必要があるだろう。 ''' 他の NIS ライブラリを用いている場合には、 ''' .I yp.conf ''' によって設定できるような、特殊な ''' .IR ypbind (8) ''' を入手する必要があるかもしれない。 .TP .IR anonuid " および " anongid これらのオプションは anonymous アカウントの uid と gid を明示的にセット する。これは、全てのリクエストが一人のユーザからになるような PC/NFS clients にとって主に有効である。 例えば、 以下の「例」のセクションでの .I /home/joe なるエクスポートエントリを見てほしい。 この例では、(joe からのものであると思われる) 全てのリクエストが uid 150 に マッピングされる。 .IP .SH 例 .PP .nf .ta +3i # 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) '''/pub/private (noaccess) .fi .PP 1 行目は、 master と trusty に対してすべてのファイルシステムの マウント許可を出している。 書き込みの許可に加え、さらに trusty に対しては、すべての uid squashing も無効にしている。 2 行目と 3 行目は、ホスト名へのワイルドカードの利用と、ネットグループ (@trusted のエントリ) の例である。 4 行目は、上で述べた PC/NFS クライアント用エントリの例である。 5 行目は、公開 FTP ディレクトリを世界中の全てのホストにエクスポートしている。 すべてのリクエストは nobody アカウントで実行される。 またこのエントリ中の .I insecure オプションによって、 NFS 用 port を使わないように実装された NFS クライアントからのアクセスも許可している。 ''' 最後の行では、 private ディレクトリへのアクセスをすべての ''' クライアントに対して拒否するようにしている。 ''' .SH 警告 ''' 他の NFS サーバの実装と違い、 ''' この ''' .B nfsd ''' では、例えば ''' .IR /usr " と " /usr/X11R6 ''' のように、あるディレクトリとそのサブディレクトリとの両方を ''' 同じホストにエクスポートすることができる。 ''' この場合、特定の度合がもっとも高いエントリのマウントオプションが適用される。 ''' 例えばクライアントホスト上のユーザが ''' .IR /usr/X11R6 ''' のファイルにアクセスする場合は、 ''' .I /usr/X11R6 ''' のエントリであたえられた マウントオプションが適用される。 ''' これはエントリのホスト指定がワイルドカード(wildcard) もしくは netgroup ''' の場合でも真である。 .SH ファイル /etc/exports ''' .SH 返り値 ''' .BR nfsd (8) ''' か ''' .BR mountd (8) ''' が起動していれば、 ''' ファイルの解釈中のエラーは常に ''' .BR syslogd (8) ''' を用いて報告される。 ''' DAEMON からの NOTICE レベルとなる。 ''' そのとき、未知のホスト全てが報告される。しかし起動時には ''' .BR named (8) ''' が全てのホストを知らない場合もありうる。 ''' したがってホストが見つかるたびに、それらは ''' .BR syslogd (8) ''' に、同じパラメータで報告される。