跳至內容

NFS

出自 Arch Linux 中文维基

本文或本節需要翻譯。要貢獻翻譯,請訪問簡體中文翻譯團隊

附註: Some content is not translated.(在 Talk:NFS# 中討論)

來自維基百科:NFS 網絡文件系統(Network File System)是由 Sun 公司 1984 年發布的分布式文件系統協議。它允許客戶端上的用戶像訪問本地文件一樣地訪問網絡上的文件。

注意:
  • 默認情況下,NFS不提供加密功能. 在處理敏感數據時,請使用 #TLS 加密Kerberos(使用 sec=krb5p 提供基於 Kerberos 的加密),也可以使用類似 WireGuard 的加密 VPN 協議傳輸NFS流量.
  • Samba 不同, NFS默認不提供任何驗證用戶的方法,客戶端訪問限制是通過 IP 地址和/或計算機名實現的。如果需要更強的加密方式,也可以使用 Kerberos。
  • NFS期望用戶和/或用戶組的 ID 在客戶端與服務端上是相同的(使用 Kerberos 的情況下除外)。使用啟用 NFSv4 ID 映射,或使用anonuid/anongid並在/etc/exports中啟用all_squash,手動改變 UID/GID 來解決這一問題.
  • NFS 不支持 POSIX ACL。NFS 服務器還是會強制應用 ACL 規則,但客戶端無法觀察或是對其進行修改。

安裝[編輯 | 編輯原始碼]

客戶端和服務端都只需要安裝 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 暴露到 MyServer:/data/music 路徑下,可通過 NFSv3 或 NFSv4 進行掛載。

指定導出根目錄[編輯 | 編輯原始碼]

共享對象是相對於所謂的「NFS 根目錄」的.出於安全考慮,建議定義一個單獨的目錄為 NFS 根,這可以將用戶限制在該掛載點中。綁定的掛載點(bind mounts)將文件系統上他處的目錄與被分享的掛載點連接起來。之前 NFSv4 強制要求使用 NFS 根目錄,現在成了可選項(從內核 2.6.33 和 nfs-utils 1.2.2 版本開始實現了虛擬根目錄)。

查看下面的例子。在本例中:

  1. NFS 根目錄是 /srv/nfs
  2. 將要共享的目錄是 /srv/nfs/music,該目錄以綁定掛載方式指向了它實際的位置/mnt/music
# mkdir -p /srv/nfs/music /mnt/music
# mount --bind /mnt/music /srv/nfs/music
注意: ZFS 文件系統對於 bindmounts 方式掛載要特殊處理,參閱 ZFS#Bind mount

為了讓服務器重啟後共享仍舊有效,增加綁定到 fstab 文件:

/etc/fstab
/mnt/music /srv/nfs/music  none   bind   0   0

增加允許被掛載的目錄和使其只能被屬於特定 CIDR 所指定的 IP 範圍或擁有特定主機名的客戶端所訪問的限制至 /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) # 將訪客映射到特定用戶組 - 在本例中是nobody

在使用 NFSv4 時,fsid=rootfsid=0 選項指定了導出目錄「根」的位置;如果使用這些選項指定了導出目錄,那其它文件夾都必須位於該文件夾下。/etc/nfs.conf 文件中的 rootdir 選項在這種情況下不起效。如果沒有指定 fsid=0,那默認行為與 NFSv3 一致。

在上面的實例中,/srv/nfs 被指定為根,且可以通過 NFSv4 按 MyServer:/music 目錄掛載 /srv/nfs/music 文件夾 - 注意,根目錄前綴被省略了。

