ファイル共有とシンボリックリンクの利用について

Last Update: feedback 共有

本記事は 2016 年 8 月 31 日に公開された記事を本ブログに移行した記事になります。

Windows プラットフォーム サポートの山本です。
今回はファイル共有とシンボリック リンクの利用について取り上げたいと思います。

1.シンボリックリンクについて
この機能は Windows 2000 の NTFS で導入された、「リパース ポイント」と呼ばれる機能を使って実現されている機能です。
mklink コマンドを使用して、以下のように C:\ 以下のフォルダへ、D:\ 以下に存在するフォルダをリンクさせることができます。

2.シンボリック リンクの作成方法
この機能を使用して、共有しているフォルダ内に別の共有 (ローカル or リモート問わず) へのリンクを作ると、ユーザー側ではアクセス先を変更せずに参照先を変更する事が出来ます。
以下のコマンド例は、別のサーバーで共有しているフォルダへのリンクを作成した際の例です。

この例で使用した C:\Share フォルダは、\w2008r2-002\Share として共有されています。
この \w2008r2-002\Share フォルダ以下に、\w2008r2-003\Share 以下で共有されている DataFolder をリンクさせた例となります。
※同様の手順で、ローカル コンピューターで共有している別のファイル/フォルダも、リンク先として指定できます。

3.アクセス元 (クライアント) での注意点
注意点として、アクセス元であるクライアント コンピューターでも設定が必要なことが挙げられます。
上記のシンボリック リンク設定だけが完了している状態では、DataFolder 以下のファイルを参照する事ができません。

これは、リモートからリモートへのシンボリック リンク解決が「クライアント上で」無効に設定されているために発生するエラーです。
解決するためには、クライアントで次のコマンドを実行します。

2 つ目のコマンドに指定した「R2R」が「Remote to Remote」を意味しており、このシンボリック リンクの解決を「許可 (1)」するというコマンドです。

※赤線個所が変化点です。

その後、改めてクライアントからのアクセスを試すと、次の結果が得られます。

ここまでで使用方法の紹介は終了です。
実際にご使用いただく場合はアクセス権なども考慮する必要がありますので、この辺りはお試しいただきながら動作をご確認ください。

4. その他、注意点
リモートでシンボリック リンクを使う場合、上記以外にもパケット量の増加に注意する必要があります。
以下のパケット トレースは、上でご紹介したやり取りを行った際、クライアントで取得したパケット トレースです。

※赤字にしている個所が、シンボリック リンクのリンク先に対して行われた通信となります。

クライアントから SMB2 CREATE のコマンドが w2008r2-002 (192.168.0.2) へリクエストされた後、ファイル サーバー (192.168.0.2) は「STATUS_STOPPED_ON_SYMLINK」というエラーを返します。
これは指定されたファイルがシンボリック リンクだった場合に発生するエラーで、返されたクライアントは、直ちに指定されたサーバー (192.168.0.3) への接続を確立します。
つまり、両方に対して SMB のセッションが必要であり、また、クライアントから送信されるパケット数もその分増加します。

5.参考事例
ファイル共有へ接続するクライアントは、CREATE コマンドを発行する際に FCB (File Control Block :ファイル情報を格納するための領域) を作成し、その情報に基づいて送信するパケットを生成します。
この FCB には Lease (※文末参照) を確保するために使う Lease Key などの情報が含まれています。
有限のリソースですので、この FCB は使い終わった後で再利用される可能性がありますが、再利用のタイミングによって CREATE の対象ファイルをサーバー側で間違えてしまい、以下のフローで STATUS_INVALID_PARAMETER を返すという事象が 1 例ありました。

 1.クライアントから、CREATE コマンドをサーバーに対して送信します。
 2.サーバー側では、CREATE コマンドを受信して Lease を割り当てます。
 3.2 の CREATE コマンドに対して、サーバー側からは STATUS_STOPPED_ON_SYMLINK の応答を返します。
 4.本来、ここでサーバー側は 2 で割り当てた Lease を解放しますが、その解放前にクライアントから次の CREATE リクエストを受信します。
 5.この CREATE には Lease を割り当てる際に使用されるキーが含まれていますが、同じ FCB が使われた事により「2 で確保した Lease」とサーバーでは判断してしまいます。
 6.1 で送られた CREATE と 4 で送られた CREATE は、パスが異なるため、サーバー側はクライアントに対して「STATUS_INVALID_PARAMETER」を返します。

ローカル内の別共有フォルダをリンク先に指定した上で、頻繁にアクセスが発生するという複数の条件が重なる事で発生した、タイミングに依存する事象です。

ただし、アプリケーションなどから機械的にシンボリック リンクを含む共有パスに対して繰り返しアクセスを行った場合などは、条件が揃う可能性もありますので、もし条件に合致するような使用方法で運用されている場合にはご注意ください。

なお上記の事例事象は、シンボリック リンクではなくジャンクション ポイントを利用する事で、回避する事が可能です。
もしローカル サーバー内でシンボリック リンクを使用して共有フォルダのリンクを公開している場合、ジャンクション ポイントへの置き換えもご検討ください。
ジャンクション ポイントは、mklink コマンドに「/J」オプションを指定する事で作成できます。

・注意
ジャンクション ポイントは、ローカル内のみで有効な機能です。
そのため、別のサーバー (あるいは自分のサーバー) の共有パスを指定すると、次のようなエラーになります。

※Lease について
SMB v2.1 (Windows 7/2008 R2) 以降では、Oplock (キャッシュの使用権) の Lease という機能が搭載されています。
Oplock Lease機能では、特定のファイルに対して最初にリクエストを出したクライアントに対し、キャッシュの使用権を与えます。
その後、別のクライアントから同一ファイルに対してキャッシュの使用権のリクエストを受信すると、すでに使用権を与えたクライアントに対して Oplock Break というリクエストを送信し、キャッシュ使用権の解放を促します。
この機能により、Oplock が使用できる環境 (有効な環境) では、ネットワーク上のクライアントから同一ファイルへのアクセスが発生する場合に、キャッシュを利用することができるため、パフォーマンスの向上が見込めます。

英文のみの紹介となってしまいますが、以下のリンクでは Oplock および Lease 機能について紹介しておりますので、詳細についてはこちらも併せてご参照ください。

Title : Client caching features: Oplock vs. Lease
Link : https://blogs.msdn.microsoft.com/openspecification/2009/05/22/client-caching-features-oplock-vs-lease/

[特記事項]
本情報の内容(添付文書、リンク先などを含む)は、作成日時点でのものであり、予告なく変更される場合があります。