更新：5 (20171209)

更新：5 (20171210)

• mount -t nfs4 [SERVER IP]:/archlinux /mnt作品。
• ss -ntp | grep 2049客戶端在 systemd 開始之前建立與伺服器的連接。
• NSF4 id mapper 只能與 Kerberos 一起使用？

問題

我正在嘗試設置無盤節點/工作站/系統。作業系統（4.13.12-1-ARCH）安裝在 SERVER 上/srv/archlinux。從GRUB 成功網路引導到 NFSv4後，systemd 開始但在多個階段失敗，例如：

• 無法掛載核心配置文件系統。
• 無法掛載核心調試文件系統。
• 掛載大頁面文件系統失敗
• 無法啟動載入/保存隨機種子。
• 無法掛載 /tmp。
• 無法啟動重建日誌目錄。
• 然後以Not tainted 4.13.12-1-ARCH #1...

或者，

• 無法掛載 POSIX 消息隊列文件系統。
• 無法啟動重新掛載根和核心文件系統。
• 無法掛載 Huge Pages 文件系統。
• 無法掛載核心調試文件系統。
• 無法掛載核心配置文件系統。
• 然後以Not tainted 4.13.12-1-ARCH #1...

我懷疑這些故障是由 NFSv4 或本地網路的錯誤配置引起的。

rpc.idmapd

/etc/idmapd.conf
 [General]
 Verbosity = 7
 Pipefs-Directory = /var/lib/nfs/rpc_pipefs
 Domain = localdomain
 [Mapping]
 Nobody-User = nobody
 Nobody-Group = nobody
 [Translation]
 Method = nnswitch

