はじめに
この実験では、Red Hat Enterprise Linux (RHEL) システムでNFSクライアントアクセスを設定するための重要なスキルを学びます。まず、mount コマンドを使用してネットワーク共有を手動でマウントし、基本的なプロセスを理解します。続いて、/etc/fstab に永続的なマウント設定を追加し、システム再起動後もNFS共有が自動的に利用可能になるように設定することで、静的なネットワークファイルシステム統合の基礎を固めます。
これらの核となる概念を基に、より動的で効率的な手法であるオートマウンターの設定へと進みます。これには 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 -o vers=3 <server>:<remote_directory> <local_mount_point> です。
-t nfs -o vers=3: ファイルシステムタイプがNFSであることを指定し、この実験環境で動作するプロトコルであるNFSv3を強制します。localhost:/srv/nfs/shared_data: ソース（サーバーとエクスポートされているパス）。~/project/nfs_mount: 宛先（ローカルのマウントポイント）。
以下のコマンドを実行して共有をマウントします。
sudo mount -t nfs -o vers=3 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 nfs (rw,relatime,vers=3,rsize=...,wsize=...,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,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,vers=3 0 0
この行の内容を解説します。
localhost:/srv/nfs/shared_data: マウントするデバイスです。NFSサーバー (localhost) とエクスポートされたディレクトリ (/srv/nfs/shared_data) を指定します。/home/labex/project/nfs_mount: 共有にアクセスするためのローカルマウントポイントです。nfs: ファイルシステムタイプを指定します。defaults,_netdev,vers=3: マウントオプションです。defaultsには標準的なオプション（読み書き用のrwなど）が含まれます。_netdevはネットワークファイルシステムにとって重要で、この共有をマウントしようとする前にネットワークがアクティブになるまで待機するようシステムに指示します。vers=3は、このコンテナ環境で動作するNFSプロトコルを維持します。0:dumpフィールドで、dumpバックアップユーティリティによって使用されます。0は無効を意味します。0:passフィールドで、fsckユーティリティが起動時のファイルシステムチェック順序を決定するために使用します。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 nfs (rw,relatime,vers=3,rsize=...,wsize=...,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,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 ... vers=3 ...) に移動し、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サーバーに対して、読み書き (rw) 権限を持つすべてのクライアント (*) と design および testing ディレクトリを共有するように指示します。
/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,vers=3 localhost:/srv/nfs/design
testing -fstype=nfs,rw,sync,vers=3 localhost:/srv/nfs/testing
行の内容を解説します。
design: 「キー」です。/project_shares以下のサブディレクトリ名に対応します。ユーザーが/project_shares/designにアクセスすると、この行がトリガーされます。-fstype=nfs,rw,sync,vers=3: マウントオプションです。ファイルシステムタイプ、読み書きアクセス、同期書き込み、およびこの実験環境で使用されるNFSバージョンを指定します。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
次に、サブディレクトリの1つにアクセスしてみます。これが 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,vers=3 localhost:/srv/nfs/common_data
この行を分析します。
/mnt/common: 「キー」ですが、ダイレクトマップの場合、キーはマウントポイントの 完全な絶対パス です。-fstype=nfs,rw,sync,vers=3: マウントオプションです。前と同じく、この実験環境で使用されるNFSバージョンを含みます。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
成功です！ ダイレクトマウントがオンデマンドで作成されました。この実験環境では、NFSサーバーとクライアントが同じマシンである場合、マウントの表示が異なる可能性があるため、成功した ls -l /mnt/common の出力が最も信頼できる確認方法です。
これで、動的サブディレクトリ用のインダイレクトマップと、静的な絶対マウントポイント用のダイレクトマップの両方を正常に設定できました。
異なるユーザーとしての直接および間接オートマウントの検証
この最後のステップでは、マルチユーザー環境でオートマウンターがどのように機能するかを検証します。オートマウントは共有を利用可能にしますが、ファイルへの読み取りや書き込みを実際に制御するのは、NFSサーバー上の基盤となるファイルシステムの権限です。テストユーザーをいくつか作成し、それぞれのNFS共有の所有権を割り当て、インダイレクトマップとダイレクトマップの両方へのアクセスをテストします。
この演習では、異なるチーム（例：デザインとテスト）がそれぞれの共有ディレクトリの所有権を持ち、他のユーザーには読み取りアクセスが可能だが、書き込みアクセスは所有者に制限されているという現実的なシナリオを示します。
ステップ 6.1: テストユーザーの作成と権限の設定
まず、designer1 と tester1 という2人の新しいユーザーを作成する必要があります。また、アカウントを切り替えられるように、彼らに単純なパスワードを割り当てます。
useradd コマンドを使用してユーザーを作成します。-m フラグは彼らのホームディレクトリを作成します。
sudo useradd -m designer1
sudo useradd -m tester1
次に、各ユーザーのパスワードを設定します。簡単にするため、この実験では両方に labex.io というパスワードを使用します（長さ、大文字小文字の混在、数字、特殊文字を含む複雑さの要件を満たしています）。
sudo passwd designer1
## Enter new UNIX password: labex.io
## Retype new UNIX password: labex.io
## passwd: password updated successfully
sudo passwd tester1
## Enter new UNIX password: labex.io
## Retype new UNIX password: labex.io
## passwd: password updated successfully
次に、「サーバー」側 (/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
## Password: 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: Permission denied
designer1 セッションを終了して labex ユーザーに戻ります。
exit
ステップ 6.3: tester1 ユーザーとしてのアクセステスト
次に、tester1 ユーザーとして同様のテストを実行します。
su - tester1
## Password: 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: 環境のクリーンアップ
実験を終了し、システムを元の状態に戻すために、作成したテストユーザーを削除します。userdel -r コマンドはユーザーとそのホームディレクトリを削除します。
sudo userdel -r designer1
sudo userdel -r tester1
これで、autofs を使用したNFS管理に関する実験は終了です。
まとめ
この実験では、RHELシステムでNFSクライアントアクセスを設定する方法を学びました。まず手動マウントを実行し、ローカルマウントポイントを作成してから mount コマンドを使用してNFS共有に接続しました。mount コマンドによる手動接続を確立した後、/etc/fstab ファイルにエントリを作成して永続的なマウントを設定し、起動時に共有が自動的にマウントされるようにしました。
さらに、autofs サービスを使用したオンデマンドマウントの設定についても学習しました。これにはサービスのインストールと有効化が含まれ、ディレクトリを動的にマウントするためのインダイレクトマップと、共有を静的で事前に定義された場所にマウントするためのダイレクトマップという、2つの異なる方法を使用して共有をマウントする方法を定義しました。プロセスは、直接および間接的なオートマウントが異なるユーザーに対して正しく機能することを確認して終了しました。
