Linux NFSマウントファイルロックのトラブル

linux

最近トラブった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

コメント

  1. あああ より:

    ちょうど困っていたので、助かりました。