どこにも見つからない問題に遭遇しました（例：Samba文書）。
server1にSamba共有があり、共有がserver2にマウントされています。 server1の共有はへのシンボリックリンクです/var/container/db。
問題は、server2でこのシンボリックリンクフォルダを開こうとすると、そのパスが/var/container/db私のserver2に存在するため、server2のローカルファイルが表示されることです。
この問題の原因は何であり、解決策は何ですか？
どちらのサーバーもDebianで実行されています。
答え1
Unixファミリーホスト間でシンボリックリンクを共有すると、共有がマウントされたシステムは独自のファイルシステムツリーに従ってシンボリックリンクを解釈します。これがUnixスタイルのシンボリックリンクがどのように機能するかです。
サーバー1の共有にシンボリックリンクが指すコンテンツが含まれている場合は、次のものを使用できます。比較的絶対リンクの代わりにシンボリックリンク。
たとえば、Samba共有がserver1にあり、/varserver2にマウントされており、/server1varシンボリックリンクがserver1にある場合、/var/some/directory/link-to-db現在のシンボリックリンクは次のようになります。
server1# ln -s /var/container/db /var/some/directory/link-to-db
代わりに、次のようにすることができます。
server1# cd /var/some/directory
server1# ln -s ../../container/db link-to-db
server1のデータベースがSamba共有内にない場合は、Sambaサーバーパラメータが必要ですwide links = yes。これにより、server1はシンボリックリンクをたどり、シンボルを渡す/var/container/dbのではなくserver1へのアクセスを提供します。
ただし、サーバーがデフォルト設定で実行されていても、デフォルトで有効になります。unix extensions = yesクライアントwide linksがUnix系システムの場合（あなたの場合のように）無効になります。
allow insecure wide links = yesただし、設定により、このパラメータを共有接続でも機能させることができますwide links。unix extensionsしかし、これは安全ではないのでお勧めできません。クライアントが共有に適切なシンボリックリンク（書き込み可能な場合）を生成してSamba共有の外部のすべてのファイルにアクセスしようとする可能性があるため、server1の管理者は共有されているものと共有できないものに対する制御を失います。接続に使用されるファイルには、ファイルを読み取る権限があります。
デフォルトでは、allow insecure wide links++++クライアント書き込み可能共有はSambawide linksとのunix extensions++++共有と実質的に同じです/。お勧めできません。