☰

質問

tag-icon • tag-icon arch-linux systemd nfs netboot nfsv4
質問

アップデート：5（20171209）

アップデート：5（20171210）

  • mount -t nfs4 [SERVER IP]:/archlinux /mnt働く
  • ss -ntp | grep 2049クライアントは systemd が起動する前にサーバーへの接続を確立します。
  • NSF4 IDマッパーはKerberosでのみ機能しますか？

質問

ディスクレスノード/ワークステーション/システムを設定しようとしています。オペレーティングシステム（4.13.12-1-ARCH）がサーバーにインストールされています/srv/archlinux。 〜の後GRUBネットワークからNFSv4で正常に起動しました。、systemdが起動しますが、いくつかの手順で失敗します。例:

  • カーネルプロファイルシステムをマウントできません。
  • カーネルデバッグファイルシステムをマウントできません。
  • ラージページファイルシステムのマウントに失敗しました。
  • ランダムシードのロード/保存を開始できません。
  • /tmp をマウントできません。
  • ジャーナル・カタログの再構築を開始できません。
  • 次に終わるNot tainted 4.13.12-1-ARCH #1...

または、

  • POSIXメッセージキューファイルシステムをマウントできません。
  • ルートおよびカーネルファイルシステムを再マウントして起動することはできません。
  • hugepageファイルシステムをマウントできません。
  • カーネルデバッグファイルシステムをマウントできません。
  • カーネルプロファイルシステムをマウントできません。
  • 次に終わる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)

/etc/hostname+（20171209）クライアントが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 -fvvvtty以下は、起動中に別々に記録されます。

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マッピングに関する同様の質問：

トラブルシューティング

  • ファイアウォールなし
  • Kerberos、LDAPなどはありません。
  • SELinuxなし
  • このユーザーはrootSERVERと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)

ネットワーク構成

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）サーバーとクライアントのNFSバージョンcat /proc/fs/nfsd/versions -> -2 +3 +4 +4.1 +4.2
  • サーバーとクライアントでcat /sys/module/nfsd/parameters/nfs4_disable_idmapping -> N。
  • サーバーからecho "options nfsd nfs4_disable_idmapping=0" > /etc/modprobe.d/nfsd.conf。
  • クライアントにはファイルが/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 / ブロント

理想的な世界では、要求クライアントのユーザーとグループが返されたデータに対する権限を決定します。私たちは理想的な世界に住んでいません。 2つの実際の問題が介入されます。

  1. サーバーファイルへのrootアクセス権を持つクライアントrootユーザーを信頼できない可能性があります。
  2. クライアントとサーバーの同じユーザー名が異なる数値 ID を持つことができます。

質問1は概念的に簡単です。 John Q.プログラマーは、rootアクセス権を持つテストシステムを入手しました。これは、John Q. Programmerがサーバーでルートが所有するファイルを変更できることを意味するわけではありません。したがって、NFSはuid 0（root）を匿名（nfsnobody）uidにマッピングするルート圧縮を提供します。このuidのデフォルト値は-2（16ビット数で65534）です。 -NFS: 概要と罠 - Copyright (C) 2003 by Steve Litt

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

~によるとRed Hat Bugzillaに関するコメントのSteve Dickson - バグ715430レポート（2011-08-12 16:01:55 EDT）

[error] 文は問題を説明します。ローカルコンピュータのDNSが設定されていないか、NULLが返され、/etc/idmapd.confのDomain =変数が設定されていません。

nss_getpwnam: name '0' does not map into domain

Debian メーリングリストには、「Kerberos Secure NFSv4」に関するJonas MeurerとChristian Seilerの間の電子メール通信（20150722）エラーについて詳しく説明します。私の議論の概要：

NFSクライアントが送信するときnss_getpwnam: name '8' domain 'freesources.org': resulting localname '(null)'

場合によっては、NFSクライアントは正しく変換されたNFSユーザー名を送信するのではなく、文字列に変換されたuidのみを送信することがあります。これはサーバーによって拒否されます。

クライアントが送信する必要があることnss_getpwnam: name '[email protected]' domain 'freesources.org': resulting localname 'mail'

ここでは、NFSクライアント転送の所有者名が「[Eメール保護]'('8'ではない)なので、@が含まれます. nss_getpwnameは、ドメイン名が一致することを確認し、それを削除して/ etc / passwdで見つけて、ユーザー名 'mail'を取得します。 ID（この場合、クライアントとサーバーは同じであるため8）とサーバーはこれに満足しています。

それでは、クライアントが間違ったユーザー名を送信するのはなぜですか？ ...時にはidmappingが失敗するため、カーネルは数字のみを送信します。ただし、この数はサーバーがそれを再変換しないため、chownコマンドが失敗する原因となります。

短い答え：わかりません。

より長い答え：…