提示:
  • 對 NFSv3 而言(不適用於 NFSv4),crossmnt 選項使客戶端可以訪問所有掛載在文件系統上並標記有 crossmnt 的文件系統並且客戶端不需要單獨逐個掛載子共享. 請注意,你可能不希望在子共享同時被共享到另一端地址時使用該選項.
  • 除了 crossmnt 之外,你也可以在子共享上使用 nohide 選項,這樣的話,子共享就會在根共享被掛載時自動掛載。與 crossmnt 不同的是,nohide 仍然會遵守子共享的地址範圍。注意,該選項僅適用於 NFSv3,NFSv4 永遠表現為該選項已啟用。
  • insecure 選項使客戶端可以用高於 1023 的端口進行連接。(大概是只有 root 用戶可以使用較低編號的端口,因此阻斷其它端口可以作為簡單的訪問控制方法。在實際使用中,使用 insecure 選項與否並不能帶來任何安全方面的提升或是下降。)
  • 使用一個通配符(*)以允許來自所有接口的訪問.

如果服務運行時修改了 /etc/exports 文件, 你需要重新導出使其生效:

# exportfs -arv

想要查看已經加載的共享的詳細信息,請使用:

# exportfs -v

有關所有可用選項的詳細介紹,請參閱exports(5).

提示:ip2cidr 是一個可以將 IP 範圍轉換為 CIDR 的工具.
注意: 如果共享是tmpfs文件系統,你需要指定fsid=1選項.

開始運行服務[編輯 | 編輯原始碼]

  • 要提供 NFSv3 和 NFSv4 服務,啟動啟用 nfs-server.service
  • 要僅提供 NFSv4 服務,啟動啟用 nfsv4-server.service

v4 版本協議的用戶可能需要至少屏蔽rpcbind.servicerpcbind.socket,以防止不需要的服務自啟,詳細信息請參考 [1]。另外,也可以禁用 nfs-server.service 以防止其由於某些原因而被拉起。

注意: 在啟用ZFS共享的同時,請一併啟動/啟用 zfs-share.service。如果不這麼做的話,在重啟之後 ZFS 目錄不會被共享.參閱 ZFS#NFS.

限制 NFS 使其只允許來自特定接口/IP 地址的訪問[編輯 | 編輯原始碼]

默認情況下,啟動 nfs-server.service 會忽略 /etc/exports 文件的內容,而是在所有網絡接口上監聽連接。可以通過定義監聽的IP和/或主機名來改變這一行為。

/etc/nfs.conf
[nfsd]
host=192.168.1.123
# 或者也可以使用主機名
# host=myhostname

在修改完後,重啟 nfs-server.service 以應用設置。

防火牆配置[編輯 | 編輯原始碼]

如果要訪問防火牆後的 NFSv4 服務器,就需要開放 2049 端口的 TCP 上行連接。(NFSv4 使用靜態網絡端口;它不使用任何像 mountd 或是 portmapper 這樣的輔助服務。)

如果要訪問 NFSv3 服務器,就還需要額外為 portmapper(rpcbind)開放 111 端口的 TCP/UDP 連接,還需要為 MOUNT(rpc.mountd)開放端口。默認情況下,rpc.mountd 會動態選擇端口,所以如果你要訪問防火牆後的服務,就需要通過編輯 /etc/nfs.conf 配置來選擇一個固定端口。可以使用 rpcinfo -p 查看 NFSv3 服務器使用的具體端口信息:

$ rpcinfo -p
100003    3   tcp   2049  nfs
100003    4   tcp   2049  nfs
100227    3   tcp   2049  nfs_acl
...

客戶端配置[編輯 | 編輯原始碼]

打算將 NFS4 與 Kerberos 一起使用的用戶需要啟動啟用 nfs-client.target.

手動掛載[編輯 | 編輯原始碼]

對於NFSv3,請使用以下命令顯示服務器分享的文件系統:

$ showmount -e servername

對於NFSv4,請掛載NFS根目錄,並查看可用的掛載:

# mount servername:/ /mountpoint/on/client

然後掛載分享.掛載時省略服務器的NFS分享根目錄:

# mount -t nfs -o vers=4 servername:/music /mountpoint/on/client

