Network File System

出典: フリー百科事典『ウィキペディア(Wikipedia)』

これはこのページの過去の版です。InTheCastle (会話 | 投稿記録) による 2020年12月24日 (木) 14:50個人設定で未設定ならUTC)時点の版 (→‎概要: NFSの代わりとなりえるRFSについて出典と共に追加。)であり、現在の版とは大きく異なる場合があります。

Network File System(NFS)は主にUNIXで利用される分散ファイルシステムおよびそのプロトコルである[1]1984年サン・マイクロシステムズによって実質的な最初の規格となるNFS version 2 (NFS v2) が発表され、RFC 1094RFC 1813RFC 3530RFC 5661RFC 7530RFC 7862 などによって定義されている。

概要

NFSは、ローカルに接続されたストレージをネットワークを介してリモートの計算機に提供する分散ファイルシステムとそのプロトコルである。マウントされたNFSボリュームは、ネットワーク上にあることを意識せずローカルと同じように利用出来る。NFS v2, v3 では、Network File System#関連プロトコルで述べるように、ファイルロック機能やクォータ管理機能などはNFSプロトコル本体に含まれず、それぞれ別のプロトコルによって提供される。これらは NFS v4 ではプロトコル本体に含まれている。
 ネットワークファイルシステムに代わる方法としてリモートファイルシェアリング(Remote File Sharing英語版)がある。リモートファイルシェアリング(RFS)は、大部分の System V 系 UNIX や BSD 系 SunOS にてオプションである[2]

ポート番号

NFSのサービスは一般的にTCPの2049番ポートで提供される。NFS v4はTCPのみだが、NFS v3はTCPとUDP(同じく2049番ポート)を使える。ボリュームを提供するNFSサーバとそれを利用するクライアント間の遠隔手続き呼出し (RPC) には、NFSの一部として開発されたONC RPCを利用している。NFSv3までは、ファイルロックやマウント要求等のONC RPCに使われるポート番号はポートマッパーによって動的に割り当てられることが一般的であった。そのため、ポート番号を固定するオプションを持たない実装の場合、ファイアウォールによるポート番号ベースの通信制御は困難であった。NFSv4からは、同等の機構がNFS本体に組み込まれ、サーバ-クライアント間の通信にはTCPの2049番ポートのみを利用するようになった。

歴史

NFS version 1

NFS version 1 (NFS v1) は、サン・マイクロシステムズ内の実験にとどまり、対外的なリリースはされなかった。

NFS version 2

NFS v2の仕様は1984年に発表され、1985年にはNFS v2を初めて実装したSunOS 2.0がリリースされた。その後1989年3月には RFC 1094 が取りまとめられ標準化された。 NFS v2の開発にはRusty Sandberg, Bob Lyon, Bill Joy, Steve Kleimanなどが参加していた。元々のNFS v2では通信にUDPのみを利用することになっているが、これはファイルロック機能をNFSの枠組みの外で実装することでプロトコルをステートレスに保つのが目的であった。

NFS version 3

1995年6月に RFC 1813 で定義されたNFS v3では、主に以下の機能追加が行われた。

  • ファイルサイズおよび読み書き時に指定するオフセットの型を32bitから64bitに拡張し、4GiB以上のファイルをサポートした。
  • 書き込み性能を向上させるため、サーバへの非同期書き込みをサポートした。
  • ファイル属性を別途取得するプロシージャ呼び出しを省くために、多くのプロシージャでその返値にファイル属性を追加した。
  • ディレクトリを走査する時、そこに含まれるファイル名に加えファイルハンドルと属性を一度に取得できるREADDIRPLUSプロシージャを追加した。

また、NFS v2の時点ですでにTCPによる転送をサポートするベンダーが複数存在したことから、サン・マイクロシステムズはNFS v3からTCP転送を仕様に追加した。これによりWANを介したNFSがより安定して動作するようになった。

NFS version 4