より長い答えを正しく理解すると、NFS クライアントが「カーネルのキーキャッシュ」に依存するため、問題が発生する可能性があります。 「カーネルキーキャッシュ」が使用されていないため、これはNFSサーバーでは問題になりません。

それにもかかわらず、

/etc/passwdを介して通常のnsswitchのみを使用しているので、nss_getpwnamはいいえ/etc/passwdに奇妙なことをしないと失敗します。

回答にはidmapdの代替も記載されていますが、それがどのように置き換えられるかnfsidmapはmanよくわかりませんidmapd。

+(20171209)nss_getpwnam: name '[email protected]' does not map into domain 'localdomain'

このエラーメッセージは私には発生しないようですが、次の答えが含まれています。SUSEサポート技術情報 - 2013年12月10日最終修正日：2017年10月12日 -これは、原因の説明と提案された解決策が他の結果の議論とは明らかに対照的であるためです。

NFSv4 は、NFSv3 とは異なる方法でユーザー ID を処理します。 v3では、nfsクライアントはchown（およびその他の要求）からUID番号を渡すだけで、nfsサーバーはその値を受け入れます（nfsサーバーがそのUID番号を持つアカウントを知らない場合でも同じです）。ただし、v4は@形式でIDを渡すように設計されています。正しい動作を実現するには、通常、クライアントとサーバーの両方でidmapd（idマッピングデーモン）を有効にし、各サーバーが自分自身を同じIDマッピングドメインの一部として表示できるようにする必要があります。

上記と同様の Chown エラーまたは idmapd エラーは、通常、次のために発生します。

  1. ユーザー名はクライアントには知られていますが、サーバーには不明です。
  2. idmapd ドメイン名は、クライアントとサーバーで異なって設定されます。

したがって、この問題は、nfsサーバーとクライアントが同じidmapdドメイン名（/etc/idmapd.conf）で構成され、両方が関連するユーザー名/アカウントを知っていることを確認することで解決できます。

ただし、両当事者がユーザーアカウントについて同じ知識を持っていることを確認することはしばしば不便です。 NFSコミュニティは、NFSv4のidmapd機能がより問題になることが多いことを認識しました。したがって、NFSv3の動作がNFSv4でも動作できるようにするには、いくつかの手順と修正を実行する必要があります。

推奨される回避策は、idmapdを無効にすることです。

nfs.nfs4_disable_idmapping=1

+(20171209) ワイヤーシャーク

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

~によると

NFS4ERR_BADOWNER（エラーコード10039）

このエラーは、ACL属性値のOwner属性またはOwner_group属性値、またはACEのwhoフィールドをローカル表現に変換できない場合に返されます。

仕様はセクション 5.9 で議論される。所有者と所有者グループの説明しかし、これについて何を引用すべきかわかりません。

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マッパーは互換性がありませんか？

docoを読むとsec = sysのように見えます。idマッパーを使用すると、クライアントとサーバーがuet / 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分投稿タイトル：-- 元の強調

答え1

~からカーネルパラメータのカーネルドキュメント

nfs.nfs4_disable_idmapping=

[NFSv4]デフォルトの「1」に設定されている場合、このオプションは、マウントが「sec = sys」セキュリティスタイルを使用している場合、RPCレベルの認証方式とNFSレベルの操作の両方が数値uids / gidの使用に同意することを保証します。実際にidmappingを無効にすることで、古いNFSv2 / v3システムからNFSv4に簡単に移行できます。クライアントはこの作業モードをサポートしていないサーバーを自動的に検出し、idmapperを使用するように置き換えます。この動作をオフにするには、値を「0」に設定します。

nfsd.nfs4_disable_idmapping=

[NFSv4] デフォルト値が '1' に設定されている場合、NFSv4 サーバーは auth_sys を使用するクライアントに数字 uid と gid だけを返し、そのクライアントから数字 uid と gid を受け入れます。その目的は、NFSv2/v3 からの移行を簡素化することです。

nfs.nfs4_disable_idmapping=1そしてnfsd.nfs4_disable_idmapping=1

サーバーとクライアントの両方でIDマッパーを無効にすると、systemdはユーザーログインプロンプトで起動し、nfsd.nfs4_disable_idmapping=11つのエラーしか発生しません。nfs.nfs4_disable_idmapping=1

  • ルートファイルとカーネルファイルシステムを再マウントして起動することはできませんが、フックを追加するとこの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。

それでも、すべてのシステム起動エラーが続きます...

  • POSIXメッセージキューファイルシステムをマウントできません。
  • ルートおよびカーネルファイルシステムを再マウントして起動することはできません。
  • hugepageファイルシステムをマウントできません。
  • カーネルデバッグファイルシステムをマウントできません。
  • カーネルプロファイルシステムをマウントできません。
  • その後、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。今しなければなりません。後で再び問題が発生する可能性があります。

関連情報