Ubuntu16.04でNFSファイル共有サーバーを構築する方法

NFS は Network File System （Network File System）の略で、分散ファイルシステムプロトコルであり、クライアントホストがローカルファイルシステムのようにネットワークを介してサーバー側ファイルにアクセスできるようにします。つまり、リモートサーバーファイルをローカルファイルのディレクトリ構造に直接マウント（マウント）してアクセスできます。

1.ソフトウェアのインストール

サーバー側は、** nfs-kernel-server **ソフトウェアパッケージをインストールする必要があります。

$ sudo apt-get update 
$ sudo apt-get install nfs-kernel-server

2、サーバー構成

デフォルトでは、共有ディレクトリがNFSサーバーで定義されている場合、ディレクトリ内のすべてのファイルとそのサブディレクトリにアクセスできます。

セキュリティ上の理由から、スーパーユーザー（つまり、ルートユーザー、UID = 0およびGID = 0）のアクセス許可を必要とするクライアントでのファイル操作は、デフォルトでUID = 65534およびGID = 65534にマップされます。ユーザー、それはUbuntuシステムのnobody：nogroupです。

たとえば、クライアントがルート権限を使用してマウントされた共有ディレクトリにファイルを作成すると、ファイルの所有者と所有者グループは自動的に** root：ではなく** nobody：nogroup になります。ルート。

サーバー側に共有ディレクトリを作成する

sudo mkdir -p /var/nfs/gernel 
sudo mkdir -p /var/nfs/public 
sudo chown nobody:nogroup /var/nfs/gernel

エクスポートファイルを変更する

指定されたクライアントホストがNFSサーバーによって定義された共有ファイルにアクセスできるようにするには、対応するレコードをサーバー側の / etc / exportsファイルに追加する必要があります。

ファイルの形式は次のとおりです。

Directory Host（Options ...）Host（Options）＃comment / etc / exportsファイルの詳細な構文と形式については、 manexportsを参照してください。

ファイルの例：

/var/nfs/gernel 192.168.56.0/24(rw,insecure,sync,no_subtree_check)/var/nfs/public*(ro,insecure,sync,no_subtree_check)/home/starky 192.168.56.1(rw,insecure,no_root_squash,sync,no_subtree_check)

最初のレコードは、** 192.168.56.0/24サブネット内のすべてのホストが var / nfs / kernelディレクトリをマウントでき、読み取りおよび書き込み（ rw **）権限を持っていることを示しています。

2番目のレコードは、すべてのホストが / var / nfs / publicディレクトリをマウントでき、読み取り専用（** ro **）権限を持つことができることを示しています

3番目のレコードは、クライアントIPアドレス192.168.56.1のホストが / home / starkyディレクトリをマウントでき、読み取りおよび書き込み権限と、root権限（UID = 0、GID = 0）を持つすべてのファイルを持っていることを示しています。デフォルトでは、操作はnobody：nogroupにマップされず、所有者（グループ）はルートのままです（** no_root_squash **）

安全でないオプション：任意のポートを介したリモートアクセスを許可する

同期オプション：要求に応答する前に、NFSサーバーにファイルの変更をディスクに書き込むように強制します（クライアントとサーバー間のファイルコンテンツの一貫性を強調しますが、ファイル操作の効率を低下させます）。

no_subtree_checkオプション：** subtree_check **を無効にします。 subtree_checkは、リクエストを受信したときに、指定されたディレクトリ構造でファイルがまだ使用可能かどうかをチェックするようにサーバーを設定するために使用されます（このオプションにより、エラーが発生する場合があります。ファイルの名前が変更されると、ファイルはクライアント側で開かれます）。

3つ目は、クライアントが共有ディレクトリをマウントする

nfsサーバー上の共有ディレクトリを一覧表示します

$ showmount -e 192.168.56.102
Exports list on 192.168.56.102:/home/starky            192.168.56.1/var/nfs/public*/var/nfs/gernel           192.168.56.0/24

マウントポイントを作成する

sudo mkdir -p /mnt/nfs/gernel 
sudo mkdir -p /mnt/nfs/public 
sudo mkdir -p /mnt/nfs/starky

リモートディレクトリをマウントする

sudo mount 192.168.56.102:/var/nfs/gernel /mnt/nfs/gernel 
sudo mount 192.168.56.102:/var/nfs/public/mnt/nfs/public 
sudo mount 192.168.56.102:/home/starky /mnt/nfs/starky

許可テスト

スクリーンショットに示されているように：

nfsパーミッションテスト

NFSの権限設定は、Linuxファイルシステムの権限管理に基づいています。つまり、クライアントがリモート共有ディレクトリをマウントした後、それらをローカルディスクディレクトリとして扱います。これもファイル所有者（グループ）と対応する権限設定に基づいています。アクセスを制限します。

gernelディレクトリの所有者（グループ）はnobody：nogroup（65534：65534）であるため、ディレクトリには読み取りおよび書き込み権限がありますが、root以外のユーザーは新しい操作を実行できません。 NFSのデフォルトのセキュリティメカニズムにより、rootユーザーは自動的にnobody：nogroupにマップされます。