AFSCIFSの存在を踏まえ、2000年12月に RFC 3010 で、また2003年4月に RFC 3530 で、さらに2015年3月に RFC 7530 で改定されたNFS v4では、性能の向上策、Kerberos認証などの強力なセキュリティ、またステートフルなプロトコルを導入した。NFS v4からはその開発主体がInternet Engineering Task Forceへ移動し、サン・マイクロシステムズに加えネットアップなども規格策定に携わった。

NFS version 4.1 は、2010年1月に RFC 5661 で、2020年8月に RFC 8881 で公開された。

NFS version 4.2 は、2016年11月に RFC 7862 で公開された。

関連プロトコル

NFSに付随するプロトコルは次のようなものがある。

Network Lock Manager (NFS v2, v3)
UNIX System Vに追加されたファイルロック機構
クォータ情報の遠隔通知 (NFS v2, v3)
NFSサーバが管理するクォータの状態をクライアントに通知するもので、rquotaとも呼ばれる。なお、クォータ管理そのものはサーバの役割であり、クライアントはその情報を受け取っているだけである。
WebNFS (NFS v2, v3)
ウェブブラウザとNFSを統合し、ファイアウォールを介した利用を実現するNFS v2, v3の拡張

アクセスコントロール

NFS v2およびNFS v3では、ユーザーのアクセス権限にUNIXのユーザー識別子およびグループ識別子をそのまま用いている。 デフォルトではクライアント側に設定された識別子番号がそのままNFSサーバに渡され、サーバはそれを見てアクセスを制御する。クライアントとサーバ間でグループ識別子を別々に管理している場合では、管理者が用意したサーバ側とクライアント側の識別子対応表を参照するか、クライアントが用意したNISサーバあるいは専用のデーモンugiddをサーバが参照するように設定することでアクセスコントロールを行う。

NFS v4では、ユーザー識別子/グループ識別子を直接使うのではなく、文字列としてのユーザー名/グループ名を使用する。更に、ケルベロス認証を利用したユーザ名ベースのアクセスコントロールを新たにサポートした。

root squash

一般的に、「NFSクライアント上での管理者特権が適切に管理されている」とは限らない[注 1]ため、管理者権限による無制限なアクセスをNFSクライアントに許可することは危険である。そのため、UNIXシステムでスーパーユーザを示す root (NFS v4) ユーザー識別子0 (NFS v2, v3) によるクライアントからのアクセスを、NFSサーバ側でより権限の低いユーザー識別子(例えば NFS v4 では nobody、NFS v2, v3 では65534や-2[注 2]など)に強制的に割り当てるroot_squashという機能を標準で有効にするものが多い。

利用可能なプラットフォーム

1985年SunOS 2.0に最初に実装された後、HP-UXSolarisNEWS-OSEWS-UXLinuxFreeBSDなど多くのUNIX系OSに実装された。その他にもMac OSWindows Server、クライアントWindowsの一部のエディション、NetWareAS/400でも利用できる。WindowsではServices for UNIXがNFSサーバおよびクライアントの機能を提供している。


注釈

  1. ^ 「NFSクライアントからの『管理者を自称するユーザ』によるアクセスでも、それが『真の管理者ユーザ』とは限らず、実際には『管理者を詐称した一般ユーザ』によるアクセス、ということがあり得る」ということ。
  2. ^ ユーザ識別子として伝統的に使用されていた「16ビット長の符号あり整数」としての"-2"は、「16ビット長の符号なし整数」「32ビット長以上の整数」における"65534"と同値となる。かつては識別子"-2"に"nobody"というユーザ名が割り当てられており、その後"nobody"のユーザ識別子は"65534"に変更された。今日のUNIX系システムでは、識別子"65534"や"-2"に対応するユーザ名は"nfsnobody"や"nobody4"などとされている。

関連項目

参考文献

出典

  1. ^ bit 編集部『bit 単語帳』共立出版、1990年8月15日、32頁。ISBN 4-320-02526-1 
  2. ^ Mike Loukides 著、砂原秀樹 監訳『UNIXシステムチューニング』アスキー出版局、1991年7月21日、274頁。ISBN 4-7561-0077-5 

各プラットフォームに関する情報