「NFS」の版間の差分
Kusanaginoturugi (トーク | 投稿記録) |
Kusanaginoturugi (トーク | 投稿記録) (→クライアント設定: 記事を追加) |
||
158行目: | 158行目: | ||
== クライアント設定 == |
== クライアント設定 == |
||
− | NFSv4 で [[Kerberos]] を使用する場合、{{ic|nfs-client.target}} も[[起動]]・[[有効化]]する必要があります。 |
+ | NFSv4 で [[Kerberos]] を使用する場合、{{ic|nfs-client.target}} も[[起動]]・[[有効化]]する必要があります。 |
+ | === 手動マウント === |
||
− | {{hc|# systemctl edit rpc-gssd.service|2= |
||
− | [Unit] |
||
− | Requires=network-online.target |
||
− | After=network-online.target |
||
− | |||
− | [Service] |
||
− | Type=simple |
||
− | ExecStart= |
||
− | ExecStart=/usr/sbin/rpc.gssd -f |
||
− | }} |
||
− | |||
− | === Linux からマウントする === |
||
NFSv3 の場合、次のコマンドを使ってサーバーのエクスポートされたファイルシステムを表示: |
NFSv3 の場合、次のコマンドを使ってサーバーのエクスポートされたファイルシステムを表示: |
||
187行目: | 176行目: | ||
{{Note|サーバーの名前は (IP アドレスではなく) ホストネームを指定する必要があります。それ以外だとリモート共有がハングアップします。}} |
{{Note|サーバーの名前は (IP アドレスではなく) ホストネームを指定する必要があります。それ以外だとリモート共有がハングアップします。}} |
||
− | + | === /etc/fstab を使う === |
|
クライアントを立ち上げたときにいつでも NFS 共有が使えるように、常に稼働させているサーバーでは [[fstab]] を利用すると便利です。{{ic|/etc/fstab}} ファイルを編集して、設定に合わせて適切な行を追加してください。また、サーバーの NFS エクスポートルートは省略します。 |
クライアントを立ち上げたときにいつでも NFS 共有が使えるように、常に稼働させているサーバーでは [[fstab]] を利用すると便利です。{{ic|/etc/fstab}} ファイルを編集して、設定に合わせて適切な行を追加してください。また、サーバーの NFS エクスポートルートは省略します。 |
||
209行目: | 198行目: | ||
{{Note|6番目のフィールド ({{ic|fs_passno}}) をゼロ以外の値に設定すると予期しない挙動が発生することがあります。例えば systemd で自動マウントしたときにチェックの待機が行われなくなります。}} |
{{Note|6番目のフィールド ({{ic|fs_passno}}) をゼロ以外の値に設定すると予期しない挙動が発生することがあります。例えば systemd で自動マウントしたときにチェックの待機が行われなくなります。}} |
||
− | + | === systemd で /etc/fstab を使う === |
|
systemd の {{ic|automount}} サービスを使う方法もあります。接続が遮断されたり、復帰した時に素早くネットワークデバイスを再マウントするため、{{ic|_netdev}} よりも好ましいと思われます。さらに、autofs の問題も解決します、下の例を見て下さい: |
systemd の {{ic|automount}} サービスを使う方法もあります。接続が遮断されたり、復帰した時に素早くネットワークデバイスを再マウントするため、{{ic|_netdev}} よりも好ましいと思われます。さらに、autofs の問題も解決します、下の例を見て下さい: |
||
228行目: | 217行目: | ||
{{Note|サーバーでも同じ方法で systemd で NFS 共有を自動マウントすると、データの量が多かった場合にフリーズする可能性があります。}} |
{{Note|サーバーでも同じ方法で systemd で NFS 共有を自動マウントすると、データの量が多かった場合にフリーズする可能性があります。}} |
||
− | + | === As systemd unit === |
|
+ | |||
+ | Create a new {{ic|.mount}} file inside {{ic|/etc/systemd/system}}, e.g. {{ic|mnt-home.mount}}. See {{man|5|systemd.mount}} for details. |
||
+ | |||
+ | {{Note|Make sure the filename corresponds to the mountpoint you want to use. |
||
+ | E.g. the unit name {{ic|mnt-home.mount}} can only be used if you are going to mount the share under {{ic|/mnt/home}}. Otherwise the following error might occur: {{ic|1=systemd[1]: mnt-home.mount: Where= setting does not match unit name. Refusing.}}. If the mountpoint contains non-ASCII characters, use [[Systemd#Writing unit files|systemd-escape]]).}} |
||
+ | |||
+ | {{ic|1=What=}} path to share |
||
+ | |||
+ | {{ic|1=Where=}} path to mount the share |
||
+ | |||
+ | {{ic|1=Options=}} share mounting options |
||
+ | |||
+ | {{Note| |
||
+ | * Network mount units automatically acquire {{ic|After}} dependencies on {{ic|remote-fs-pre.target}}, {{ic|network.target}} and {{ic|network-online.target}}, and gain a {{ic|Before}} dependency on {{ic|remote-fs.target}} unless {{ic|nofail}} mount option is set. Towards the latter a {{ic|Wants}} unit is added as well. |
||
+ | * [[Append]] {{ic|noauto}} to {{ic|Options}} preventing automatically mount during boot (unless it is pulled in by some other unit). |
||
+ | * If you want to use a hostname for the server you want to share (instead of an IP address), add {{ic|1=nss-lookup.target}} to {{ic|1=After}}. This might avoid mount errors at boot time that do not arise when testing the unit. |
||
+ | }} |
||
+ | |||
+ | {{hc|/etc/systemd/system/mnt-home.mount|2= |
||
+ | [Unit] |
||
+ | Description=Mount home at boot |
||
+ | |||
+ | [Mount] |
||
+ | What=172.16.24.192:/home |
||
+ | Where=/mnt/home |
||
+ | Options=vers=4 |
||
+ | Type=nfs |
||
+ | TimeoutSec=30 |
||
+ | |||
+ | [Install] |
||
+ | WantedBy=multi-user.target |
||
+ | }} |
||
+ | |||
+ | {{Tip|In case of an unreachable system, [[append]] {{ic|1=ForceUnmount=true}} to {{ic|[Mount]}}, allowing the export to be (force-)unmounted.}} |
||
+ | |||
+ | To use {{ic|mnt-home.mount}}, [[start]] the unit and [[enable]] it to run on system boot. |
||
+ | |||
+ | ==== automount ==== |
||
+ | |||
+ | To automatically mount a share, one may use the following automount unit: |
||
+ | |||
+ | {{hc|/etc/systemd/system/mnt-home.automount|2= |
||
+ | [Unit] |
||
+ | Description=Automount home |
||
+ | |||
+ | [Automount] |
||
+ | Where=/mnt/home |
||
+ | |||
+ | [Install] |
||
+ | WantedBy=multi-user.target |
||
+ | }} |
||
+ | |||
+ | [[Disable]]/[[stop]] the {{ic|mnt-home.mount}} unit, and [[enable]]/[[start]] {{ic|mnt-home.automount}} to automount the share when the mount path is being accessed. |
||
+ | |||
+ | {{Tip|[[Append]] {{ic|TimeoutIdleSec}} to enable auto unmount. See {{man|5|systemd.automount}} for details.}} |
||
+ | |||
+ | === autofs を使う === |
||
複数のマシンを NFS で接続したい場合は [[autofs]] を使うのが便利です。サーバーだけでなくクライアントにもなることができます。他の簡単な方法よりもこの方法が推奨される理由は、サーバーの電源が落とされた時に、クライアントがNFS 共有を見つけられないことについてエラーを投げないからです。詳しくは [[autofs#NFS ネットワークマウント]] を見て下さい。 |
複数のマシンを NFS で接続したい場合は [[autofs]] を使うのが便利です。サーバーだけでなくクライアントにもなることができます。他の簡単な方法よりもこの方法が推奨される理由は、サーバーの電源が落とされた時に、クライアントがNFS 共有を見つけられないことについてエラーを投げないからです。詳しくは [[autofs#NFS ネットワークマウント]] を見て下さい。 |
2024年4月19日 (金) 19:16時点における版
関連記事
Wikipedia より:
- Network File System (NFS) はローカルストレージにアクセスするのと同じようにネットワーク上のファイルにクライアントコンピュータでアクセスできるようにする分散ファイルシステムおよびそのプロトコルである。1984年に Sun Microsystems によって開発された。
インストール
クライアントとサーバーどちらでも必要なのは nfs-utils パッケージのインストールだけです。
クライアント・サーバーの時計を一致させるために全てのノードで時刻同期デーモンを使うことが強く推奨されます。全てのノードで時計が正確でないと、NFS は望ましくない遅延を生じさせる可能性があります。
サーバー設定
グローバル設定オプションは /etc/nfs.conf
で設定されます。単純な設定を使用するユーザーはこのファイルを編集する必要はありません。
NFS サーバーは、共有するディレクトリのリストが必要で、/etc/exports
または /etc/exports.d/*.exports
に定義する必要があります(詳細は exports(5) を参照)。デフォルトでは、ディレクトリはそのパスのままエクスポートされます。例えば:
/etc/exports
/data/music 192.168.1.0/24(rw)
上記の設定により、ディレクトリ /data/music
は NFSv3 および NFSv4 で MyServer:/data/music
としてマウント可能になります。
カスタムエクスポートルート
共有はいわゆる NFS ルートからの相対パスになります。セキュリティ上、NFS ルートを定義するときはサーバーのルートファイルシステム下の専用のディレクトリツリーを使用して、ユーザーからマウントポイントへのアクセスを制限すると良いでしょう。バインドマウントは、共有マウントポイントを ファイルシステム 上の実際のディレクトリにリンクするために使用されます。過去には NFSv4 で NFS ルートが必須でしたが、現在はオプションです(カーネル 2.6.33 および nfs-utils 1.2.2 から、仮想ルートが実装されています)。
下の例では以下の設定を使用します:
- NFS ルートは
/srv/nfs
。 - エクスポートは
/srv/nfs/music
で/mnt/music
にバインドマウントする。
# mkdir -p /srv/nfs/music /mnt/music # mount --bind /mnt/music /srv/nfs/music
サーバーを再起動してもマウントされるように、バインドマウントを fstab に追加:
/etc/fstab
/mnt/music /srv/nfs/music none bind 0 0
CIDR によるアドレス指定またはホストネームを使ってマウントを許可するクライアントマシンを制限するには /etc/exports
に以下のように共有ディレクトリを追加:
/etc/exports
/srv/nfs 192.168.1.0/24(rw,fsid=root) /srv/nfs/music 192.168.1.0/24(rw,sync) /srv/nfs/home 192.168.1.0/24(rw,sync) /srv/nfs/public 192.168.1.0/24(ro,all_squash,insecure) desktop(rw,sync,all_squash,anonuid=99,anongid=99) # map to user/group - in this case nobody
NFSv4 を使用する場合、オプション fsid=root
または fsid=0
は「ルート」エクスポートを示します。そのようなエクスポートが存在する場合、他のすべてのディレクトリはそれ以下でなければなりません。/etc/nfs.conf
ファイルの rootdir
オプションはこれに影響しません。fsid=0
エクスポートがない場合のデフォルトの動作は、NFSv3 と同じように動作することです。
上記の例では、/srv/nfs
がルートとして指定されているため、エクスポート /srv/nfs/music
は NFSv4 を介して MyServer:/music
としてマウント可能になります - ルートプレフィックスは省略されることに注意してください。
サーバー実行中に /etc/exports
を変更した場合は再度エクスポートしないと変更が適用されないので注意してください:
# exportfs -rav
現在ロードされているエクスポートの状態をより詳細に見るには、以下を使用する:
# exportfs -v
利用可能なオプションについて詳しくは exports(5) を参照してください。
サーバーを起動する
- NFSv3 および NFSv4 サービスを提供するには、
nfs-server.service
を開始して有効化します。 - NFSv4 サービスのみを提供するには、
nfsv4-server.service
を開始して有効化します。
プロトコルバージョン 4 のエクスポートを使用するユーザーは、不要なサービスが実行されないように、最低限 rpcbind.service
と rpcbind.socket
を マスク することを望むでしょう。詳細は FS#76453 を参照してください。また、何らかの理由で引き込まれた nfs-server.service
もマスクすることを検討してください。
特定のインターフェイスあるいは IP からのアクセスに NFS を制限
デフォルトでは nfs-server.service
を起動すると /etc/exports
とは関係なく全てのネットワークインターフェイスから接続を待機します。待機する IP あるいはホストネームを定義することで挙動を変更できます:
/etc/nfs.conf
[nfsd] host=192.168.1.123 # Alternatively, you can use your hostname. # host=myhostname
変更を適用するには nfs-server.service
を再起動してください。
ファイアウォール設定
ファイアウォールを通過してアクセスできるようにするには、デフォルト設定の場合 tcp と udp のポート 111, 2049, 20048 を開放する必要があります。rpcinfo -p
を使ってサーバーで使用しているポートを確認してください。この設定を iptables でするには、/etc/iptables/iptables.rules
を編集して以下の行を含めるようにしてください:
/etc/iptables/iptables.rules
-A INPUT -p tcp -m tcp --dport 111 -j ACCEPT -A INPUT -p tcp -m tcp --dport 2049 -j ACCEPT -A INPUT -p tcp -m tcp --dport 20048 -j ACCEPT -A INPUT -p udp -m udp --dport 111 -j ACCEPT -A INPUT -p udp -m udp --dport 2049 -j ACCEPT -A INPUT -p udp -m udp --dport 20048 -j ACCEPT
NFSv3 と、上記の rpc.statd
や lockd
の固定ポートを使用している場合は、それらも設定に追加してください:
/etc/iptables/iptables.rules
-A INPUT -p tcp -m tcp --dport 32765 -j ACCEPT -A INPUT -p tcp -m tcp --dport 32803 -j ACCEPT -A INPUT -p udp -m udp --dport 32765 -j ACCEPT -A INPUT -p udp -m udp --dport 32803 -j ACCEPT
v4 以上だけを使う構成の場合、開く必要があるのは tcp ポート 2049 だけです。したがって、必要な行は一行だけになります:
/etc/iptables/iptables.rules
-A INPUT -p tcp -m tcp --dport 2049 -j ACCEPT
変更を適用するために、iptables
サービスを再起動してください。
NFSv4 の ID マッピングが有効になっていることを確認
idmapd が動作していても、マッピングが完全には有効になっていないことがあります。/sys/module/nfsd/parameters/nfs4_disable_idmapping
が N
になっている場合、以下のコマンドを実行することで有効にできます:
# echo "N" | sudo tee /sys/module/nfsd/parameters/nfs4_disable_idmapping
変更を永続化するにはモジュールオプションで設定してください:
/etc/modprobe.d/nfsd.conf
options nfsd nfs4_disable_idmapping=0
クライアント設定
NFSv4 で Kerberos を使用する場合、nfs-client.target
も起動・有効化する必要があります。
手動マウント
NFSv3 の場合、次のコマンドを使ってサーバーのエクスポートされたファイルシステムを表示:
$ showmount -e servername
NFSv4 の場合、root NFS ディレクトリをマウントして利用できるマウントを確認:
# mount server:/ /mountpoint/on/client
そしてサーバーの NFS エクスポートルートは省略してマウント:
# mount -t nfs -o vers=4 servername:/music /mountpoint/on/client
マウントが失敗する場合はサーバーのエクスポートルートを含めて見て下さい (Debian/RHEL/SLES では必須、ディストリビューションによっては -t nfs
ではなく -t nfs4
):
# mount -t nfs -o vers=4 servername:/srv/nfs/music /mountpoint/on/client
/etc/fstab を使う
クライアントを立ち上げたときにいつでも NFS 共有が使えるように、常に稼働させているサーバーでは fstab を利用すると便利です。/etc/fstab
ファイルを編集して、設定に合わせて適切な行を追加してください。また、サーバーの NFS エクスポートルートは省略します。
/etc/fstab
servername:/music /mountpoint/on/client nfs rsize=8192,wsize=8192,timeo=14,_netdev 0 0
マウントオプションの説明は以下の通り:
- rsize と wsize
rsize
はサーバーから読み込むときに使用されるバイト数の値です。wsize
はサーバーに書き込むときのバイト数の値です。どちらもデフォルトは 1024 ですが、8192 などと値を高く設定することでスループットを改善できます。この値は汎用ではありません。値を変更した後にテストを行うことを推奨します、#パフォーマンスチューニングを見てください。
- timeo
timeo
は RPC タイムアウトの後に再送信を行うまで待機する時間の値です (10分の1秒単位)。最初にタイムアウトした後、再試行する度にタイムアウトの値は2倍になっていき、最大60秒になるか正式なタイムアウトになります。遅いサーバーやトラフィックの多いネットワークに接続する場合、このタイムアウトの値を増やすことでパフォーマンスが改善されるかもしれません。
- _netdev
_netdev
オプションは共有をマウントする前にネットワークが立ち上がるまで待機するようシステムに通知するオプションです。systemd は NFS がこのオプションを使うことを想定していますが、どんな形式のネットワークファイルシステムであれ、このオプションを使うことはグッドプラクティスと言えます。
- minorversion
- NFS バージョン 4.1 の Windows Server 2012 (Essentials) の共有をマウントするときは
minorversion=1
を使います。
systemd で /etc/fstab を使う
systemd の automount
サービスを使う方法もあります。接続が遮断されたり、復帰した時に素早くネットワークデバイスを再マウントするため、_netdev
よりも好ましいと思われます。さらに、autofs の問題も解決します、下の例を見て下さい:
/etc/fstab
servername:/home /mountpoint/on/client nfs noauto,x-systemd.automount,x-systemd.device-timeout=10,timeo=14,x-systemd.idle-timeout=1min 0 0
systemd が fstab の変更に気づくようにクライアントを再起動する必要があります。もしくは、systemd をリロードして mountpoint-on-client.automount
を再起動して /etc/fstab
の設定を再読み込みしてください。
As systemd unit
Create a new .mount
file inside /etc/systemd/system
, e.g. mnt-home.mount
. See systemd.mount(5) for details.
What=
path to share
Where=
path to mount the share
Options=
share mounting options
/etc/systemd/system/mnt-home.mount
[Unit] Description=Mount home at boot [Mount] What=172.16.24.192:/home Where=/mnt/home Options=vers=4 Type=nfs TimeoutSec=30 [Install] WantedBy=multi-user.target
To use mnt-home.mount
, start the unit and enable it to run on system boot.
automount
To automatically mount a share, one may use the following automount unit:
/etc/systemd/system/mnt-home.automount
[Unit] Description=Automount home [Automount] Where=/mnt/home [Install] WantedBy=multi-user.target
Disable/stop the mnt-home.mount
unit, and enable/start mnt-home.automount
to automount the share when the mount path is being accessed.
autofs を使う
複数のマシンを NFS で接続したい場合は autofs を使うのが便利です。サーバーだけでなくクライアントにもなることができます。他の簡単な方法よりもこの方法が推奨される理由は、サーバーの電源が落とされた時に、クライアントがNFS 共有を見つけられないことについてエラーを投げないからです。詳しくは autofs#NFS ネットワークマウント を見て下さい。
ヒントとテクニック
パフォーマンスチューニング
When using NFS on a network with a significant number of clients one may increase the default NFS threads from 8 to 16 or even a higher, depending on the server/network requirements:
/etc/nfs.conf
[nfsd] threads=16
NFS の性能を完全に発揮するには、ネットワーク設定にあわせて rsize
や wsize
マウントオプションを調整する必要があります。
最近の Linux カーネル (2.6.18 以上) ではメモリの容量によって NFS サーバーが使用できる I/O のサイズ (最大ブロックサイズ) が変わります。最大は 1M (1048576バイト) で、NFS クライアントがより大きな rsize
や wsize
を必要としている場合でもサーバーの最大ブロックサイズが使われます [1]。nfsd を起動する前に /proc/fs/nfsd/max_block_size
に書き込むことでサーバーのデフォルト最大ブロックサイズを変更できます。例えば、以下のコマンドは昔のデフォルトの IO サイズであった 32k に設定します:
# echo 32767 > /proc/fs/nfsd/max_block_size
変更を永続化するには systemd-tmpfile を作成してください:
/etc/tmpfiles.d/nfsd-block-size.conf
w /proc/fs/nfsd/max_block_size - - - - 32768
To mount with the increased rsize
and wsize
mount options:
# mount -t nfs -o rsize=32768,wsize=32768,vers=4 servername:/srv/nfs/music /mountpoint/on/client
Furthermore, despite the violation of NFS protocol, setting async
instead of sync
or sync,no_wdelay
may potentially achieve a significant performance gain especially on spinning disks. Configure exports with this option and then execute exportfs -arv
to apply.
/etc/exports
/srv/nfs 192.168.1.0/24(rw,async,crossmnt,fsid=0) /srv/nfs/music 192.168.1.0/24(rw,async)
自動マウントの処理
ローカルのワイヤレスネットワークから nfs 共有を使う必要があるノートパソコンでこの設定は役に立ちます。nfs ホストが到達できない状態になったとき、nfs 共有はアンマウントされ、hard マウントオプションを使っている際にシステムフリーズが起こらなくなります。https://bbs.archlinux.org/viewtopic.php?pid=1260240#p1260240 を参照。
NFS のマウントポイントが /etc/fstab
に正しく記述されていることを確認してください:
/etc/fstab
lithium:/mnt/data /mnt/data nfs noauto,noatime,rsize=32768,wsize=32768 0 0 lithium:/var/cache/pacman /var/cache/pacman nfs noauto,noatime,rsize=32768,wsize=32768 0 0
noauto
マウントオプションは起動時に自動的に共有をマウントしないように systemd に命じます。これを設定していないとネットワーク上に共有が存在するかどうかわからないのに systemd が共有をマウントしようとしてブート中にブランクスクリーンで止まってしまいます。
root 以外のユーザー user
で NFS 共有をマウントするには fstab にエントリを追加する必要があります。
cron を使って NFS ホストが到達可能なチェックする auto_share
スクリプトを作成:
/usr/local/bin/auto_share
#!/bin/bash function net_umount { umount -l -f $1 &>/dev/null } function net_mount { mountpoint -q $1 || mount $1 } NET_MOUNTS=$(sed -e '/^.*#/d' -e '/^.*:/!d' -e 's/\t/ /g' /etc/fstab | tr -s " ")$'\n'b printf %s "$NET_MOUNTS" | while IFS= read -r line do SERVER=$(echo $line | cut -f1 -d":") MOUNT_POINT=$(echo $line | cut -f2 -d" ") # Check if server already tested if [[ "${server_ok[@]}" =~ "${SERVER}" ]]; then # The server is up, make sure the share are mounted net_mount $MOUNT_POINT elif [[ "${server_notok[@]}" =~ "${SERVER}" ]]; then # The server could not be reached, unmount the share net_umount $MOUNT_POINT else # Check if the server is reachable ping -c 1 "${SERVER}" &>/dev/null if [ $? -ne 0 ]; then server_notok[${#Unix[@]}]=$SERVER # The server could not be reached, unmount the share net_umount $MOUNT_POINT else server_ok[${#Unix[@]}]=$SERVER # The server is up, make sure the share are mounted net_mount $MOUNT_POINT fi fi done
スクリプトに実行権限を付与:
# chmod +x /usr/local/bin/auto_share
cron エントリか systemd タイマーを作成して、共有サーバーにアクセスできるか1分ごとに確認するようにしてください。
Cron
# crontab -e
* * * * * /usr/local/bin/auto_share
systemd/タイマー
以下のユニットを作成:
# /etc/systemd/system/auto_share.timer
[Unit] Description=Check the network mounts [Timer] OnCalendar=*-*-* *:*:00 [Install] WantedBy=timers.target
# /etc/systemd/system/auto_share.service
[Unit] Description=Check the network mounts [Service] Type=simple ExecStart=/usr/local/bin/auto_share
作成したら auto_share.timer
を有効化してください。
systemd で起動時にマウント
systemd のユニットファイルを使って起動時に NFS 共有をマウントすることも可能です。クライアントに NetworkManager がインストール・設定されている場合はユニットファイルは必要ありません。#NetworkManager dispatcher を見て下さい。
/etc/systemd/system/auto_share.service
[Unit] Description=NFS automount After=syslog.target network.target [Service] Type=oneshot RemainAfterExit=yes ExecStart=/usr/local/bin/auto_share [Install] WantedBy=multi-user.target
auto_share.service
を有効化してください。
NetworkManager dispatcher を使う
上で説明している方法に加えて、ネットワークの状態が変わった時にスクリプトを実行するよう NetworkManager を設定することもできます。
NetworkManager-dispatcher
サービスを有効化・起動してください。
ネットワーク状態の変化にあわせてネットワーク上の共有をマウントする一番簡単な方法は auto_share
スクリプトにシンボリックリンクを作成することです:
# ln -s /usr/local/bin/auto_share /etc/NetworkManager/dispatcher.d/30-nfs.sh
ただし、特定の場合では、ネットワーク接続が無効になった後にアンマウントが実行され、KDE Plasma アプレットがフリーズしたりすることがあります。
以下のスクリプトを使うことでネットワーク接続が切れる前に NFS 共有を安全にアンマウントすることができます:
/etc/NetworkManager/dispatcher.d/30-nfs.sh
#!/bin/bash # Find the connection UUID with "nmcli con show" in terminal. # All NetworkManager connection types are supported: wireless, VPN, wired... WANTED_CON_UUID="CHANGE-ME-NOW-9c7eff15-010a-4b1c-a786-9b4efa218ba9" if [[ "$CONNECTION_UUID" == "$WANTED_CON_UUID" ]]; then # Script parameter $1: NetworkManager connection name, not used # Script parameter $2: dispatched event case "$2" in "up") mount -a -t nfs4,nfs ;; "pre-down");& "vpn-pre-down") umount -l -a -t nfs4,nfs >/dev/null ;; esac fi
スクリプトに実行可能属性を付与:
# chmod +x /etc/NetworkManager/dispatcher.d/30-nfs.sh
/etc/NetworkManager/dispatcher.d/pre-down
にシンボリックリンクを作成して pre-down
イベントをキャッチ:
# ln -s /etc/NetworkManager/dispatcher.d/30-nfs.sh /etc/NetworkManager/dispatcher.d/pre-down.d/30-nfs.sh
上記のスクリプトは別の接続で別の共有をマウントするように修正することができます。
NetworkManager#dispatcher を使って CIFS 共有のマウントを処理を参照。
TLS encryption
NFS traffic can be encrypted using TLS as of Linux 6.5 using the xprtsec=tls
mount option. To begin, install the ktls-utilsAUR package on the client and server, and follow the below configuration steps for each.
Server
Create a private key and obtain a certificate containing your server's DNS name (see Transport Layer Security for more detail). These files do not need to be added to the system's trust store.
Edit /etc/tlshd.conf
to use these files, using your own values for x509.certificate
and x509.private_key
/etc/tlshd.conf
[authenticate.server] x509.certificate= /etc/nfsd-certificate.pem x509.private_key= /etc/nfsd-private-key.pem
Now start and enable tlshd.service
.
Client
Add the server's TLS certificate generated in the previous step to the system's trust store (see Transport Layer Security for more detail).
Start and enable tlshd.service
.
Now you should be able to mount the server using the server's DNS name:
# mount -o xprtsec=tls servername.domain:/ /mountpoint/on/client
Checking journalctl on the client should show that the TLS handshake was successful:
$ journalctl -b -u tlshd.service
Sep 28 11:14:46 client tlshd[227]: Built from ktls-utils 0.10 on Sep 26 2023 14:24:03 Sep 28 11:15:37 client tlshd[571]: Handshake with servername.domain (192.168.122.100) was successful
トラブルシューティング
NFS/トラブルシューティングを参照してください。