クライアントとサーバーにstarkyという名前のユーザーがいて、そのUID：GIDが1000：1000であるため、サーバーの / home / starkyディレクトリには、クライアントのstarkyユーザーが直接アクセスできます。また、** no_root_squash オプションがあるため、 sudo **コマンドによって作成されたファイルの所有者は引き続きrootです（誰にもマップされなくなります）。

もちろん、これによりセキュリティ上の問題が発生します。たとえば、複数のクライアントにUID（GID）が1000のユーザーが同時にいる場合（ユーザー名に関係なく）、これらのユーザーはサーバーの / home / starkyディレクトリでファイルのアクセス許可を共有します。。

第4に、共有ディレクトリはシステムの起動時に自動的にマウントされます

/ etc / fstabファイルを編集して、共有ディレクトリをマウントするマウント操作をシステムの固定構成にすることができます（手動で入力したマウントコマンドは一時的なマウントであり、再起動後に自動的にアンマウントされます）。これにより、システムは再起動後に自動的にマウントできます。リモートファイルシステムをロードします。 / etc / fstabファイルのサンプルコンテンツは次のとおりです。

# filesystem          mountpoint    fstype flags            dump  fsck
192.168.56.102: /var/nfs/gernel /mnt/nfs/gernel nfs   rw,bg,intr,hard,nodev,nosuid 00192.168.56.102:/var/nfs/public/mnt/nfs/public nfs4  ro,bg,intr,soft,nodev,nosuid 00192.168.56.102:/home/starky   /mnt/nfs/starky nfs   rw,bg,intr,hard,nodev,nosuid 00
付録：

付録：

1. / etc / exportsファイルのホスト形式

/ etc / exportsファイルの形式は次のとおりです。DirectoryHost（Options ...）Host（Options）＃comment

ホスト項目は、対応する共有ディレクトリにアクセスできるホストを指定するために使用され、その形式は次のタイプに分類できます。

単一のホスト

ホストアイテムは、1つ以上の個別のTCP / IPホスト名またはIPアドレスにすることができます

admin
admin.starky.net
192.168.56.101

IPサブネット

10.0.0.0 /255.0.0.0172.16.0.0/255.255.0.0192.168.56.0/24

TCP / IPドメイン

ワイルドカードを使用すると、特定のドメイン内のホストのすべてまたは一部を指定できます

*. starky.net
* craft.starky.net
???. starky.net

NISグループ

@ groupを使用して、特定のNISグループ内のすべてのホストのアクセス許可を指定できます

2. / etc / exportsファイルのオプション

オプション	説明
ro	読み取り専用アクセス
rw	読み取りおよび書き込み権限（デフォルト）
rw = list	リストを介して書き込み権限を持つクライアントホストを指定し、他のホストには読み取り専用権限があります
root_squash	UID0とGID0をanonuidとanongidにマップします（つまり、Ubuntuシステムではnobodyとnogroup）
no_root_squash	root権限を必要とするファイル操作を許可します。セキュリティ上のリスクがあります
all_squash	主に信頼できないホストの場合、すべてのUIDとGIDを匿名形式にマップします
anonuid = xxx	クライアントのルート権限の操作にマップする必要があるUIDを指定します（デフォルトは65534）
anongid = xxx	クライアントのルート権限の操作にマップする必要があるGIDを指定します（デフォルトは65534）
安全でない	任意のポートを介したリモートアクセスを許可する
async	サーバーは、ハードディスクに書き込む前にクライアントの書き込み要求に応答できます
wdelay	遅延して複数のクライアントからのファイル更新を同期します
sec = flavor	sys（UNIX認証）、dh（DES）、krb5i、krb5p、none（匿名アクセス）など、共有ディレクトリのセキュリティ認証方法を指定します

3. NFSマウントオプション

オプション	説明
rw	ファイルシステムを読み取り/書き込みモードでマウントします（rwもサーバーで定義する必要があります）
ro	ファイルシステムを読み取り専用モードでマウントする
bg	マウントが失敗した場合（サーバーが応答しない場合）、バックグラウンドで他のマウント要求を実行してみてください
ハード	サーバーが応答しない場合は、サーバーが応答するまで要求を繰り返します
ソフト	サーバーが応答しない場合は、要求を繰り返し、一定時間後にエラーを返します。常にブロックすることはありません
intr	ユーザーがブロックされたファイル操作を中断できるようにします（そしてエラーを返します）
nointr	ユーザーがクライアントファイルの操作要求を中断できないようにする
retrans = n	ソフトモードで、エラーを返す前に要求を繰り返す回数を指定します
timeo = n	タイムアウト後にリクエストを繰り返す時間間隔を設定します（単位1/10秒）
rsize = n	読み取りバッファサイズをnバイトに設定
wsize = n	書き込みバッファサイズをnバイトに設定
sec = flavor	セキュリティ検証方法を設定する
proto = proto	送信プロトコルを設定します。NFSv4はTCPである必要があります

