序章

NFS（Network File System）は、サーバーにリモートディレクトリをマウントできる分散ファイルシステムプロトコルです。 これにより、別の場所にあるストレージスペースを管理し、複数のクライアントからそのスペースに書き込むことができます。 NFSは、ネットワークを介してリモートシステムにアクセスするための比較的迅速で簡単な方法を提供し、共有リソースが定期的にアクセスされる状況でうまく機能します。

このガイドでは、NFSマウントを構成する方法について説明します。

前提条件

このチュートリアルでは、2つのサーバーを使用します。1つはファイルシステムの一部をもう1つと共有します。 フォローするには、次のものが必要です。

チュートリアル全体を通して、ディレクトリを共有するサーバーを host と呼び、これらのディレクトリをマウントするサーバーをclientと呼びます。 それらをまっすぐに保つために、ホストとクライアントの値の代用として次のIPアドレスを使用します。

  • ホスト：203.0.113.0
  • クライアント：203.0.113.256

これらの値を独自のホストおよびクライアントのIPアドレスに置き換える必要があります。

ステップ1—コンポーネントのダウンロードとインストール

まず、各サーバーに必要なコンポーネントをインストールします。

ホスト上

ホストサーバーにnfs-kernel-serverパッケージをインストールします。これにより、ディレクトリを共有できるようになります。 これは、このセッションでaptを使用して実行する最初の操作であるため、インストール前にローカルパッケージインデックスを更新します。

  1. sudo apt-get update

  2. sudo apt-get install nfs-kernel-server

これらのパッケージがインストールされたら、クライアントサーバーに切り替えます。

クライアント上

クライアントサーバーに、nfs-commonというパッケージをインストールする必要があります。これは、不要なサーバーコンポーネントを含めずにNFS機能を提供します。 繰り返しになりますが、インストール前にローカルパッケージインデックスを更新して、最新の情報を確実に入手できるようにします。

  1. sudo apt-get update

  2. sudo apt-get install nfs-common

両方のサーバーに必要なパッケージが用意されたので、それらの構成を開始できます。

ステップ2—ホスト上に共有ディレクトリを作成する

スーパーユーザーアクセスに関してNFSマウントを構成できる2つの主要な方法を説明するために、構成設定が異なる2つの別々のディレクトリを共有します。

スーパーユーザーは、システム上のどこでも何でもできます。 ただし、NFSにマウントされたディレクトリは、それらがマウントされているシステムの一部ではないため、デフォルトでは、NFSサーバーはスーパーユーザー権限を必要とする操作の実行を拒否します。 このデフォルトの制限は、クライアントのスーパーユーザーがrootとしてファイルを書き込んだり、所有権を再割り当てしたり、NFSマウントで他のスーパーユーザータスクを実行したりできないことを意味します。

ただし、クライアントシステムには、マウントされたファイルシステムでこれらのことを実行できる必要があるが、ホストでスーパーユーザーアクセスを行う必要のない信頼できるユーザーがいる場合があります。 NFSサーバーは、これを許可するように構成できますが、リスクの要素が発生するため、ユーザーはホストシステム全体へのルートアクセスを取得できます。

例1：汎用マウントのエクスポート

最初の例では、デフォルトのNFS動作を使用する汎用NFSマウントを作成し、クライアントマシンでroot権限を持つユーザーが、それらのクライアントスーパーユーザー権限を使用してホストと対話することを困難にします。 このようなものを使用して、コンテンツ管理システムを使用してアップロードされたファイルを保存したり、ユーザーがプロジェクトファイルを簡単に共有できるスペースを作成したりできます。

まず、nfsという名前の共有ディレクトリを作成します。

  1. sudo mkdir /var/nfs/general -p

sudoで作成しているため、このディレクトリはホスト上のrootによって所有されています。

  1. ls -la /var/nfs/general



Output
4 drwxr-xr-x  2 root   root    4096 Jul 25 15:26 .

NFSは、セキュリティ対策として、クライアントでのroot操作をnobody:nogroupクレデンシャルに変換します。 したがって、これらの資格情報に一致するようにディレクトリの所有権を変更する必要があります。

  1. sudo chown nobody:nogroup /var/nfs/general

