最近トラブったNFSに関するまとめ。解決はしたけど、根本の部分は検証不十分でまだ不明な部分有り。検証でき次第追加予定。
2021/6/16、6/28 追記
https://access.redhat.com/solutions/5532441
nfsv4(v3でも起こるかも)+rhel8によるサーバ自動再起動バグを踏んだ可能性有
起動kernelのversionを変更することで一旦は改善。RedHatの調査待ち
## from RedHat 不具合が疑われる箇所は、sunrpc の応答を受信する処理にあるため、NFSv3 であったとしても、当該不具合による問題が生じる可能性がございます。しかしながら、実際に NFSv3 で同様のカーネルパニックが生じたといった報告は 見受けられません。
どのkernelでも起こりうる可能性がある不具合とのことだが、下記の要領でkernelを変更することで一旦収まった
>>現行kernel
4.18.0-305.3.1.el8_4.x86_64
>>変更kernel
4.18.0-305.el8.x86_64
>>変更、再起動、確認
# grubby --set-default /boot/vmlinuz-4.18.0-305.el8.x86_64
# reboot
# uname -a
事象1:ファイルロックがかかり読み込めない part1
OS:centOS7
NFS:v3
参考URL
– https://hogem.hatenablog.com/entry/20110116/1295707887
– https://hogem.hatenablog.com/entry/2015/07/09/230000
結論
うまいぼう先輩のブログにも記載がありますが、rpcbindが抜けてたorz
事象2:ファイルロックがかかり読み込めない part2
OS:RHEL8
NFS:v3
firewalld:rpcbind許可済
以下の参考URLをもとに動作確認
– https://qiita.com/hana_shin/items/410f8e021bf58ce9632b
# touch /nfs/locktest
# echo 12345 > /nfs/file
### terminal1で開く
# flock -x /nfs/locktest vi /nfs/file
### terminal2で開く
# flock -x /nfs/locktest vi /nfs/file
オプションを「-x」にしているので、terminal1を閉じない限りterminal2は開けないが、1を閉じても2が開けない状態で待ちが発生していることを確認。※ただ毎回発生するわけではなく開けるときもあった。
nfsをv3からv4に変更し、そもそもrpcbindを使わないようにし事象改善。
参考
– https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/8/html/deploying_different_types_of_servers/exporting-nfs-shares_deploying-different-types-of-servers
### fstab変更前
# cat /etc/fstab
nfs-sv:/nfs /nfs nfs intr,vers=3,noatime,rsize=32768,wsize=32768 0 0
### マウント内容変更前
# nfsstat -m
/nfs from nfs-sv:/nfs
Flags: rw,noatime,vers=3,rsize=32768,wsize=32768,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=10.0.0.1,mountvers=3,mountport=635,mountproto=udp,local_lock=none,addr=10.0.0.1
### fstab変更後(nfsv4がデフォルトなのでv3指定を削除)
# cat /etc/fstab
nfs-sv:/nfs /nfs nfs intr,noatime,rsize=32768,wsize=32768 0 0
### マウント内容変更前
# nfsstat -m
/nfs from nfs-sv:/nfs
Flags: rw,noatime,vers=4.1,rsize=32768,wsize=32768,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.0.0.100,local_lock=none,addr=10.0.0.1
予想だけでいうと、firewalldではrpcbindの許可がきちんとできていなくて、もう少しやることがあったのではないかと想定中。試験したいけど時間がない。。。このブログ書く時間はあるけどね。ハハハ
おまけ:事象2解消後、NFS内のroot権限ファイルがnobody
詳細な解説は以下を参照(RHEL公式は404で残念)
– https://blog.osakana.net/archives/10372
– https://qiita.com/zkangaroo/items/17e3813ccb6ffaa38a28
– https://docs.microsoft.com/ja-jp/azure/azure-netapp-files/azure-netapp-files-configure-nfsv41-domain
下記対応で治った。
※Domainはクライアントとサーバで共通とあるが、netappの方わからないので、一つ目の方の記事と同じものを入れて見た
### 対応前
# ls -l /nfs/
drwxr-xr-x 4 nobody nobody 4096 4月 22 15:35 test
### 対応
# vi /etc/idmapd.conf
[General]
Domain = defaultv4iddomain.com
# nfsidmap -d
# nfsidmap -c
# nfsidmap -l
# mount -a
### 対応後
# ls -l /nfs/
drwxr-xr-x 4 root root 4096 4月 22 15:35 test
コメント
ちょうど困っていたので、助かりました。