はじめに
この実験では、Red Hat Enterprise Linux (RHEL) システムで NFS クライアントアクセスを設定するための必須スキルを習得します。まず、基本的なプロセスを理解するために、mount コマンドを使用してネットワーク共有を手動でマウントすることから始めます。その後、システム再起動後も NFS 共有が自動的に利用できるように、/etc/fstab に永続的なマウントを設定し、静的なネットワークファイルシステム統合の基礎を理解します。
これらのコアコンセプトを基盤として、より動的で効率的な方法に進み、オートマウンターを設定します。これには、autofs サービスをインストールして有効にし、オンデマンドでのディレクトリマウント用の間接マップと、静的なマウントポイント用の直接マップを作成することが含まれます。最後に、直接および間接オートマウントが異なるユーザーに対して正しく機能することを確認し、堅牢な NFS クライアント構成を管理する能力を確固たるものにします。
mount コマンドを使用して NFS 共有を手動でマウントする
このステップでは、Network File System (NFS) プロトコルを使用してネットワーク共有ディレクトリに手動でアクセスする方法を学びます。NFS は、クライアントシステムがローカルストレージにアクセスする方法と同様の方法で、コンピューターネットワーク経由でファイルにアクセスできるようにします。この演習では、必要なコマンドを練習するために、ローカルマシン上で NFS サーバーとクライアントの両方をシミュレートします。
システム上では、/srv/nfs/shared_data ディレクトリをエクスポート（共有）するように NFS サーバーが事前に設定されています。あなたのタスクは、この共有ディレクトリをローカルフォルダにマウントし、アクセスを確認してからアンマウントすることです。
ステップ 1.1: ローカルマウントポイントの作成
共有 NFS ディレクトリにアクセスするには、ローカルディレクトリを「マウントポイント」として使用する必要があります。これは基本的にクライアントシステム上の空のフォルダであり、リモート共有の内容がマウントされるとここに表示されます。すべての操作は ~/project ディレクトリ内で行われます。
プロジェクトフォルダ内に nfs_mount という名前のディレクトリを作成します。
mkdir ~/project/nfs_mount
プロジェクトフォルダの内容をリストすることで、ディレクトリが作成されたことを確認できます。
ls -F ~/project
nfs_mount/
ステップ 1.2: NFS シェアのマウント
次に、mount コマンドを使用して、リモート NFS シェアを新しく作成したマウントポイントにアタッチします。マウントはシステムレベルの操作であるため、このコマンドには sudo 権限が必要です。
基本的な構文は mount -t nfs <server>:<remote_directory> <local_mount_point> です。
-t nfs: ファイルシステムタイプが NFS であることを指定します。localhost:/srv/nfs/shared_data: ソースであり、サーバーとそのエクスポートパスです。~/project/nfs_mount: デスティネーションであり、ローカルマウントポイントです。
共有をマウントするには、次のコマンドを実行します。
sudo mount -t nfs localhost:/srv/nfs/shared_data ~/project/nfs_mount
このコマンドは、成功した場合、何も出力しません。
ステップ 1.3: マウントの確認と共有へのアクセス
mount コマンドを実行した後、共有が正しくマウントされていることを確認する必要があります。これにはいくつかの方法があります。
まず、mount コマンドを grep にパイプして、NFS マウントをフィルタリングします。
mount | grep nfs
localhost:/srv/nfs/shared_data on /home/labex/project/nfs_mount type nfs4 (rw,relatime,vers=4.2,rsize=...,wsize=...,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=...,local_lock=none,addr=...)
次に、マウントポイントの内容を確認します。これにより、リモートの /srv/nfs/shared_data ディレクトリからのファイルが表示されるはずです。
ls -l ~/project/nfs_mount
total 4
-rw-r--r--. 1 root root 32 Nov 10 14:30 welcome.txt
これで、このディレクトリをローカルフォルダのように操作できます。この実験環境では、NFS サーバーの設定で no_root_squash が使用されているため、ファイルは root によって所有されていることに注意してください。本番環境では、NFS サーバーの設定によって nobody が所有者として表示される場合があります。マウントされた共有内に新しいファイルを作成してみましょう。NFS シェアは root によって所有されている可能性があるため、tee コマンドで sudo を使用してファイルを書き込む必要があります。
echo "My test file" | sudo tee ~/project/nfs_mount/my_file.txt > /dev/null
新しいファイルが元のファイルと一緒に存在することを確認します。
ls -l ~/project/nfs_mount
total 8
-rw-r--r--. 1 root root 13 Nov 10 14:35 my_file.txt
-rw-r--r--. 1 root root 32 Nov 10 14:30 welcome.txt
ステップ 1.4: NFS シェアのアンマウント
ネットワーク共有の使用が終了したら、umount コマンドを使用して適切にアンマウントすることが重要です。これにより、すべてのデータが同期され、接続が正しく閉じられます。マウントポイントを指定するだけで十分です。
sudo umount ~/project/nfs_mount
共有がアンマウントされたことを確認するには、~/project/nfs_mount ディレクトリの内容をリストします。これにより、再び空になっているはずです。
ls -l ~/project/nfs_mount
total 0
/etc/fstab で永続的な NFS マウントを設定する
前のステップでは、mount コマンドを使用して NFS シェアを手動でマウントする方法を学びました。しかし、このようなマウントは一時的なものであり、システム再起動後には維持されません。マウントを永続化するには、/etc/fstab ファイル（"file systems table" の略）にエントリを追加する必要があります。このファイルには、システム起動時に自動的にマウントされるファイルシステムとデバイスのリストが含まれています。
このステップでは、/etc/fstab にエントリを追加して、同じ NFS シェアを永続的にマウントするように設定します。
ステップ 2.1: 環境の準備
まず、前のステップのマウントポイントである ~/project/nfs_mount が存在し、空であることを確認してください。前のステップから直接続行している場合は、すでに存在しているはずです。
ディレクトリが存在しない場合は、今すぐ作成してください。
mkdir -p ~/project/nfs_mount
また、このディレクトリに現在何もマウントされていないことを確認してください。umount コマンドを実行できます。マウントされていない場合はエラーが表示されますが、それは問題ありません。
sudo umount ~/project/nfs_mount
ステップ 2.2: /etc/fstab ファイルの編集
次に、/etc/fstab ファイルに新しい行を追加して、永続的な NFS マウントを定義します。このシステム設定ファイルを編集するには sudo を使用する必要があります。ここでは nano エディタを使用します。
次のコマンドでファイルを開きます。
sudo nano /etc/fstab
ファイルの末尾に移動し、次の行を追加します。このファイルの構文は非常に重要です。誤りがあるとシステム起動に問題が発生する可能性があります。
localhost:/srv/nfs/shared_data /home/labex/project/nfs_mount nfs defaults,_netdev 0 0
この行の内訳を見てみましょう。
localhost:/srv/nfs/shared_data: マウントするデバイスです。NFS サーバー (localhost) とエクスポートされたディレクトリ (/srv/nfs/shared_data) を指定します。/home/labex/project/nfs_mount: シェアにアクセス可能になるローカルマウントポイントです。nfs: ファイルシステムタイプを指定します。defaults,_netdev: マウントオプションです。defaultsは標準的なオプションのセット（読み書きのためのrwなど）を含みます。_netdevはネットワークファイルシステムにとって重要です。これは、システムがこの共有のマウントを試みる前にネットワークがアクティブになるまで待つように指示します。0:dumpバックアップユーティリティで使用されるdumpフィールドです。値0は無効にします。0: 起動時のファイルシステムチェックの順序を決定するためにfsckユーティリティによって使用されるpassフィールドです。値0はファイルシステムがチェックされないことを意味します。
行を追加したら、Ctrl+X、次に Y、そして Enter を押してファイルを保存し、nano を終了します。
ステップ 2.3: /etc/fstab エントリのテスト
新しい /etc/fstab エントリをテストするために再起動する必要はありません。mount コマンドは /etc/fstab を読み取るのに十分賢いです。マウントポイントのみを指定した場合、mount は /etc/fstab で対応するエントリを検索し、そこで見つかった情報を使用します。
マウントポイントのみを使用して共有をマウントします。
sudo mount ~/project/nfs_mount
コマンドがエラーなく完了した場合、/etc/fstab エントリは正しいです。
ステップ 2.4: マウントの検証
mount コマンドの出力を確認し、ディレクトリの内容をリストすることで、共有がマウントされていることを検証します。
mount | grep nfs_mount
localhost:/srv/nfs/shared_data on /home/labex/project/nfs_mount type nfs4 (rw,relatime,vers=4.2,rsize=...,wsize=...,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=...,local_lock=none,addr=...,_netdev)
次に、内容を確認します。共有からのファイルが表示されるはずです。
ls -l ~/project/nfs_mount
total 4
-rw-r--r--. 1 root root 32 Nov 10 14:30 welcome.txt
このマウントは現在永続的であり、再起動後も自動的に再確立されます。
ステップ 2.5: 環境のクリーンアップ
後続の実験との競合を避けるために、ここで変更を元に戻す必要があります。まず、共有をアンマウントし、次に /etc/fstab から追加した行を削除します。
ディレクトリをアンマウントします。
sudo umount ~/project/nfs_mount
エントリを削除するために、再度 /etc/fstab を開きます。
sudo nano /etc/fstab
矢印キーを使用して追加した行 (localhost:/srv/nfs/shared_data ...) に移動し、Ctrl+K を押して行全体を削除します。その後、Ctrl+X、Y、そして Enter を押して保存し、終了します。
これにより、実験の次の部分のためにシステムはクリーンな状態になります。
autofs をインストールして有効化し、オートマウンターを設定する
これまでのステップでは、手動マウントと永続マウントについて説明しました。/etc/fstab は永続マウントに非常に便利ですが、欠点があります。それは、起動時にすべてのものをマウントしようとすることです。ネットワーク共有が利用できない場合、起動プロセスが遅くなったり、停止したりする可能性があります。autofs サービスによって提供されるオートマウンターは、ネットワークファイルシステムが最初にアクセスされたときにのみ、オンデマンドでマウントすることでこの問題を解決します。
autofs サービスは、「マップ」と呼ばれる一連の設定ファイルを使用して、どのリモート共有をどこにマウントするかを決定します。このステップでは、必要なパッケージをインストールし、そのサービスを開始することによって、オートマウンターを使用するようにシステムを準備します。
ステップ 3.1: autofs パッケージのインストール
autofs 機能は、デフォルトの RHEL インストールには含まれていません。dnf パッケージマネージャーを使用してインストールする必要があります。これには sudo 権限が必要です。
次のコマンドを実行して autofs パッケージをインストールします。-y フラグは、確認プロンプトに対して自動的に「yes」と答えるため、この実験では便利です。
sudo dnf install -y autofs
コマンドは autofs パッケージと必要な依存関係をダウンロードしてインストールします。以下のような出力が表示されます。
Last metadata expiration check: ...
Dependencies resolved.
================================================================================
Package Architecture Version Repository Size
================================================================================
Installing:
autofs x86_64 1:5.1.7-50.el9 ... ...
...
Transaction Summary
================================================================================
Install 1 Package
Total download size: ...
Installed size: ...
...
Complete!
ステップ 3.2: autofs サービスの開始
標準的な RHEL システムでは、systemctl を使用してサービスを開始および有効化します。しかし、この実験はコンテナ化された環境で実行されており、systemctl は利用できません。代わりに、automount コマンドを使用して autofs デーモンを直接開始します。
このコマンドは、バックグラウンドで実行され、マップで設定されたディレクトリへのアクセス試行を監視するオートマウンターデーモンを開始します。
サービスを開始するには、次のコマンドを実行します。
sudo automount
成功した場合、このコマンドは何も出力しません。単にデーモンプロセスを開始します。
ステップ 3.3: サービスの実行状況の確認
systemctl status autofs を使用してサービスを確認できないため、ps コマンドを使用して automount プロセスが実行されていることを確認できます。ps aux コマンドは実行中のすべてのプロセスをリストし、その出力を | でパイプして grep に渡すことで automount プロセスをフィルタリングできます。
ps aux | grep automount
automount プロセス自体の行が少なくとも 1 つ表示されるはずです。grep automount を示す 2 行目は、実行した grep コマンド自体であり、無視できます。
root ... 0.0 0.0 ... ? Ssl 15:30 0:00 /usr/sbin/automount
labex ... 0.0 0.0 ... pts/0 S+ 15:31 0:00 grep --color=auto automount
/usr/sbin/automount プロセスが表示されることで、サービスが実行されており、オンデマンドマウントに対応する準備ができていることが確認できます。次のステップでは、autofs に何を行うかを指示するマップを設定します。
動的ディレクトリ用の間接オートマウントマップを作成する
このステップでは、間接マップを使用して最初のオートマウントルールを設定します。間接マップは、最も一般的なオートマウント構成タイプです。これは、単一のベースディレクトリ（/home や /net など）をマップファイルに関連付けることで機能します。ユーザーがそのベースディレクトリ内のサブディレクトリにアクセスしようとすると、autofs はマップファイルでサブディレクトリ名を検索し、オンデマンドで対応するリモート共有をマウントします。
これは、すべてのホームディレクトリや共有プロジェクトフォルダを一度にマウントすることなく、ユーザーのホームディレクトリやプロジェクトフォルダのコレクションをマウントするのに非常に役立ちます。ここでは、/project_shares という新しいベースディレクトリの下にあるプロジェクトディレクトリを動的にマウントするように間接マップを設定します。
ステップ 4.1: NFS サーバーのエクスポートの作成
まず、共有したいディレクトリをシミュレートされた NFS サーバー上で準備しましょう。/srv/nfs/ 内に design と testing という 2 つのプロジェクトディレクトリを作成します。
ディレクトリを作成し、それぞれにサンプルファイルを配置します。
sudo mkdir -p /srv/nfs/{design,testing}
sudo sh -c 'echo "Design documents" > /srv/nfs/design/README'
sudo sh -c 'echo "Testing scripts" > /srv/nfs/testing/README'
次に、NFS サーバーにこれらのディレクトリをエクスポートするように指示する必要があります。これは /etc/exports ファイルにエントリを追加することで行います。
nano でファイルを開きます。
sudo nano /etc/exports
ファイルに次の行を追加します。これらの行は、NFS サーバーに design および testing ディレクトリを、すべてのクライアント（*）と読み書き（rw）権限で共有するように指示します。
/srv/nfs/design *(rw,sync,no_root_squash)
/srv/nfs/testing *(rw,sync,no_root_squash)
ファイルを保存して終了します（Ctrl+X、Y、Enter）。
最後に、すべてのディレクトリを再エクスポートして、NFS サーバーに変更を適用します。
sudo exportfs -ra
ステップ 4.2: マスターマップエントリの作成
autofs の構成は、マスターマップファイル /etc/auto.master から始まります。ベストプラクティスは、このファイルを直接編集するのではなく、/etc/auto.master.d/ ディレクトリに新しい構成ファイルを追加することです。
プロジェクト共有用の新しいマスターマップファイルを作成します。
sudo nano /etc/auto.master.d/shares.autofs
このファイルに次の 1 行を追加します。
/project_shares /etc/auto.shares
この行は autofs に「/project_shares ディレクトリの下へのアクセスについては、指示のために /etc/auto.shares にあるマップファイルを参照してください」と指示します。
エディタを保存して終了します。
ステップ 4.3: 間接マップファイルの作成
次に、マスターマップで参照した間接マップファイル /etc/auto.shares を作成します。
sudo nano /etc/auto.shares
このファイルに次の行を追加します。
design -fstype=nfs,rw,sync localhost:/srv/nfs/design
testing -fstype=nfs,rw,sync localhost:/srv/nfs/testing
1 行の内訳を見てみましょう。
design: これは「キー」です。/project_sharesの下のサブディレクトリ名に対応します。ユーザーが/project_shares/designにアクセスすると、この行がトリガーされます。-fstype=nfs,rw,sync: これらはマウントオプションで、ファイルシステムタイプ、読み書きアクセス、および同期書き込みを指定します。localhost:/srv/nfs/design: これはマウントされるリモート NFS 共有の場所です。
エディタを保存して終了します。
ステップ 4.4: autofs のリロードとマウントのテスト
autofs サービスが新しいマップファイルを認識するようにするには、その構成をリロードする必要があります。systemctl が利用できないため、automount プロセスに HUP (hangup) シグナルを送信します。これにより、構成が再読み込みされます。
sudo killall -HUP automount
それではテストしてみましょう。まず、ベースディレクトリ /project_shares の内容をリストしてみてください。何もマウントされていないため、空に見えます。
ls -l /project_shares
total 0
次に、サブディレクトリのいずれかにアクセスしてみてください。これが autofs にマウントを実行させるトリガーとなります。
ls -l /project_shares/design
total 4
-rw-r--r--. 1 root root 17 Nov 10 16:10 README
成功しました！design シェアは自動的にマウントされました。これで、ベースディレクトリを再度リストすると、design ディレクトリが表示されます。これはアクティブなマウントポイントであるためです。
ls -l /project_shares
total 0
dr-xr-xr-x. 2 root root 0 Nov 10 16:12 design
testing ディレクトリについても同様に行い、正常に動作することを確認してください。
ls -l /project_shares/testing
total 4
-rw-r--r--. 1 root root 16 Nov 10 16:10 README
間接オートマウントマップを正常に構成し、テストしました。
静的マウントポイント用の直接オートマウントマップを作成する
このステップでは、2 番目のオートマウント構成タイプである直接マップについて学びます。間接マップは共通のベースディレクトリの下に複数のマウントをグループ化しますが、直接マップはファイルシステム内の任意の場所に特定の個別のマウントポイントを定義します。直接マップのエントリはそれぞれ、単一の絶対パスに対応します。
直接マップは、共有ツールディレクトリを /usr/local/tools にマウントするなど、少数の共有を固定された既知の場所にマウントする場合に便利です。ここでは、共有 common_data ディレクトリを /mnt/common にマウントするように直接マップを設定します。
ステップ 5.1: NFS サーバーのエクスポートの準備
これまでと同様に、まず共有したいディレクトリをシミュレートされた NFS サーバー上で設定する必要があります。common_data という名前のディレクトリを作成します。
ディレクトリを作成し、その中にサンプルファイルを配置します。
sudo mkdir -p /srv/nfs/common_data
sudo sh -c 'echo "Common shared data" > /srv/nfs/common_data/info.txt'
次に、このディレクトリを NFS 経由で利用可能にするために、/etc/exports にエントリを追加します。
sudo nano /etc/exports
ファイルに次の新しい行を追加します。これにより、/srv/nfs/common_data ディレクトリが共有されます。
/srv/nfs/common_data *(rw,sync,no_root_squash)
ファイルを保存して終了します（Ctrl+X、Y、Enter）。
すべてのディレクトリを再エクスポートして、NFS サーバーに変更を適用します。
sudo exportfs -ra
ステップ 5.2: 直接マップ用のマスターマップエントリの作成
直接マップを使用するには、まずマスターマップ構成から参照する必要があります。特別なマウントポイント /- は、関連付けられたマップファイルが直接マップであることを示すために使用されます。
直接マウント用の新しいマスターマップファイルを作成します。
sudo nano /etc/auto.master.d/direct.autofs
このファイルに次の 1 行を追加します。
/- /etc/auto.direct
この行は autofs に「直接マウントのリストについては、ファイル /etc/auto.direct を参照してください。マウントポイントは、そのファイル内で定義された絶対パスです」と指示します。
エディタを保存して終了します。
ステップ 5.3: 直接マップファイルの作成
次に、参照した直接マップファイル /etc/auto.direct を作成します。
sudo nano /etc/auto.direct
このファイルに次の行を追加します。フォーマットは間接マップとはわずかに異なります。
/mnt/common -fstype=nfs,rw,sync localhost:/srv/nfs/common_data
この行を分析しましょう。
/mnt/common: これは「キー」ですが、直接マップの場合、キーはマウントポイントの完全な絶対パスです。-fstype=nfs,rw,sync: これらはマウントオプションで、以前と同様です。localhost:/srv/nfs/common_data: これはリモート NFS 共有の場所です。
エディタを保存して終了します。
ステップ 5.4: autofs のリロードと直接マウントのテスト
間接マップの場合と同様に、新しい直接マップを認識させるために autofs の構成をリロードする必要があります。
sudo killall -HUP automount
それでは、直接マウントをテストしてみましょう。間接マップとは異なり、マウントポイント /mnt/common は、アクセスを試みるまでファイルシステムに存在しません。
ディレクトリ /mnt/common にアクセスしてみてください。これにより、autofs がマウントポイントを作成し、共有をマウントするトリガーが実行されます。
ls -l /mnt/common
total 4
-rw-r--r--. 1 root root 19 Nov 10 17:00 info.txt
成功しました！直接マウントはオンデマンドで作成されました。mount コマンドでも確認できます。
mount | grep common
localhost:/srv/nfs/common_data on /mnt/common type nfs4 (rw,relatime,vers=4.2,rsize=...,wsize=...,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=...,local_lock=none,addr=...)
これで、動的なサブディレクトリ用の間接マップと、静的な絶対マウントポイント用の直接マップの両方を正常に構成しました。
異なるユーザーとして直接および間接オートマウントを確認する
この最後のステップでは、マルチユーザー環境でのオートマウンターの動作を検証します。オートマウントは共有を利用可能にしますが、実際にファイルの読み書きを制御するのは NFS サーバー上の基盤となるファイルシステム権限です。ここでは、いくつかのテストユーザーを作成し、それぞれの NFS 共有の所有権を割り当て、その後、間接マップと直接マップの両方へのアクセスをテストします。
この演習は、異なるチーム（例：設計とテスト）がそれぞれの共有ディレクトリの所有権を持ち、他のユーザーは読み取りアクセスが可能だが書き込みアクセスは所有者に制限されている、という実際のシナリオを示しています。
ステップ 6.1: テストユーザーの作成と権限の設定
まず、designer1 と tester1 という 2 つの新しいユーザーを作成する必要があります。また、アカウントを切り替えられるように、簡単なパスワードを設定します。
useradd コマンドを使用してユーザーを作成します。-m フラグは、ユーザーのホームディレクトリを作成します。
sudo useradd -m designer1
sudo useradd -m tester1
次に、各ユーザーのパスワードを設定します。この実験（lab）では簡単にするため、両方にパスワード labex.io を使用します（長さ、大文字・小文字の区別、数字、特殊文字を含む複雑さの要件を満たしています）。
sudo passwd designer1
## 新しい UNIX パスワードを入力してください: labex.io
## 新しい UNIX パスワードを再入力してください: labex.io
## passwd: パスワードが正常に更新されました
sudo passwd tester1
## 新しい UNIX パスワードを入力してください: labex.io
## 新しい UNIX パスワードを再入力してください: labex.io
## passwd: パスワードが正常に更新されました
次に、「サーバー」側の共有ディレクトリ（/srv/nfs/*）の所有権を変更して、これらの新しいユーザーにアクセス権を付与します。
sudo chown -R designer1:designer1 /srv/nfs/design
sudo chown -R tester1:tester1 /srv/nfs/testing
/srv/nfs/common_data ディレクトリは root が所有したままにし、一般ユーザーは読み取り専用にします。
ステップ 6.2: designer1 ユーザーとしてのアクセスをテストする
su (substitute user) コマンドを使用して、designer1 ユーザーアカウントに切り替えます。- は、ユーザーの完全なログイン環境を取得することを保証します。
su - designer1
## パスワード: labex.io
コマンドプロンプトが [designer1@host ~]$ に変わります。
まず、間接マップ経由で design 共有へのアクセスをテストします。これは成功するはずです。
ls -l /project_shares/design
total 4
-rw-r--r--. 1 designer1 designer1 17 Jun 16 16:12 README
次に、このディレクトリにファイルを書き込もうとします。これも成功するはずです。
echo "My design file" > /project_shares/design/design_file.txt
ls -l /project_shares/design
total 8
-rw-r--r--. 1 designer1 designer1 15 Jun 16 16:18 design_file.txt
-rw-r--r--. 1 designer1 designer1 17 Jun 16 16:12 README
次に、testing 共有へのアクセスを試みます。内容は表示できますが、tester1 が所有しているため書き込むことはできません。
ls -l /project_shares/testing
total 4
-rw-r--r--. 1 tester1 tester1 16 Jun 16 16:12 README
最後に、直接マップされた共有をテストします。designer1 はそれを読み取ることはできますが、書き込むことはできません。
cat /mnt/common/info.txt
Common shared data
echo "test" > /mnt/common/new_file.txt
-bash: /mnt/common/new_file.txt: アクセスが拒否されました
designer1 のセッションを終了して、labex ユーザーに戻ります。
exit
ステップ 6.3: tester1 ユーザーとしてのアクセスをテストする
次に、tester1 ユーザーとして同様のテストを実行します。
su - tester1
## パスワード: labex.io
design 共有にアクセスします。designer1 が作成したファイルを含む内容を表示できますが、書き込むことはできません。
ls -l /project_shares/design
total 8
-rw-r--r--. 1 designer1 designer1 15 Jun 16 16:18 design_file.txt
-rw-r--r--. 1 designer1 designer1 17 Jun 16 16:12 README
次に、testing 共有にアクセスして書き込みます。このディレクトリは tester1 が所有しているため、これは成功するはずです。
ls -l /project_shares/testing
total 4
-rw-r--r--. 1 tester1 tester1 16 Jun 16 16:12 README
echo "My test script" > /project_shares/testing/test_script.sh
ls -l /project_shares/testing
total 8
-rw-r--r--. 1 tester1 tester1 16 Jun 16 16:12 README
-rw-r--r--. 1 tester1 tester1 15 Jun 16 16:19 test_script.sh
tester1 のセッションを終了します。
exit
ステップ 6.4: 環境のクリーンアップ
実験（lab）を終了し、システムを元の状態に戻すために、作成したテストユーザーを削除します。userdel -r コマンドは、ユーザーとそのホームディレクトリを削除します。
sudo userdel -r designer1
sudo userdel -r tester1
これで、autofs を使用した NFS 管理に関する実験は終了です。
まとめ
この実験（lab）では、RHEL システムでの NFS クライアントアクセスを構成する方法を学びます。まず、ローカルマウントポイントを作成し、次に mount コマンドを使用して NFS 共有に接続することで、手動マウントを実行します。mount コマンドで手動接続を確立した後、/etc/fstab ファイルにエントリを作成して永続的なマウントを構成し、起動時に共有が自動的にマウントされるようにします。
さらに、この実験では autofs サービスを使用したオンデマンドマウントの構成についても説明します。これには、サービスのインストールと有効化、そして 2 つの異なる方法を使用した共有のマウント方法の定義が含まれます。動的にディレクトリをマウントするための間接マップと、静的で事前に定義された場所に共有をマウントするための直接マップの作成です。プロセスは、直接および間接オートマウントの両方が異なるユーザーに対して正しく機能することを検証して完了します。