これで、このディレクトリをエクスポートする準備が整いました。

例2：ホームディレクトリのエクスポート

2番目の例の目標は、ホストに格納されているユーザーのホームディレクトリをクライアントサーバーで使用できるようにすると同時に、それらのクライアントサーバーの信頼できる管理者がユーザーを便利に管理するために必要なアクセスを許可することです。

これを行うには、/homeディレクトリをエクスポートします。 すでに存在しているので、作成する必要はありません。 権限も変更しません。 did の場合、ホストマシンにホームディレクトリがある人にはあらゆる種類の問題が発生します。

ステップ3—ホストサーバーでのNFSエクスポートの構成

次に、NFS構成ファイルを詳しく調べて、これらのリソースの共有を設定します。

root権限でテキストエディタで/etc/exportsファイルを開きます。

  1. sudo nano /etc/exports

このファイルには、各構成行の一般的な構造を示すコメントが含まれています。 構文は基本的に次のとおりです。

/ etc / exports
directory_to_share    client(share_option1,...,share_optionN)

共有する予定のディレクトリごとに1行を作成する必要があります。 サンプルクライアントのIPは203.0.113.256であるため、行は次のようになります。 クライアントに一致するようにIPを変更してください。

/ etc / exports
/var/nfs/general    203.0.113.256(rw,sync,no_subtree_check)
/home       203.0.113.256(rw,sync,no_root_squash,no_subtree_check)

no_root_squashを除いて、両方のディレクトリに同じ構成オプションを使用しています。 それぞれの意味を見てみましょう。

  • rw ：このオプションは、クライアントコンピューターにボリュームへの読み取りアクセスと書き込みアクセスの両方を提供します。
  • sync ：このオプションは、応答する前にNFSに変更をディスクに書き込むように強制します。 これにより、応答がリモートボリュームの実際の状態を反映するため、より安定した一貫性のある環境が実現します。 ただし、ファイル操作の速度も低下します。
  • no_subtree_check ：このオプションは、サブツリーチェックを防ぎます。サブツリーチェックは、リクエストごとに、エクスポートされたツリーでファイルが実際にまだ利用可能かどうかをホストがチェックする必要があるプロセスです。 これにより、クライアントがファイルを開いているときにファイルの名前が変更されると、多くの問題が発生する可能性があります。 ほとんどの場合、サブツリーチェックを無効にすることをお勧めします。
  • no_root_squash ：デフォルトでは、NFSはrootユーザーからの要求をサーバー上の非特権ユーザーにリモートで変換します。 これは、クライアントのrootアカウントがホストのファイルシステムをrootとして使用することを防ぐためのセキュリティ機能として意図されていました。 no_root_squashは、特定の共有に対してこの動作を無効にします。

変更が完了したら、ファイルを保存して閉じます。 次に、構成したクライアントが共有を使用できるようにするには、次のコマンドを使用してNFSサーバーを再起動します。

  1. sudo systemctl restart nfs-kernel-server

ただし、実際に新しい共有を使用する前に、共有へのトラフィックがファイアウォールルールで許可されていることを確認する必要があります。

ステップ4—ホストのファイアウォールを調整する

まず、ファイアウォールのステータスをチェックして、ファイアウォールが有効になっているかどうかを確認し、有効になっている場合は、現在許可されているものを確認します。

  1. sudo ufw status



Output
Status: active

To                         Action      From
--                         ------      ----
OpenSSH                    ALLOW       Anywhere
OpenSSH (v6)               ALLOW       Anywhere (v6)

私たちのシステムでは、SSHトラフィックのみが許可されているため、NFSトラフィックのルールを追加する必要があります。

多くのアプリケーションでは、sudo ufw app listを使用して名前で有効にすることができますが、nfsはその1つではありません。 ufwは/etc/servicesでもサービスのポートとプロトコルをチェックするため、名前でNFSを追加できます。 ベストプラクティスでは、許可するトラフィックを引き続き許可する最も制限の厳しいルールを有効にすることをお勧めします。そのため、どこからでもトラフィックを有効にするのではなく、具体的に説明します。