如果掛載失敗,請嘗試包括服務器的分享根目錄(對於Debian/RHEL/SLES是必需的,某些發行版需要使用-t nfs4而不是-t nfs):

# mount -t nfs -o vers=4 servername:/srv/nfs/music /mountpoint/on/client
注意: servername 必須被替換為有效的主機名(而不僅僅是IP地址)。否則,掛載遠程共享將掛起。

使用/etc/fstab掛載[編輯 | 編輯原始碼]

對於服務器保持開啟,且無論客戶端何時啟動皆可用的 NFS 共享而言,fstab 非常有用。編輯 /etc/fstab,然後根據需要添加一行新配置。同樣,服務端的 NFS 導出根路徑已被缺省。

/etc/fstab
servername:/music   /mountpoint/on/client   nfs   defaults,timeo=900,retrans=5,_netdev	0 0
注意: 更多掛載選項可參考 nfs(5)mount(8)

以下為一些可參考的掛載選項:

rsize 和 wsize:rsize 指單次請求從服務器讀取的字節數,wsize 指單次請求向服務器寫入的字節數。默認情況下,如果未指定值,客戶端和服務端會協商使用它們都支持的最大值(參考 nfs(5))。修改值後,建議進行性能測試(參考#性能調優)。
soft 或 hard:決定在 NFS 請求超時後的恢復行為。如果沒有指定(或者指定了 hard 選項),NFS 會無限重試請求。如果指定了 soft 選項,那麼 NFS 客戶端會在重試 retrans 指定的次數後失敗,導致 NFS 客戶端向發起應用返回錯誤。
警告: soft(軟)超時在某些情況下會導致數據靜默損壞。因此,建議僅在客戶端響應度優先于于數據完整性的情況下使用 soft 選項。使用基於 TCP 傳輸的 NFS 或增加 retrans 選項數值有助於降低使用 soft 導致的故障風險。
timeo:timeo 表示在遇到 RPC 超時後重發前的等待時間,單位為十分之一秒。對基於 TCP 的 NFS 而言默認值為 600(即 60 秒)。在首次超時後,超時值都將加倍,最大不超過 60 秒或是出現重大超時。在連接到慢速服務器或是使用高負載網絡時,增加超時值有助於提高連接穩定性。
retrans:NFS 客戶端在執行下一步恢復操作前的請求重試次數。如果未指定 retrans 值,那 NFS 客戶端會為請求重試 3 次。在 retrans 次重試後,NFS 客戶端會生成一條「server not responding」消息,然後進行下一步恢復嘗試(取決於是否使用了硬掛載選項)。
_netdev:_netdev 選項告知系統在網絡就緒後再嘗試掛載該共享 - systemd 會自動為 NFS 使用該項。
注意: 將第六項(fs_passno)設為非零值可能會導致預期外行為,例如當 systemd 自動掛載等待永不會發生的檢查時掛起

搭配 /etc/fstab 和 systemd 進行掛載[編輯 | 編輯原始碼]

另一種方法是使用 x-systemd.automount 選項,它會在訪問時掛載文件系統:

/etc/fstab
servername:/home   /mountpoint/on/client  nfs  _netdev,noauto,x-systemd.automount,x-systemd.mount-timeout=10,timeo=14,x-systemd.idle-timeout=1min 0 0

為了讓 systemd 意識到 fstab 的更改,需要重新加載 systemd 並重啟 remote-fs.target [2]

本文或本章節的事實準確性存在爭議。

原因: 不是所有人都用 NetworkManager。是否可以用Systemd#在網絡已連接後再啟動某服務替代?(在 Talk:NFS 中討論)


提示:
  • noauto 選項使得在訪問 NFS 共享前不會進行掛載;使用 auto 會立刻進行掛載。
    如果遇到了網絡未拉起/不可用導致的掛載失敗,可以啟用 NetworkManager-wait-online.service。它會確保在激活前 network.target 已準備好所有鏈接可用。
  • users 選項允許普通用戶進行掛載,但請注意,它同時啟用了如 noexec 等隱藏掛載選項。
  • x-systemd.idle-timeout=1min 會在 1 分鐘內未使用 NFS 共享的情況下自動將其卸載。該選項對於隨時會斷網的筆記本環境來說比較有用。
  • 如果由於 NFS 導致關機/重啟時間過長,可以啟用 NetworkManager-wait-online.service 來確保 NetworkManager 在 NFS 卷卸載前不會關閉。
  • 不要添加 x-systemd.requires=network-online.target 掛載選項,該選項可能會導致 systemd 出現啟動順序循環 [3]。systemd 會根據 _netdev 選項自動將 network-online.target 添加為單元依賴。
  • nocto 選項可能會提高只讀掛載的性能,但應只用在服務器上數據不經常出現變更的情況下。

作為 systemd 單元[編輯 | 編輯原始碼]

/etc/systemd/system目錄下創建一個新.mount 文件,例如mnt-home.mount.有關詳細信息,請參見systemd.mount(5).

注意: 確保文件名與您要使用的掛載點相對應.例如,僅當要將共享掛載到 /mnt/home 時才能使用單元名稱 mnt-home.mount,否則可能會發生以下錯誤:systemd[1]: mnt-myshare.mount: Where= setting does not match unit name. Refusing.。如果掛載點包含非 ASCII 字符,請使用 systemd-escape

What= 分享的路徑

Where= 分享應當被掛載的路徑

Options= 掛載分享的選項

{{注意|

  • 網絡安裝單元會自動獲取對 remote-fs-pre.targetnetwork.targetnetwork-online.targetAfter 依賴,並獲得對 remote-fs.targetBefore 依賴,除非設置了 nofail 掛載選項。在後一種情況下,還會添加一個 Wants 單元。
  • 添加 noautoOptions 可以防止啟動時自動掛載(除非被其它單元觸發)。
  • 如果你要為共享服務器使用域名而不是 IP 地址,則需要添加 nss-lookup.targetAfter 下。這可能會避免測試中沒有問題,但啟動時掛載出錯的情況出現。
/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
提示:為處理網絡出現中斷的情況,可添加 ForceUnmount=true[Mount],該選項使掛載可以被強制卸載。

要使用 mnt-home.mount啟動該單元,然後將其啟用以在系統啟動時進行掛載。

自動掛載[編輯 | 編輯原始碼]

要想自動掛載一個分享,你可以使用下面的自動掛載單元:

/etc/systemd/system/mnt-home.automount
[Unit]
Description=Automount home

[Automount]
Where=/mnt/home

[Install]
WantedBy=multi-user.target

禁用/停止 mnt-home.mount 單元,然後啟用/啟動 mnt-home.automount 以在路徑可用時自動掛載共享。

提示:添加 TimeoutIdleSec 以啟用自動卸載,詳細信息可參考 systemd.automount(5)

使用 autofs 掛載[編輯 | 編輯原始碼]

Using autofs is useful when multiple machines want to connect via NFS; they could both be clients as well as servers. The reason this method is preferable over the earlier one is that if the server is switched off, the client will not throw errors about being unable to find NFS shares. See autofs#NFS network mounts for details.

提示和技巧[編輯 | 編輯原始碼]

啟用 NFSv4 ID 映射[編輯 | 編輯原始碼]

本文或本章節的語言、語法或風格需要改進。參考:幫助:風格

原因:The instructions are too convoluted. Separate sections for client and server configuration would be better than notes like "Enabling/starting nfs-idmapd.service should not be needed on the client" or "Do not confuse the nfsidmap (only for nfs clients) with nfs-idmapd.service".(在Talk:NFS討論)

這篇文章的某些內容需要擴充。

原因: Missing lookup information, static binding examples, etc. (在 Talk:NFS 中討論)
注意:
  • NFSv4 ID 映射無法解決默認 sec=sys 掛載選項導致的所有問題。更多信息請參考 NFS#靜態映射[4]
  • 在客戶端和服務端上需要啟用 NFSv4 ID 映射
  • 另一個選擇是確保用戶 ID 和組 ID(UID 和 GID)在客戶端和服務器上一致。
  • 需要啟用/啟動 nfs-idmapd.service,因為它已被新的 ID 映射器替換:
# dmesg | grep id_resolver
[ 3238.356001] NFS: Registering the id_resolver key type
[ 3238.356009] Key type id_resolver registered
提示:
  • Do not confuse the nfsidmap (only for nfs clients) with nfs-idmapd.service which is used by the NFS server and forks the process rpc.idmapd.
  • Both rpc.idmapd and nfsidmap share also some configurations from idmapd.conf(5).
  • 更多信息請參考 idmapd(8)nfsidmap(8)

NFSv4 協議將客戶端的 UID 和 GID 值表示為 user@domain 形式的字符串.將UID和字符串互相轉換的過程稱為 ID 映射

域名[編輯 | 編輯原始碼]

注意:
  • By default, the domain part of the string is the system's DNS domain name. It can also be specified in /etc/idmapd.conf if the system is multi-homed, or if the system's DNS domain name does not match the name of the system's Kerberos realm.
  • When the domain is not specified in /etc/idmapd.conf the local DNS server will be queried for the _nfsv4idmapdomain text record. If the record exists that will be used as the domain. When the record does not exist, the domain part of the DNS domain will used.

Display the system's effective NFSv4 domain name on stdout.

# nfsidmap -d
domain.tld

Edit to match up the Domain on the server and/or client:

/etc/idmapd.conf
[General]
Domain = guestdomain.tld

靜態映射[編輯 | 編輯原始碼]

提示:
  • 這個映射僅用於客戶端本地映射 uid。如果您創建一個屬於某個在服務器上不被識別的 uid(例如 1005)的文件。該文件會以 uid 1005 的形式存儲在服務器上,但在傳輸過程中不會再顯示正確的 uid。
  • 在與服務器交互(例如列出文件)之後,您可以查看密鑰環中的所有條目。
# nfsidmap -l
7 .id_resolver keys found:
 uid:nobody
 user:1
 uid:bin@domain.tld
 uid:foo@domain.tld
 gid:foo@domain.tld
 uid:remote_user@domain.tld
 uid:root@domain.tld
  • 您可以使用命令 nfsidmap -c 清除密鑰環,但在默認設置中,條目會在 10 分鐘後過期,因此並不需要手動清除。

這些步驟只在服務器和客戶端具有不同的用戶/組名稱時才需要進行。

更改只會在客戶端的配置文件中進行。

/etc/idmapd.conf
[Translation]
# The default is nsswitch and other methods exist.
method = static,nsswitch

[Static]
foo@domain.tld = local_foo
remote_user@domain.tld = user

後備映射[編輯 | 編輯原始碼]

Only in the client configuration. Local user/group name to be used when a mapping cannot be completed:

/etc/idmapd.conf
[Mapping]
Nobody-User = nobody
Nobody-Group = nobody

性能調優[編輯 | 編輯原始碼]

本文內容(或本節內容)已經過時。

原因: Mentions 32-bit and 2.6 Linux kernel... (在Talk: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

It may be necessary to tune the rsize and wsize mount options to meet the requirements of the network configuration.

In recent linux kernels (>2.6.18) the size of I/O operations allowed by the NFS server (default max block size) varies depending on RAM size, with a maximum of 1M (1048576 bytes), the max block size of the server will be used even if nfs clients requires bigger rsize and wsize. See https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/5/html/5.8_technical_notes/known_issues-kernel It is possible to change the default max block size allowed by the server by writing to the /proc/fs/nfsd/max_block_size before starting nfsd. For example, the following command restores the previous default iosize of 32k:

# echo 32768 > /proc/fs/nfsd/max_block_size
注意: This is mainly useful for 32-bit servers when dealing with the large numbers of nfsd threads. Lowering the max_block_size may decrease NFS performance on modern hardware.

To make the change permanent, create a 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)
警告: Using async comes with a risk of possible data loss or corruption if the server crashes or restarts uncleanly.

處理自動掛載[編輯 | 編輯原始碼]

This trick is useful for NFS-shares on a wireless network and/or on a network that may be unreliable. If the NFS host becomes unreachable, the NFS share will be unmounted to hopefully prevent system hangs when using the hard mount option [5].

Make sure that the NFS mount points are correctly indicated in fstab:

/etc/fstab
lithium:/mnt/data           /mnt/data	        nfs noauto 0 0
lithium:/var/cache/pacman   /var/cache/pacman	nfs noauto 0 0
注意:
  • Use hostnames in fstab for this to work, not IP addresses.
  • In order to mount NFS shares with non-root users the users option has to be added.
  • The noauto mount option tells systemd to not automatically mount the shares at boot, otherwise this may cause the boot process to stall.

Create the auto_share script that will be used by cron or systemd/Timers to use ICMP ping to check if the NFS host is reachable:

/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[${#server_notok[@]}]=$SERVER
      # The server could not be reached, unmount the share
      net_umount $MOUNT_POINT
    else
      server_ok[${#server_ok[@]}]=$SERVER
      # The server is up, make sure the share are mounted
      net_mount $MOUNT_POINT
    fi
  fi
done
注意: Test using a TCP probe instead of ICMP ping (default is tcp port 2049 in NFS4) then replace the line:
# Check if the server is reachable
ping -c 1 "${SERVER}" &>/dev/null

with:

# Check if the server is reachable
timeout 1 bash -c ": < /dev/tcp/${SERVER}/2049"
in the auto_share script above.

Make sure the script is executable.

Next check configure the script to run every X, in the examples below this is every minute.

Cron[編輯 | 編輯原始碼]

# crontab -e
* * * * * /usr/local/bin/auto_share

systemd/Timers[編輯 | 編輯原始碼]

/etc/systemd/system/auto_share.timer
[Unit]
Description=Automount NFS shares every minute

[Timer]
OnCalendar=*-*-* *:*:00

[Install]
WantedBy=timers.target
/etc/systemd/system/auto_share.service
[Unit]
Description=Automount NFS shares
After=network.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/auto_share

[Install]
WantedBy=multi-user.target

Finally, enable and start auto_share.timer.

Using a NetworkManager dispatcher[編輯 | 編輯原始碼]

NetworkManager can also be configured to run a script on network status change.

The easiest method for mount shares on network status change is to symlink the auto_share script:

# ln -s /usr/local/bin/auto_share /etc/NetworkManager/dispatcher.d/30-nfs.sh

However, in that particular case unmounting will happen only after the network connection has already been disabled, which is unclean and may result in effects like freezing of KDE Plasma applets.

The following script safely unmounts the NFS shares before the relevant network connection is disabled by listening for the down, pre-down and vpn-pre-down events, make sure the script is executable:

/etc/NetworkManager/dispatcher.d/30-nfs.sh
#!/bin/sh

# 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: network interface name, not used
    # Script parameter $2: dispatched event
    
    case "$2" in
        "up")
            mount -a -t nfs4,nfs 
            ;;
        "down"|"pre-down"|"vpn-pre-down")
            umount -l -a -t nfs4,nfs -f >/dev/null
            ;;
    esac
fi
注意: This script ignores mounts with the noauto option, remove this mount option or use auto to allow the dispatcher to manage these mounts.

/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

TLS 加密[編輯 | 編輯原始碼]

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.

服務端[編輯 | 編輯原始碼]

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.

注意: Using a self-signed certificate that has also been encrypted is currently not supported and will result in a mount failure.

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.

客戶端[編輯 | 編輯原始碼]

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/Troubleshooting 頁面。

更多參考[編輯 | 編輯原始碼]