/etc/exports
(printed using # exportfs -v)
 /srv            <world>(rw,sync,wdelay,hide,no_subtree_check,fsid=0,sec=sys,no_root_squash,no_all_squash)
 /srv/archlinux  <world>(rw,sync,wdelay,hide,no_subtree_check,sec=sys,no_root_squash,no_all_squash)

(Exposed to "world" for debugging purposes)

rpc.idmapd -fvvv在啟動期間單獨執行tty會記錄以下內容：

rpc.idmapd: libnfsidmap: using domain: localdomain
rpc.idmapd: libnfsidmap: Realms list: 'LOCALDOMAIN'
rpc.idmapd: libnfsidmap: processing 'Method' list
rpc.idmapd: libnfsidmap: loaded plugin /usr/lib/libnfsidmap/nsswitch.so for method nsswitch
rpc.idmapd: Expiration time is 600 seconds.
rpc.idmapd: Opened /proc/net/rpc/nfs4.nametoid/channel
rpc.idmapd: Opened /proc/net/rpc/nfs4.idtoname/channel
rpc.idmapd: nfsdcb: authbuf=* authtype=user
rpc.idmapd: nfs4_uid_to_name: calling nsswitch->uid_to_name
rpc.idmapd: nfs4_uid_to_name: nsswitch->uid_to_name returned 0
rpc.idmapd: nfs4_uid_to_name: final return value is 0
rpc.idmapd: Server : (user) id "0" -> name "root@localdomain"

如果exportfs sec=sys，則繼續如下：

rpc.idmapd: nfsdch: authbuf=* authtype=user
rpc.idmapd: nfs4_name_to_uid: calling nsswitch->name_to_uid
rpc.idmapd: nss_getpwnam: name '0' domain 'localdomain': resulting localname '(null)'
rpc.idmapd: nss_getpwnam: name '0' does not map into domain 'localdomain'
rpc.idmapd: nfs4_name_to_uid: nsswitch->name_to_uid returned -22
rpc.idmapd: nfs4_name_to_uid: final return value is -22
rpc.idmapd: Server : (user) name "0" -> id "99"
(stops here)

+(20171209) 確保/etc/hostnameCLIENT 的 設置為client2(duh) 後，如果exportfs sec=none 或 sec=sys，則繼續如下：

rpc.idmapd: nfsdch: authbuf=* authtype=group
rpc.idmapd: nfs4_gid_to_name: calling nsswitch->gid_to_name
rpc.idmapd: nfs4_gid_to_name: nsswitch->gid_to_name returned 0
rpc.idmapd: nfs4_gid_to_name: final return value is 0
rpc.idmapd: Server : (group) id "190" -> name "systemd-journal@localdomain"
rpc.idmapd: nfsdch: authbuf=* authtype=user
rpc.idmapd: nfs4_name_to_uid: calling nsswitch->name_to_uid
rpc.idmapd: nss_getpwnam: name '0' domain 'localdomain': resulting localname '(null)'
rpc.idmapd: nss_getpwnam: name '0' does not map into domain 'localdomain'
rpc.idmapd: nfs4_name_to_uid: nsswitch->name_to_uid returned -22
rpc.idmapd: nfs4_name_to_uid: final return value is -22
rpc.idmapd: Server : (user) name "0" -> id "99"
(stops here)

如果我改為將方法從更改nsswitch為static（NFS 中的 UID 映射）

/etc/idmapd.conf
 ...
 [Translation]
 Method = static
 [Static]
 root@localdomain = root

在啟動期間rpc.idmapd -fvvv單獨tty記錄以下內容：

rpc.idmapd: libnfsidmap: using domain: localdomain
rpc.idmapd: libnfsidmap: Realms list: 'LOCALDOMAIN'
rpc.idmapd: libnfsidmap: processing 'Method' list
rpc.idmapd: static_getpwnam: name 'root@localdomain' mapped to 'root'
rpc.idmapd: static_getpwnam: group 'root@localdomain' mapped to ' root'
rpc.idmapd: libnfsidmap: loaded plugin /usr/lib/libnfsidmap/static.so for method static
rpc.idmapd: Expiration time is 600 seconds.
rpc.idmapd: Opened /proc/net/rpc/nfs4.nametoid/channel
rpc.idmapd: Opened /proc/net/rpc/nfs4.idtoname/channel
rpc.idmapd: nfsdcb: authbuf=* authtype=user
rpc.idmapd: nfs4_uid_to_name: calling static->uid_to_name
rpc.idmapd: nfs4_uid_to_name: static->uid_to_name returned 0
rpc.idmapd: nfs4_uid_to_name: final return value is 0
rpc.idmapd: Server : (user) id "0" -> name "root@localdomain"

如果exportfs sec=sys，則繼續如下：

rpc.idmapd: nfsdch: authbuf=* authtype=user
rpc.idmapd: nfs4_name_to_uid: calling static->name_to_uid
rpc.idmapd: nfs4_name_to_uid: static->name_to_uid returned -2
rpc.idmapd: nfs4_name_to_uid: final return value is -2
rpc.idmapd: Server : (user) name "0" -> id "99"
(stops here)

如果exportfs sec=none，則繼續如下：

rpc.idmapd: nfsdch: authbuf=* authtype=group
rpc.idmapd: nfs4_gid_to_name: calling static->gid_to_name
rpc.idmapd: nfs4_gid_to_name: static->gid_to_name returned -2
rpc.idmapd: nfs4_gid_to_name: final return value is -2
rpc.idmapd: Server : (group) id "190" -> name "nobody"
rpc.idmapd: nfsdch: authbuf=* authtype=user
rpc.idmapd: nfs4_name_to_uid: calling static->name_to_uid
rpc.idmapd: nfs4_name_to_uid: static->name_to_uid returned -2
rpc.idmapd: nfs4_name_to_uid: final return value is -2
rpc.idmapd: Server : (user) name "0" -> id "99"
(stops here)

使用者 ID 映射的類似問題：

• NFSv4 使用者映射
• NFS 使用者映射
• 將本地使用者的 UID 和 GID 映射到掛載的 NFS 共享
• 還有更多……通常與從 NFSv3 到 NFSv4 的切換有關，很少與網路啟動有關。

故障排除

• 沒有防火牆
• 沒有 Kerberos、LDAP 等。
• 沒有 SELinux
• 使用者root同時存在於 SERVER 和 CLIENT 上，具有相同的密碼。

伺服器

我可以在伺服器上辨識的 NFSv4 的所有其他相關配置文件。

/etc/nsswitch.conf
 passwd: compat mymachines systemd
 group: compat mymachines systemd
 shadow: compat
 publickey: files
 hosts: files mymachines resolve [!UNAVAIL=return] dns myhostname
 networks: files
 protocols: files
 services: files
 ethers: files
 rpc: files
 netgroup: files

/etc/nfs.conf
 (all settings commented out)
/etc/conf.d/nfs-common.conf
 (all settings commented out)

網路配置

• 如何在 GNU/Linux 上設置域名？
• Archlinux Wiki 網路配置：設置主機名
• Archlinux Wiki 網路配置：本地網路主機名解析

SERVER 主機名是server並且有 3 個網路設備（nd

$$ 1-3 $$）。網關default via 192.168.0.1 nd1。

/etc/hosts
 127.0.0.1      localhost.localdomain  localhost
 ::1            ip6.localhost          localhost
 192.168.0.101  nd1.localdomain        server servernd1
 192.168.1.101  nd2.localdomain        server servernd2
 192.168.2.101  nd3.localdomain        server servernd2
 192.168.1.102  client1.localdomain    client1
 192.168.2.102  client2.localdomain    client2

/etc/resolveconf.conf
 name_servers=192.168.0.1

# hostname -f
# nd1.localdomain

# hostname -i
192.168.0.101 192.168.1.101 192.168.2.101

# getent hosts IP -> the corresponding line in /etc/hosts
# getent ahosts HOSTNAME -> the corresponding line in /etc/hosts

# ping -c 3 server.localdomain -> 0% packet loss

# id -u root -> 0
# id -un 0 -> root

Display the system's effective NFSv4 domain name on stdout.
# nfsidmap -d -> localdomain

Display on stdout all keys currently in the keyring used to cache ID mapping results. These keys are visible only to the superuser.
# nfsidmap -l -> nfsidmap: '.id_resolver' keyring was not found.

客戶

/etc/hostname +(20171209)
 client2
/etc/hosts
 (exactly the same as the hosts file on the server)
/etc/resolveconf.conf
 name_servers=192.168.0.1
/etc/idmapd.conf
 (exactly the same as the idmapd.conf file on the server)
/etc/fstab
 # sys=sec or sys=none to correspond to server export settings. 
 /dev/nfs  /  nfs  rw,hard,rsize=9151,sec=sys,clientaddr=192.168.2.102  0  0
 devtmpfs  /dev   devtmpfs  defaults
 proc      /proc  proc      defaults
 none      /run   tmpfs     defaults
 sys       /sys   sysfs     defaults
 run       /run   tmpfs     defaults
 tmp       /tmp   tmpfs     defaults

是通過fstab使用findmnt -A.

net_nfs4

• +(20171210) SERVER 和 CLIENT 上的 NFS 版本cat /proc/fs/nfsd/versions -> -2 +3 +4 +4.1 +4.2
• 在 SERVER 和 CLIENTcat /sys/module/nfsd/parameters/nfs4_disable_idmapping -> N上。
• 在伺服器上echo "options nfsd nfs4_disable_idmapping=0" > /etc/modprobe.d/nfsd.conf。
• 在 CLIENT/sys/module/nfs/parameters/nfs4_disable_idmapping上不存在，並且不確定如何手動創建它，因為它/sys是只讀的。
• +(20171210) 在客戶上 echo "options nfs nfs4_disable_idmapping=0" > /etc/modprobe.d/nfs.conf。

客戶端 IP 是192.168.2.102/24。CLIENT 網路設備連接到 SERVER nd2 192.168.2.101/24（主機名：servernd2）。

開機時的網路資訊：

:: running early hook [udev]
starting version 235
:: running hook [udev]
:: Triggering uevents...
:: running hook [net_nfs4]
IP-Config: eth0 hardware address [CLIENT NETWORK DEVICE MAC] mtu 1500 DHCP
hostname client2 IP-Config: eth0 guessed broadcast address 192.168.2.255
IP-Config: eth0 complete (from 192.168.0.101):
address: 192.168.2.102     broadcast: 192.168.2.255     netmask: 255.255.255.0
gateway: 192.168.2.101     dns0     : 192.168.0.1       dns1   : 0.0.0.0
host   : client2
domain : localdomain
rootserver: 192.168.0.101 rootpath: /srv/archlinux
filename  : /netboot/grub/i386-pc/core.0
NFS-Mount: 192.168.2.101:/archlinux
Waiting 10 seconds for device /dev/nfs ...
(systemd takes over from here)

為什麼會出現 NSFv4 錯誤？

Server : (group) id "190" -> name "nobody"

使用 NFSv4，情況發生了變化：使用者由使用者名映射，使用者名和使用者 ID 之間的映射由一個稱為“ID 映射守護程序”(idmapd) 的程序處理。特別是 NFSv4 客戶端和伺服器應該使用相同的域以使映射正常工作，否則請求將被映射到匿名使用者/組。–試用 NFSv4（在 Linux 和 Solaris 上） – 2012 年 3 月 15 日 - 13:03 / bronto

---

在理想情況下，請求客戶端的使用者和組將確定返回數據的權限。我們不是生活在一個理想的世界裡。兩個現實世界的問題介入：

1. 您可能不信任對伺服器文件具有 root 訪問權限的客戶端的 root 使用者。
2. 客戶端和伺服器上相同的使用者名可能具有不同的數字 ID

問題 1 在概念上很簡單。John Q. Programmer 獲得了一台測試機器，他對其具有 root 訪問權限。這絕不意味著 John Q. Programmer 應該能夠更改伺服器上的根擁有的文件。因此 NFS 提供了根壓縮，該功能將 uid 0（根）映射到匿名 (nfsnobody) uid，預設為 -2（16 位數字為 65534）。– NFS: Overview and Gotchas – 版權所有 (C) 2003 by Steve Litt

+(20171209)rpc.idmapd: nss_getpwnam: name '0' domain 'localdomain': resulting localname '(null)'

根據Steve Dickson 在對 Red Hat Bugzilla 的評論 (2011-08-12 16:01:55 EDT) 中的評論 – 錯誤 715430 報告

這

$$ error $$聲明解釋了問題。本地機器上的 DNS 未設置（或返回 NULL），並且 /etc/idmapd.conf 中的 Domain= 變數未設置。

nss_getpwnam: name '0' does not map into domain

在 Debian 郵件列表中，Jonas Meurer 和 Christian Seiler (20150722) 之間有關“Kerberos-secured NFSv4”的電子郵件通信中詳細解釋了該錯誤。我對討論的總結：

當 NFS 客戶端發送nss_getpwnam: name '8' domain 'freesources.org': resulting localname '(null)'

NFS 客戶端在某些情況下只發送轉換為字元串的 uid，而不是正確轉換的 NFS 使用者名，然後伺服器會拒絕該使用者名。

客戶應該發送nss_getpwnam: name 'mail@freesources.org' domain 'freesources.org': resulting localname 'mail'

在這裡，您可以看到 NFS 客戶端傳輸的所有者名稱是“mail@freesources.org”（而不僅僅是“8”），所以它確實包含一個 @；nss_getpwname 可以看到域名匹配，然後將其剝離，產生一個使用者名“mail”，它在 /etc/passwd 中查找，返回使用者 id（在本例中為 8，因為它在客戶端和伺服器），伺服器非常高興。

那麼為什麼客戶端會發送錯誤的使用者名呢？…每隔一段時間，idmapping 就會失敗，所以核心只會發送一個數字。但是這個數字會導致 chown 命令失敗，因為伺服器不會把它翻譯回來。

簡短的回答：我不知道。

更長的答案：…

如果我正確理解較長的答案，則可能會出現問題，因為 NFS 客戶端依賴於“核心的密鑰記憶體”。對於 NFS 伺服器，這永遠不會成為問題，因為從未使用過“核心的密鑰記憶體”。

儘管如此，

由於您只是通過 /etc/passwd 使用正常 nsswitch，因此 nss_getpwnam在您的情況下永遠不會失敗，除非您同時使用 /etc/passwd 做一些奇怪的事情。

答案還提到了 idmapd 的替代方法；nfsidmap，雖然閱讀man我不太明白它將如何取代idmapd.

+(20171209) nss_getpwnam: name 'root@domain.com' does not map into domain 'localdomain'

我似乎沒有出現此錯誤消息，但是我包含了來自SUSE 支持知識庫的答案 - 10-DEC-13 修改日期：12-OCT-17 -因為原因描述和建議的補救措施與其他發現的討論形成鮮明對比。

NFSv4 處理使用者身份的方式與 NFSv3 不同。在 v3 中，nfs 客戶端只需在 chown（和其他請求）中傳遞一個 UID 號，nfs 伺服器會接受它（即使 nfs 伺服器不知道具有該 UID 號的帳戶）。但是，v4 旨在以@ 的形式傳遞身份。為了正常執行，通常需要 idmapd（id 映射守護程序）在客戶端和伺服器上處於活動狀態，並且每個都將自己視為同一 id 映射域的一部分。

像上面記錄的那樣，chown 失敗或 idmapd 錯誤通常是以下任一原因的結果：

1. 客戶端知道使用者名但伺服器不知道使用者名，或者
2. idmapd 域名在客戶端的設置與在伺服器上的設置不同。

因此，可以通過確保 nfs 伺服器和客戶端配置有相同的 idmapd 域名 (/etc/idmapd.conf) 並且都知道相關的使用者名/帳戶來解決此問題。

但是，確保雙方具有相同的使用者帳戶知識通常並不方便，尤其是在 nfs 伺服器是文件管理器的情況下。NFS 社區已經認識到，NFSv4 的這個 idmapd 特性通常更麻煩，因此值得採取一些步驟和修改，以使 NFSv3 行為即使在 NFSv4 下也能正常工作。

建議的補救措施是禁用 idmapd。

nfs.nfs4_disable_idmapping=1

+(20171209) Wireshark

分析 Wireshark 日誌，它相當廣泛，但開頭類似：

[IP CLIENT] -> [IP SERVER] NFS 226 V4 Call ACCESS FH: [HEX VALUE], [Check: RD LU MD XT DL]
[IP SERVER] -> [IP CLIENT] NFS 238 V4 Reply (Call In 34) ACCESS, [Allowed: RD LU MD XT DL]
[IP CLIENT] -> [IP SERVER] NFS 246 V4 Call LOOKUP DH: [HEX VALUE]/archlinux

其中, , , , , , , , , , ,可以[A HEX VALUE]/[PATH]辨識出 類似的模式。/sbin``/usr``/bin``/init``/lib``/systemd``/dev``/proc``/sys``/run``/``/lib64

當客戶端請求/Id-linux-x86-64.so.2第一個錯誤開始出現：

[IP CLIENT] -> [IP SERVER] NFS 342 V4 Call OPEN DH: [HEX VALUE]/Id-linux-x86-64.so.2
[SERVER IP] -> [CLIENT IP] NFS 166 V4 Reply (Call In 124) OPEN Status: NFS4ERR_SYMLINK

該模式或多或少會重複出現更頻繁的錯誤，例如LOOKUP Status;，OPEN Status:報告NFS4ERR_NOENT。

有趣的是，在日誌的最末尾，首先且僅引用了使用者權限，

[SERVER IP] -> [CLIENT IP] NFS 182 V4 Reply (Call In 9562) SETATTR Status: NFS4ERR_BADOWNER

RFC

根據

• RFC7530（網路文件系統 (NFS) 第 4 版協議，201503，建議標準） ——由RFC7931更新
• RFC5661（網路文件系統 (NFS) 版本 4 次要版本 1 協議，201001，建議標準） ——由RFC8178更新
• RFC7862 (Network File System (NFS) Version 4 Minor Version 2 Protocol, 201001, PROPOSED STANDARD) – 由RFC8178更新– 指回$$ RFC5661 $$.

NFS4ERR_BADOWNER（錯誤程式碼 10039）

當無法將 ACL 屬性值中的 owner 或 owner_group 屬性值或 ACE 的 who 欄位轉換為本地表示時，將返回此錯誤。

規範在第 5.9 節中討論。解釋 owner 和 owner_group，但我不確定引用什麼是相關的。

NFS4ERR_SYMLINK（錯誤程式碼 10029）

噹噹前操作不允許符號連結作為目標時，目前文件句柄指定一個符號連結。

NFS4ERR_NOENT（錯誤程式碼 2）

這表明沒有這樣的文件或目錄。指定名稱引用的文件系統對像不存在。

然而，這個錯誤是可以預料的……

假定目前文件句柄引用一個命名屬性目錄的正常目錄。LOOKUPP 將其父目錄的文件句柄分配為目前文件句柄。如果沒有父目錄，則必須返回 NFS4ERR_NOENT 錯誤。因此，噹噹前文件句柄位於伺服器文件樹的根或頂部時，伺服器將返回 NFS4ERR_NOENT。

+(20171210)mount -t nfs4 [SERVER IP]:/archlinux /mnt

在客戶端電腦上，使用 Archlinux “LiveUSB”，我能夠掛載網路驅動器，通過 SERVER 網際網路連接下載最新核心（4.14-4-1-ARCH），然後在[SERVER IP]/archlinux.

在安裝期間rpc.idmapd -fvvv表明使用者名映射成功，例如，

rpc.idmapd: Server : (user) id "0" -> name "root@localdomain"
rpc.idmapd: Server : (group) id "99" -> name "nobody@localdomain"
... -> name "tty@localdomain"
... -> name "systemd-journal-upload@localdomain"
... -> name rpc@localdomain
... -> name systemd-journal@localdomain
... -> name utmp@localdomain

結果genfstab也不同：

[SERVER IP]:/archlinux  /  nfs4 rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,times=600,retrans=2,sec=sys,clientaddr=[CLIENT IP],local_lock=none,addr=[SERVER IP]  0 0

儘管如此，重新啟動systemd後再次失敗，並出現與文章開頭所述相同的失敗。

+(20171210) 伺服器上的遠端目錄是否掛載到/new_root？

該mkinitcpio腳本使用該變數mount_handler來承載分配的“掛載函式”，在這種情況下，“根路徑”在稍後階段nfs_mount_handler()傳遞給該函式；.$1``/new_root

我正在嘗試驗證客戶端是否[SERVER IP]:/archlinux已將/new_root. 在伺服器上，我只能觀察到客戶端已經建立了連接，但不能觀察到目錄是否已掛載以及掛載到哪裡？

showmount -a server -> All mount points on server: (empty)

ss -ntp | grep 2049 ->
ESTAB  0    0   192.168.2.101:2049  192.168.2.102:809 (random port)

+(20171210) NFS4sec=sys和 id 映射器不兼容？

閱讀文件，它看起來像 sec=sys，並且 id 映射器可用於將 uid/gid 正確映射到客戶端和伺服器在 /etc/passwd 和 /etc/group 中具有不同映射的名稱。這根本不是真的。

那是因為 sec=sys id 映射器不會在 nfs 協議的身份驗證部分發揮作用，只有文件屬性部分。使用 sec=sys 身份驗證，nfs 只需傳遞伺服器直接使用的客戶端 uid/gid。因此，如果客戶端和伺服器的 uid 和 gid 不對齊，權限檢查將被搞砸。更令人困惑的是，當客戶端創建一個新文件時，它使用的是身份驗證憑據，因此該文件是在伺服器上使用客戶端的 uid/gid 創建的。之後，nfs 使用 idmap 獲取文件屬性，因此 uid/gid（最初來自客戶端）在伺服器上被映射，您最終會看到客戶端 uid/gid 的伺服器名稱。報關！另一方面，如果文件最初是在伺服器上創建的，您將在客戶端看到正確的名稱，即使 uid/gid 不同。但是權限檢查仍然會被破壞。–kimmie – 發表於：2013 年 2 月 20 日，星期三 3:14 am 發表主題： – 強調原文

來自核心參數的核心文件

nfs.nfs4_disable_idmapping=

$$ NFSv4 $$當設置為預設值“1”時，此選項確保 RPC 級別身份驗證方案和 NFS 級別操作都同意使用數字 uids/gids，如果掛載使用“sec=sys”安全風格。實際上，它禁用了 idmapping，這可以使從傳統 NFSv2/v3 系統遷移到 NFSv4 更容易。不支持這種操作模式的伺服器將被客戶端自動檢測到，它會回退到使用 idmapper。要關閉此行為，請將值設置為“0”。

nfsd.nfs4_disable_idmapping=

$$ NFSv4 $$當設置為預設值“1”時，NFSv4 伺服器將只返回數字 uid 和 gid 給使用 auth_sys 的客戶端，並接受來自此類客戶端的數字 uid 和 gid。這旨在簡化從 NFSv2/v3 的遷移。

nfs.nfs4_disable_idmapping=1和nfsd.nfs4_disable_idmapping=1

nfsd.nfs4_disable_idmapping=1在 SERVER和CLIENT 上禁用 id 映射器nfs.nfs4_disable_idmapping=1會導致 systemd 啟動到使用者登錄提示，只有 1 個錯誤：

• 無法啟動 Remount Root 和 Kernel File System，但是通過添加hooks解決modconf了；mkinitcpio一起block keyboard嘗試處理另一個明顯的問題：
• 筆記本鍵盤不能用…

rpc.idmapd -fvvv沒有輸出任何消息。

我可以使用外部 USB 鍵盤以 root 身份登錄，讀取和創建文件。我沒有進行任何廣泛的測試，所以這個解決方案仍然可能存在問題。

nfs.nfs4_disable_idmapping=0和nfsd.nfs4_disable_idmapping=0

似乎echo "options nfs nfs4_disable_idmapping=0" >> /etc/modprobe.d/nfs.conf（或cat /sys/module/nfsd/parameters/nfs4_disable_idmapping -> N）對 CLIENT 沒有任何影響。

CLIENT id 映射器被禁用，直到我nfs.nfs4_disable_idmapping=0在引導期間將參數顯式傳遞給核心 (GRUB)。

rpc.idmapd -fvvv沒有輸出任何投訴。另一方面，在建立第一個……之後它沒有列印出任何其他東西rpc.idmapd: Server : (user) id "0" -> name "root@localdomain"……

然而，Wireshark 日誌不再記錄NFS4ERR_BADOWNER.

儘管如此，所有 systemd 啟動失敗仍然存在……

• 無法掛載 POSIX 消息隊列文件系統。
• 無法啟動重新掛載根和核心文件系統。
• 無法掛載 Huge Pages 文件系統。
• 無法掛載核心調試文件系統。
• 無法掛載核心配置文件系統。
• 然後以 Not tainted 4.13.12-1-ARCH #1 結束…

結論

nfs.nfs4_disable_idmapping=0和nfsd.nfs4_disable_idmapping=0

除了設置 Kerberos 和故障排除之外，我不確定接下來要嘗試什麼。rpc.idmapd似乎仍然無法映射正確的權限，但不再rpc.idmapd -fvvv輸出任何錯誤……？該怎麼辦？引導錯誤可能是由其他原因引起的……我不知道……

nfs.nfs4_disable_idmapping=1和nfsd.nfs4_disable_idmapping=1

雖然可行，但方法似乎是錯誤的；我沒有遷移，我應該能夠使用rpc.idmapd. 現在它必須這樣做；它可能會在未來回來咬我……

引用自：https://unix.stackexchange.com/questions/409768