4. NFSプロトコルの議論

転送プロトコル

元のNFSv2は、パフォーマンス上の理由からUDPプロトコルを使用していました。NFSは独自のパケットシーケンスの再編成およびエラーチェック機能を追加しましたが、UDPもNFSもブロッキング制御アルゴリズムを備えていないため、インターネット環境での十分なパフォーマンスの欠如。

NFSv3は、UDPプロトコルとTCPプロトコルのどちらかを選択できます。 NFSv4はTCPプロトコルのみを使用できます。

CPU、メモリ、その他のハードウェアデバイス、およびネットワーク伝送速度の向上に伴い、パフォーマンス要件によるUDPプロトコルの最初の選択は不要になりました。

State

NFSv2とNFSv3はステートレス接続です。サーバーはクライアントによる共有ディレクトリのマウントを追跡しませんが、「Cookie」を使用してマウントの成功を記録します。「Cookie」はサーバーが再起動するため削除されず、サーバーがダウンした後もクライアントの接続情報を保持するために使用できます。

NFSv4はステートフル接続です。クライアントとサーバーの両方がファイル操作レコードとファイルロックステータスを維持します。したがって、「Cookie」を使用する必要はなくなりました。

ファイルロック

以前のバージョンのNFSプロトコル（v2およびv3）はステートレス接続であり、どのホストがどのファイルを使用しているかを認識していません。ただし、ファイルロックを実現するには、ステータス情報を取得する必要があります。したがって、初期のプロトコルのファイルロックはNFSとは独立して実装されます。

NFSv4は、ファイルロックの実装をコアプロトコルに統合します。これにより複雑さが増しますが、以前のバージョンの多くの問題も解決されます。

ただし、V2およびV3プロトコルを使用するクライアントと互換性を持たせるには、独立した** locked および statd **デーモンが引き続き必要です。

安全関連

NFSプロトコルは、当初、設計時にセキュリティに注意を払っていませんでした。NFSv4は、より強力なセキュリティサービスとID検証のサポートを導入することにより、プロトコルのセキュリティを強化しました。

従来のNFSプロトコルは、主にUNIXユーザーおよびグループIDに基づくAUTH_SYS認証を使用します。このように、クライアントはUIDとGIDを送信し、それをサーバー上の / etc / passwdファイルの内容と比較して、クライアントが持っている権限を判別するだけで済みます。

したがって、複数のクライアントに同じUIDのユーザーがいる場合、これらのユーザーには同じファイル権限があります。さらに、root権限を持つユーザーは、** su **コマンドを介して任意のUIDログインに切り替えることができ、サーバーはそれに応じて対応するUID権限をユーザーに付与します。

上記の問題を防ぐために、サーバーは、NFSPRCSEC_GSSと組み合わせた** Kerberos **などのより堅牢な認証メカニズムを使用することを選択できます。

NFS共有ディレクトリのアクセス制御は、 / etc / exportsファイルで定義されたホスト名またはIPアドレスに基づいています。ただし、クライアントはIDとIPアドレスを簡単に改ざんする可能性があり、セキュリティ上の問題が発生する可能性もあります。

NFSv4は、送信プロトコルとしてTCPのみを使用し、通常、データ送信用にポート2049のみを開きます。ファイアウォールを構成するときは、2049ポートの制限を解除することに加えて、データ送信の送信元アドレスと宛先アドレスに常に注意を払う必要があります。

5. Windowsシステムマウント共有ディレクトリ

win10システムは、デフォルトではNFS共有ディレクトリをマウントできません。コントロールパネル（プログラム）（プログラムと機能）を入力して、Windows機能を有効または無効にし、** NFSサービス**を確認する必要があります。

nfsサービスを有効にする

次に、** mount **コマンドを使用して共有ディレクトリをマウントできます。

共有ディレクトリをマウントするmountコマンド

WindowsシステムはLinuxのようなユーザー管理を使用しないため、マウントされた共有ディレクトリは読み取りのみが可能で、書き込みはできません。

ファイルを書き込めません

解決策は、レジストリに2つの** DWORD **値を作成して、匿名ユーザーのUIDとGIDとして使用することです。

デフォルトパラメータであるUIDとGIDのマウントオプションは両方とも-2です。

デフォルトのマウントオプション

** regedit （ regedit ）と入力し、HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ ClientForNFS \ CurrentVersion \ Defaultに移動して、 AnonymousUid と AnonymousGid **という名前の2つの新しいDWORDを作成できます。（32ビット）値を使用する必要のある数値に変更します（0に変更しました。これはLinuxシステムのrootユーザーに対応します。0以外の数値に変更する必要がある場合は、最初に16に変換するように注意してください）。

このときのマウントオプションは次のようになります。

UIDとGIDを変更する

変更が有効にならない場合は、コンピューターを再起動してください。

参考資料

UNIX and Linux System Administration Handbook, 4th Edition

How to Mount an NFS Share Using a Windows 10 Machine

以上が本稿の内容ですので、皆様のご勉強に役立てていただければ幸いです。