問題の説明（この問題はすでに解決されていますが、このソリューションが機能する理由について質問があります。）
NFS サーバーは Ubuntu 16.04.4 LTS です。クライアントは、Ubuntu 16.04.4 LTSとCentOS 6.10と7が混在しています。
NFSサーバーは数ヶ月間正常に実行されており、特定のエクスポートの1つが複数のクライアントにバックアップを提供しています。 NFSサーバーディレクトリは次のとおりです。
/mnt/backups/client1
/mnt/backups/client2
/mnt/backups/client3
/mnt/backups/client4
/etc/exports には以下が含まれます。
/mnt/backups 1.2.3.0/24(rw,sync,no_subtree_check)
クライアントはバックアップ中にのみ nfs サーバーをマウントし、バックアップが完了するとバックアップをアンマウントします。
これはうまく機能しますが、クライアントが/mnt/backupsディレクトリにお互いを見ることはできません。すべてのクライアントは同じバックアップuid / gidを使用します。したがって、/ etc / exportsファイルを使用してディレクトリを分割することにしました。
これを行うには、NFSサーバーを停止し、次のものを含めるように/ etc / exportsを変更します。
/mnt/backups/client1 1.2.3.21(rw,sync,no_subtree_check)
/mnt/backups/client2 1.2.3.22(rw,sync,no_subtree_check)
/mnt/backups/client3 1.2.3.23(rw,sync,no_subtree_check)
/mnt/backups/client4 1.2.3.24(rw,sync,no_subtree_check)
クライアントは、バックアップが進行中の場合（午前4時）にNFSサーバーをマウントすることに注意してください。サーバーでNFSサービスを再起動し、importfsを使用してエクスポートすることを確認しても問題ありません。
いいですね。 client1をテストしてみてください。
mount nfserver:/mnt/backups/client1 /mnt/client1
うまくいきますが、/mnt/client1の操作の結果は次のとおりです。
cannot open directory /mnt/client1/: Stale file handle
取られたソリューション（これをしました。いいえ働く）：サーバーでNFSを再起動します。クライアントを再起動します。クライアントとサーバーの両方でlsof | grep / mntを実行して、ファイルを開いたままにするプログラムがあることを確認してください。サーバー/クライアントの権限を確認してください。繰り返しますが、NFS /etc/exportsを古いファイルに戻し、クライアントからnfsサーバーをマウントするだけです。 「新しい」方法に戻すと機能しません。
「NFSの再起動」のような答えを見つけるためにこれを行き、マニュアルページとSTFWをたくさん挽く必要がありました。私は数年前にこの問題があり、何らかの理由でfsidが解決策に関与していたことを思い出しました。マニュアルページを読んだら、NFS サーバーの /etc/exports ファイルに以下を追加します。
/mnt/backups/client1 1.2.3.21(fsid=101,rw,sync,no_subtree_check)
/mnt/backups/client2 1.2.3.22(fsid=102,rw,sync,no_subtree_check)
/mnt/backups/client3 1.2.3.23(fsid=103,rw,sync,no_subtree_check)
/mnt/backups/client4 1.2.3.24(fsid=104,rw,sync,no_subtree_check)
もう一度言いますが、この後に実行される唯一の作業は、サーバーからエクスポートfs -raを実行することです。
これで、すべてのクライアントがnfsサーバーのエクスポートをマウントできるようになり、すべて機能します。
これはなぜ解決策ですか？
fsidを使用する必要がありますすべて出口？
マンページを読んでください。これfsidが解決策である理由の明確な説明がないようです。古いマウントがクライアント側（またはサーバー側）の一種のNFSファイルハンドラである可能性があると思われましたが、再起動後も持続することは奇妙です。
答え1
簡単に言うと、fsidは、クライアントとサーバーがエクスポートをインストールした後にそれを識別する方法です。
マニュアルページで指定されているように指定しない場合、fsid はデフォルトのファイルシステムから派生します。
4つのエクスポートには同じfsidがあるため、client1がマウントされたファイルを要求した場合、サーバーはclient4のエクスポートにアクセスしようとしていると考えることができます（同じfsidの最新の項目のみを保持すると仮定）。
私の考えでは、この仮説を検証する方法はいくつかあります。たとえば、4つのクライアントのうちの1つだけが有効であることを確認します。また、他の3つのエクスポートではなくclient1のエクスポートのみを維持し、client1が正しく機能していることを確認してください。
また、見ることができますこの回答クライアントでfsidを照会する方法の場合は、mountpoint -d4つのクライアントで利用可能な次のコマンドを使用して、4つのインストールに同じfsidがあることを確認できます。
これはなぜ解決策ですか？
異なる fsid が使用されるため、NFS サーバーへのエクスポートが異なるため、クライアント アクセスをそのインストールに正しく一致させます。
すべてのエクスポートにfsidを使用する必要がありますか？
はい、これはプライマリストレージデバイスの制御と変更を維持し、エクスポートが顧客に影響を与えないようにするための良い方法だと思います。
（私の場合、一部のディスクがSANにあり、NFSサーバーが時々別の順序でディスクをスキャンするため、これを採用したと思います。したがって、再起動後に/ dev / sdhが突然/ dev / sdjになります。タグを使用してマウントすると正しい場所にマウントされますが、fsidが変更され、クライアントが失われますが、これはUUIDが存在する前であり、UUIDは現在サポートされているように見え、ディスクに問題がある場合は確かにより良い解決策です。それは悪い考えではなく、すべての権限を維持することができます。
答え2
Ventura 13.2を実行しているMacでNFS経由でQNAPにアクセスするときにこの問題が発生しました。その結果、両方のデバイスを再起動しても消えない古いNFSハンドルが生成されます。
確認するには、サーバーにログインしてssh次の手順を実行します。
exportfs -ra
他の何も（構成変更なし、再生なしfsid、他の操作なし）問題は解決されませんでした。