前書き
NFS、またはネットワークファイルシステムは、サーバー上のリモートディレクトリをマウントできる分散ファイルシステムプロトコルです。 これにより、異なる場所のストレージスペースを管理し、複数のクライアントからそのスペースに書き込むことができます。 NFSは、ネットワーク経由でリモートシステムにアクセスするための比較的迅速で簡単な方法を提供し、共有リソースに定期的にアクセスする状況で適切に機能します。
このガイドでは、NFSマウントの構成方法について説明します。
前提条件
このチュートリアルでは、2つのサーバーを使用します。1つはファイルシステムの一部をもう1つと共有します。
従うには、次のものが必要です。
-
Two Ubuntu 16.04 servers, each with a non-root user with
sudo
privilegesおよびプライベートネットワークが有効になっています。-
これらの権限を持つユーザーの設定については、Initial Server Setup with Ubuntu 16.04ガイドに従ってください。
-
プライベートネットワークの設定については、How To Set Up And Use DigitalOcean Private Networkingを参照してください。
-
チュートリアル全体を通して、ディレクトリを共有するサーバーをhostと呼び、これらのディレクトリをマウントするサーバーをclientと呼びます。 それらをまっすぐに保つために、ホストとクライアントの値の代用として次のIPアドレスを使用します。
-
Host:203.0.113.0
-
Client:203.0.113.256
これらの値を独自のホストおよびクライアントIPアドレスに置き換える必要があります。
[[ステップ-1 -—-コンポーネントのダウンロードとインストール]] ==ステップ1—コンポーネントのダウンロードとインストール
まず、各サーバーに必要なコンポーネントをインストールします。
ホスト上
ホストサーバーにnfs-kernel-server
パッケージをインストールします。これにより、ディレクトリを共有できるようになります。 これは、このセッションでapt
を使用して実行する最初の操作であるため、インストール前にローカルパッケージインデックスを更新します。
sudo apt-get update
sudo apt-get install nfs-kernel-server
これらのパッケージがインストールされたら、クライアントサーバーに切り替えます。
クライアントで
クライアントサーバーに、nfs-common
というパッケージをインストールする必要があります。これは、不要なサーバーコンポーネントを含めずにNFS機能を提供します。 繰り返しますが、インストール前にローカルパッケージインデックスを更新して、最新の情報があることを確認します。
sudo apt-get update
sudo apt-get install nfs-common
両方のサーバーに必要なパッケージがあるので、それらの構成を開始できます。
[[step-2 -—- creating-the-share-directories-on-the-host]] ==ステップ2—ホスト上に共有ディレクトリを作成する
スーパーユーザーアクセスに関してNFSマウントを構成する2つの重要な方法を説明するために、構成設定が異なる2つの個別のディレクトリを共有します。
スーパーユーザーは、システムのどこでも何でもできます。 ただし、NFSマウントされたディレクトリは、それらがマウントされているシステムの一部ではないため、デフォルトでは、NFSサーバーはスーパーユーザー特権を必要とする操作の実行を拒否します。 このデフォルトの制限は、クライアント上のスーパーユーザーがファイルをrootとして記述したり、所有権を再割り当てしたり、NFSマウントで他のスーパーユーザータスクを実行したりできないことを意味します。
ただし、マウントされたファイルシステムでこれらの操作を実行できる必要があるが、ホストでのスーパーユーザーアクセスが不要な信頼できるユーザーがクライアントシステムに存在する場合があります。 NFSサーバーは、これを許可するように構成できますが、ユーザーcouldがホストシステム全体へのルートアクセスを取得するため、リスクの要素が発生します。
例1:汎用マウントのエクスポート
最初の例では、デフォルトのNFS動作を使用する汎用NFSマウントを作成し、クライアントマシンでroot権限を持つユーザーがそれらのクライアントスーパーユーザー権限を使用してホストと対話することを困難にします。 このようなものを使用して、コンテンツ管理システムを使用してアップロードされたファイルを保存したり、ユーザーがプロジェクトファイルを簡単に共有できるスペースを作成したりできます。
まず、nfs
という共有ディレクトリを作成します。
sudo mkdir /var/nfs/general -p
sudo
を使用して作成しているため、ディレクトリはホスト上のrootによって所有されています。
ls -la /var/nfs/general
Output4 drwxr-xr-x 2 root root 4096 Jul 25 15:26 .
NFSは、セキュリティ対策として、クライアントでのroot
操作をnobody:nogroup
資格情報に変換します。 したがって、これらの資格情報と一致するようにディレクトリの所有権を変更する必要があります。
sudo chown nobody:nogroup /var/nfs/general
これで、このディレクトリをエクスポートする準備ができました。
例2:ホームディレクトリのエクスポート
2番目の例の目的は、ホストに保存されているユーザーのホームディレクトリをクライアントサーバーで使用できるようにし、それらのクライアントサーバーの信頼できる管理者がユーザーの管理に必要なアクセスを許可することです。
これを行うには、/home
ディレクトリをエクスポートします。 既に存在するため、作成する必要はありません。 権限も変更しません。 didの場合、ホストマシンにホームディレクトリがある人にはあらゆる種類の問題が発生します。
[[step-3 -—- configuring-the-nfs-exports-on-the-host-server]] ==ステップ3—ホストサーバーでのNFSエクスポートの構成
次に、これらのリソースの共有を設定するために、NFS構成ファイルに飛び込みます。
root権限でテキストエディタで/etc/exports
ファイルを開きます。
sudo nano /etc/exports
ファイルには、各構成行の一般的な構造を示すコメントが含まれています。 構文は基本的に次のとおりです。
/etc/exports
directory_to_share client(share_option1,...,share_optionN)
共有する予定のディレクトリごとに行を作成する必要があります。 サンプルクライアントの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ユーザーからの要求をサーバー上の非特権ユーザーにリモートで変換します。 これは、クライアントのルートアカウントがホストのファイルシステムをルートとして使用するのを防ぐセキュリティ機能として意図されていました。
no_root_squash
は、特定の共有に対してこの動作を無効にします。
変更が完了したら、ファイルを保存して閉じます。 次に、構成したクライアントが共有を使用できるようにするには、次のコマンドを使用してNFSサーバーを再起動します。
sudo systemctl restart nfs-kernel-server
ただし、新しい共有を実際に使用する前に、ファイアウォールルールによって共有へのトラフィックが許可されていることを確認する必要があります
[[ステップ-4 -—-ホスト上のファイアウォールの調整]] ==ステップ4—ホスト上のファイアウォールの調整
まず、ファイアウォールのステータスをチェックして、有効になっているかどうかを確認し、有効になっている場合は、現在許可されているものを確認します。
sudo ufw status
OutputStatus: 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アドレスを必ず置き換えてください。
sudo ufw allow from 203.0.113.256 to any port nfs
次のように入力して、変更を確認できます。
sudo ufw status
出力にポート2049から許可されたトラフィックが表示されるはずです。
OutputStatus: active
To Action From
-- ------ ----
OpenSSH ALLOW Anywhere
2049 ALLOW 203.0.113.256
OpenSSH (v6) ALLOW Anywhere (v6)
これにより、UFWがクライアントマシンからのポート2049でのNFSトラフィックのみを許可することが確認されます。
[[step-5 --- creating-the-mount-points-on-the-client]] ==ステップ5—クライアントでのマウントポイントの作成
ホストサーバーが構成され、その共有を提供しているので、クライアントを準備します。
クライアントでリモート共有を使用できるようにするには、空のクライアントディレクトリにホストディレクトリをマウントする必要があります。
[.note]#Note:マウントポイントにファイルとディレクトリがある場合、NFS共有をマウントするとすぐに、それらは非表示になります。 すでに存在するディレクトリにマウントする場合は、そのディレクトリが空であることを確認してください。
#
マウント用に2つのディレクトリを作成します。
sudo mkdir -p /nfs/general
sudo mkdir -p /nfs/home
[[step-6 --- mounting-the-directories-on-the-client]] ==ステップ6—ディレクトリをクライアントにマウントする
リモート共有を配置する場所があり、ファイアウォールを開いたので、次のように、このガイドでは203.0.113.0
であるホストサーバーをアドレス指定することで共有をマウントできます。
sudo mount 203.0.113.0:/var/nfs/general /nfs/general
sudo mount 203.0.113.0:/home /nfs/home
これらのコマンドは、共有をホストコンピューターからクライアントマシンにマウントする必要があります。 いくつかの方法で正常にマウントされたことを再確認できます。 これはプレーンなmount
またはfindmnt
コマンドで確認できますが、df -h
を使用すると、nfs共有のディスク使用量がどのように異なるかを示す人間が読める形式の出力が得られます。
df -h
OutputFilesystem 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
は、人間が読める形式の出力を出力します。
例えば:
du -sh /nfs/home
Output36K /nfs/home
これは、ホームディレクトリ全体のコンテンツが使用可能なスペースのうち20Kだけを使用していることを示しています。
[[step-7 -—- testing-nfs-access]] ==ステップ7—NFSアクセスのテスト
次に、各共有に何かを書き込んで共有へのアクセスをテストしましょう。
例1:汎用共有
まず、テストファイルを/var/nfs/general
共有に書き込みます。
sudo touch /nfs/general/general.test
次に、所有権を確認します。
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:ホームディレクトリ共有
汎用共有のアクセス許可をホームディレクトリ共有と比較するには、同じ方法でファイルホームディレクトリを作成します。
sudo touch /nfs/home/home.test
次に、ファイルの所有権を確認します。
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が所有しています。 これにより、クライアントマシン上のルートユーザーがルートとして機能し、ユーザーアカウントの管理がより便利になります。 同時に、これらのユーザーにホストのルートアクセスを許可する必要がないことを意味します。
[[step-8 --- mounting-the-remote-nfs-directories-at-boot]] ==ステップ8—ブート時にリモートNFSディレクトリをマウントする
リモートNFS共有は、クライアントの/etc/fstab
ファイルに追加することで、起動時に自動的にマウントできます。
テキストエディタでルート権限でこのファイルを開きます。
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
[.note]#Note:ここで指定するオプションの詳細については、man nfs
コマンドを使用したfstab
でのNFSマウントについて説明しているマニュアルページを参照してください。
#
クライアントサーバーは、ブート時にリモートパーティションを自動的にマウントしますが、接続が確立されて共有が利用可能になるまでに少し時間がかかる場合があります。
[[step-9 -—- unmounting-an-nfs-remote-share]] ==ステップ9—NFSリモート共有のアンマウント
システムにリモートディレクトリをマウントする必要がなくなった場合は、次のように共有のディレクトリ構造から移動してアンマウントすることにより、リモートディレクトリをアンマウントできます。
cd ~
sudo umount /nfs/home
sudo umount /nfs/general
これにより、リモート共有が削除され、ローカルストレージのみがアクセス可能になります。
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を使用している場合は、そのデータを保護する方法を決定する必要があります。 NFSをSSHまたはVPN接続経由でルーティングして、より安全なエクスペリエンスを作成できる場合がありますが、多くの場合、パフォーマンスが大幅に低下します。 パフォーマンスが問題になる場合は、SSHFSを検討してください。 暗号化されていないNFSトラフィックよりも若干遅くなりますが、通常、トンネル化されたNFSよりもはるかに高速です。 NFSのKerberos認証暗号化は、検討するもう1つのオプションです。