私のあごひげは今では真っ白で、何十年もNFSを使ってきたことを思い出します。ここでは元のRFCを引用する。これが今日のNFSの基礎となっている。RFC1094。 もちろん、それから30年ほど経ちましたが、それで、質問です:
その間設定オプションを介して、サーバー側からリンクを解釈することが可能になりましたか?これにより、クライアント側でのリンクの解釈に関する多くの問題が確実に解消されるでしょう。
それとも、私が完全に間違っていて、私が引用しているものは時代遅れで、実際にはデフォルトでサーバー側で解決されていて、トラブルシューティングでウサギの穴に落ちてウサギを追いかけているだけなのでしょうか?
もしそれがまだ古いやり方でクライアント側で解釈されるのであれば、サーバー側での解釈を可能にするオプションがない場合、絶対リンクではなく相対リンクを使用すると役立つでしょうか?
ありがとう。
答え1
シンボリックリンクは常にクライアントによって解決されます。これにはいくつかの理由があります。まず、NFS プロトコルにはファイルハンドルの概念があります。各ハンドルは、ディレクトリ、ファイル、シンボリックリンク (およびその他) であるファイルシステムオブジェクトを指します。さらに、NFSv4.1仕様には明確にこう書かれています:
NFS クライアントによって作成されたか、サーバー上でローカルに作成されたかに関係なく、シンボリック リンク内のデータは作成時に解釈されず、単に保存されます。
2 番目に、シンボリック リンクをサーバー側で処理する場合、シンボリック リンクがエクスポートされたファイルシステムの外部を指す可能性があるため、追加のアクセス許可ルールを考慮する必要があります。
実際、SAMBAサーバーにはシンボリックリンクをたどるオプションはありません。これは、(a) オリジナルのMSファイルシステムにはシンボリックリンクの概念がなかったことと、(b) ファイルシステムオブジェクトタイプとしてシンボリックリンクが追加されたためです。SM2 についてちなみに、この動作は NFS の解釈と一致します。
シンボリック リンクはサーバーによって評価されてはなりません。
必要に応じてカスタム ファイル システムの実装を可能にするユーザー空間 NFS サーバーがいくつかあります。
もし良いサーバー側でシンボリックリンクを解決する理由がある場合は、これを追加できます。
答え2
ネットワーク上に、サーバーを指す同じ NFS マウント設定を持つ 2 台のコンピューターがあります。サーバーには、エクスポートされたディレクトリから別のディレクトリへのシンボリック リンクがあります。1 つのクライアントではリンクは問題なく機能しますが、もう 1 つのクライアントではリンクが信頼できません。機能しているクライアントは新しいバージョンの NFS (同じプロトコルを使用) を使用しているため、バグが修正されたのではないかと考えています。理論的には、エクスポートを実行しているのはサーバーであるため、リクエストはサーバーに送信され、そこで解釈されるはずです。クライアントがフォルダーにシンボリック リンクを配置すると、他のクライアントではおそらく壊れます。ただし、サーバーのシンボリック リンクは機能するはずです。これは通常、ネットワーク共有用の特別なタイプのシンボリック リンクが必要であることを示しています。サーバー シンボリック リンクのようなものです。