次のコマンドを使用して、ホストのポート2049を開きます。必ず、クライアントのIPアドレスに置き換えてください。

  1. sudo ufw allow from 203.0.113.256 to any port nfs

次のように入力して、変更を確認できます。

  1. sudo ufw status

出力にポート2049から許可されたトラフィックが表示されます。

Output
Status: active

To                         Action      From
--                         ------      ----
OpenSSH                    ALLOW       Anywhere                 
2049                       ALLOW       203.0.113.256        
OpenSSH (v6)               ALLOW       Anywhere (v6)

これは、UFWがクライアントマシンからのポート2049でのNFSトラフィックのみを許可することを確認します。

ステップ5—クライアントでのマウントポイントの作成

ホストサーバーが構成され、その共有を提供するようになったので、クライアントを準備します。

クライアントでリモート共有を利用できるようにするには、ホストディレクトリを空のクライアントディレクトリにマウントする必要があります。

注：マウントポイントにファイルとディレクトリがある場合、NFS共有をマウントするとすぐに、それらは非表示になります。 すでに存在するディレクトリにマウントする場合は、そのディレクトリが空であることを確認してください。

マウント用に2つのディレクトリを作成します。

  1. sudo mkdir -p /nfs/general

  2. sudo mkdir -p /nfs/home

ステップ6—クライアントへのディレクトリのマウント

リモート共有を配置する場所があり、ファイアウォールを開いたので、次のように、このガイドでは203.0.113.0であるホストサーバーをアドレス指定することで共有をマウントできます。

  1. sudo mount 203.0.113.0:/var/nfs/general /nfs/general

  2. sudo mount 203.0.113.0:/home /nfs/home

これらのコマンドは、ホストコンピューターからクライアントマシンに共有をマウントする必要があります。 いくつかの方法で、それらが正常にマウントされたことを再確認できます。 これは、プレーンなmountまたはfindmntコマンドで確認できますが、df -hを使用すると、nfs共有のディスク使用量がどのように異なるかを示す人間が読める形式の出力が得られます。

  1.   df -h



Output
Filesystem                Size  Used Avail Use% Mounted on
udev                      238M     0  238M   0% /dev
tmpfs                      49M  628K   49M   2% /run
/dev/vda1                  20G  1.2G   18G   7% /
tmpfs                     245M     0  245M   0% /dev/shm
tmpfs                     5.0M     0  5.0M   0% /run/lock
tmpfs                     245M     0  245M   0% /sys/fs/cgroup
tmpfs                      49M     0   49M   0% /run/user/0
203.0.113.0:/home      20G  1.2G   18G   7% /nfs/home
203.0.113.0:/var/nfs/general   20G  1.2G   18G   7% /nfs/general

マウントした両方の共有が下部に表示されます。 それらは同じファイルシステムからマウントされたため、同じディスク使用量を示します。 各マウントポイントで実際に使用されているスペースを確認するには、ディスク使用量コマンドduとマウントのパスを使用します。 -sフラグは、すべてのファイルの使用状況を表示するのではなく、使用状況の概要を提供します。 -hは、人間が読める形式の出力を出力します。

例えば：

  1. du -sh /nfs/home



Output
36K	/nfs/home

これは、ホームディレクトリ全体のコンテンツが使用可能なスペースの20Kのみを使用していることを示しています。

ステップ7—NFSアクセスのテスト

次に、それぞれに何かを書き込んで、共有へのアクセスをテストしてみましょう。

例1：汎用シェア

まず、/var/nfs/general共有にテストファイルを書き込みます。

  1. sudo touch /nfs/general/general.test

次に、その所有権を確認します。

  1. ls -l /nfs/general/general.test



Output
-rw-r--r-- 1 nobody nogroup 0 Aug  1 13:31 /nfs/general/general.test

NFSのデフォルトの動作を変更せずにこのボリュームをマウントし、sudoコマンドを使用してクライアントマシンのrootユーザーとしてファイルを作成したため、ファイルの所有権はデフォルトでnobody：nogroupになります。 クライアントスーパーユーザーは、このNFSマウントされた共有で、ファイルの所有者の変更やユーザーのグループ用の新しいディレクトリの作成など、一般的な管理アクションを実行できません。

