この問題の簡単な概要:
CentOS6.9 システム上の NFS 共有は、Windows または Linux システムにマウントされた場合にはディレクトリを適切にマウントして表示しますが、Mac OS システムにマウントされた場合にはディレクトリを表示できません。Mac OS システムに NFS 共有をマウントした後、ディレクトリの内容を読み込もうとすると Finder が回転します。
/var/log/messages からのエラー メッセージ:
kernel: nfsd: last server has exited, flushing export cache
kernel: Installing knfsd (copyright (C) 1996 [email protected])
kernel: NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory
cat /etc/passwd | grep rpc の出力
rpc:x:32:32:Rpcbind Daemon:/var/lib/rpcbind:/sbin/nologin
rpcuser:x:29:29:RPC Service User:/var/lib/nfs:/sbin/nologin
/var/log/messages のエラー メッセージを理解するのに非常に苦労しています。nfs の何が問題なのでしょうか? 他の投稿では問題ないはずと述べられているにもかかわらず、/etc/passwd のパスが間違っていると指摘する他の投稿がオンラインでいくつか見つかりました。
/etc/passwd にリストされているパスを再確認したところ、/var/lib にはそのような rpcbind フォルダーはありませんが、/var/cache には 1 つあり、その投稿の人が正しいパスであると述べていました。そのパスが問題の原因となっている可能性がありますか?
次に行う予定の手順は、nfs および rpcbind サービスを再起動し、それが失敗した場合は、yum reinstall nfs-util rpcbind を使用して再インストールすることです。これらの方法の両方が失敗した場合は、パスを /var/lib から /var/cache に変更することを検討します。
これまでにこの問題に遭遇した人はいますか?
答え1
私の理解が正しければ、問題自体は NFS ではなく Finder にあります。Windows および Linux クライアントでは、NFS マウントに接続してもパフォーマンスの問題は表示されませんでした。
Finder のパフォーマンス問題を解決するために実行した手順は次のとおりです。
- rpcbind サービスを停止しました
- nfslock サービスを停止しました
- 実行されたコマンド rm -rf /var/lib/nfs/statd/sm/*
- 実行されたコマンド rm -rf /var/lib/nfs/statd/sm.bak/*
- rpcbind サービスを開始しました
- nfslock サービスを開始しました
- NFSサービスを再起動しました
その後、Finder は簡単にディレクトリを開いて一覧表示できるようになりました。なぜこれが機能したのかは正確にはわかりませんが、効果は顕著でした。
最後に、/var/lib/rpcbind のシンボリックリンクを /var/cache/rpcbind に追加しようとしましたが、何も変わりませんでした (もちろん、適切なサービスはすべて再起動しました) ので、元の設定に戻しました。
編集: 主な原因は隠しファイルで、その数は数百万に上ります。Finder はこれらすべてのファイルを処理するのに非常に苦労しました。それらを削除すると、これまで試したどの方法よりもパフォーマンスが改善されました。