例2：ホームディレクトリ共有

汎用共有のアクセス許可をホームディレクトリ共有と比較するには、同じ方法でファイルホームディレクトリを作成します。

  1. sudo touch /nfs/home/home.test

次に、ファイルの所有権を確認します。

  1. ls -l /nfs/home/home.test



Output
-rw-r--r-- 1 root root 0 Aug  1 13:32 /nfs/home/home.test

general.testファイルを作成したのとまったく同じ方法で、sudoコマンドを使用してルートとしてhome.testを作成しました。 ただし、この場合、このマウントでno_root_squashオプションを指定したときにデフォルトの動作を無効にしたため、rootが所有しています。 これにより、クライアントマシン上のrootユーザーがrootとして機能できるようになり、ユーザーアカウントの管理がはるかに便利になります。 同時に、これらのユーザーにホストへのルートアクセスを許可する必要がないことを意味します。

ステップ8—起動時にリモートNFSディレクトリをマウントする

クライアントの/etc/fstabファイルにリモートNFS共有を追加することで、起動時にリモートNFS共有を自動的にマウントできます。

テキストエディタでroot権限でこのファイルを開きます。

  1. sudo nano /etc/fstab

ファイルの最後に、各共有の行を追加します。 それらは次のようになります。

/ etc / fstab
. . .
203.0.113.0:/var/nfs/general    /nfs/general   nfs auto,nofail,noatime,nolock,intr,tcp,actimeo=1800 0 0
203.0.113.0:/home       /nfs/home      nfs auto,nofail,noatime,nolock,intr,tcp,actimeo=1800 0 0

注：ここで指定するオプションの詳細については、man nfsコマンドを使用したfstabでのNFSマウントについて説明しているマニュアルページを参照してください。

クライアントサーバーは起動時にリモートパーティションを自動的にマウントしますが、接続が確立されて共有が利用可能になるまでに少し時間がかかる場合があります。

ステップ9—NFSリモート共有のアンマウント

リモートディレクトリをシステムにマウントする必要がなくなった場合は、次のように、共有のディレクトリ構造から移動してアンマウントすることで、リモートディレクトリをアンマウントできます。

  1. cd ~

  2. sudo umount /nfs/home

  3. sudo umount /nfs/general

これにより、リモート共有が削除され、ローカルストレージのみがアクセス可能になります。

  1. df -h



Output

Filesystem      Size  Used Avail Use% Mounted on
/dev/vda         59G  1.3G   55G   3% /
none            4.0K     0  4.0K   0% /sys/fs/cgroup
udev            2.0G   12K  2.0G   1% /dev
tmpfs           396M  320K  396M   1% /run
none            5.0M     0  5.0M   0% /run/lock
none            2.0G     0  2.0G   0% /run/shm
none            100M     0  100M   0% /run/user

また、次回の再起動時に再マウントされないようにする場合は、/etc/fstabを編集し、行を削除するか、行の先頭に＃記号を付けてコメントアウトします。 autoオプションを削除して自動マウントを防ぐこともできます。これにより、手動でマウントできるようになります。

結論

このチュートリアルでは、NFSホストを作成し、NFSクライアントと共有する2つの異なるNFSマウントを作成することにより、いくつかの主要なNFS動作を示しました。 本番環境でNFSを実装する場合は、プロトコル自体が暗号化されていないことに注意することが重要です。 公的にアクセスできるように意図されたファイルを共有している場合、それは深刻な問題を引き起こしません。

ただし、プライベートデータにNFSを使用している場合は、そのデータをどのように保護するかを決定する必要があります。 SSHまたはVPN接続を介してNFSをルーティングして、より安全なエクスペリエンスを作成できる場合がありますが、これには多くの場合、パフォーマンスが大幅に低下します。 パフォーマンスが問題になる場合は、SSHFSを検討してください。 暗号化されていないNFSトラフィックよりもわずかに低速ですが、通常はトンネル化されたNFSよりもはるかに高速です。 NFS用のKerberos認証付き暗号化は、検討するもう1つのオプションです。