【ITニュース解説】Map WebDAV to a Real Drive Letter on Windows: Network Location vs. Volume

Windowsを使っていると、ファイルサーバーやNAS（ネットワーク接続ストレージ）のような、ネットワーク上にある保存場所を自分のパソコンのドライブのように扱いたくなる場面がよくある。多くの人が最初に試すのは「ネットワークドライブの割り当て」という機能だろう。しかし、この機能を使って割り当てられたものは、実は「本当のドライブ」とは少し違う扱いになるため、後からさまざまな問題に直面することがある。この解説では、その落とし穴と、問題を解決するための方法について詳しく説明していく。

「ネットワークドライブの割り当て」で設定した場所は、エクスプローラーには表示されるものの、Windowsの内部では「ネットワークロケーション」として認識されるだけで、CドライブやDドライブのような「ボリューム」とは区別される。この違いが、多くの不具合の原因となる。例えば、日々のバックアップを取るためのソフトウェアや、パソコン全体のシステムイメージを作成するツール、あるいは古いタイプのソフトウェアのインストーラーなどは、ネットワークロケーションを「ドライブ」として認識できない場合がある。その結果、バックアップツールが「該当するドライブがありません」と報告したり、ソフトウェアのインストールが途中で止まったりすることが起こる。実際にエクスプローラーでファイルが見えているのに、特定のソフトウェアからは見えない、という奇妙な状況に遭遇することがあるが、これはドライブとして認識されていないことが原因である。

二つ目の問題は、ファイルへの「ロック機能」が不足している点だ。ファイルがネットワーク上にある場合、複数のユーザーが同時にアクセスしたり、編集したりする可能性がある。このようなとき、ファイルが壊れてしまわないように、最初にファイルを開いたユーザーが一時的にそのファイルを「ロック」し、他のユーザーが編集できないようにする仕組みが必要になる。しかし、Windowsに標準で搭載されているWebDAV（ウェブ分散オーサリングおよびバージョン管理）クライアントは、このロック機能を十分に実装していない。そのため、Microsoft Officeのようなファイルを排他的に開いて編集するアプリケーションは、ネットワーク上のファイルを読み取り専用として扱ってしまうか、最悪の場合、ファイルを保存できないといったエラーを引き起こす。また、ファイルを編集する際に一時ファイルを元のファイルの隣に作成するようなソフトウェアも、このロック機能の不足が原因で正しく動作しないことがある。このような問題は原因の特定が難しく、利用者を困らせることが少なくない。

三つ目は、「パスの長さ制限」という意外な落とし穴だ。Windowsのシステムでは、ファイルやフォルダへの経路を示す「パス」の長さに260文字という制限が昔から存在している。最近ではこの制限が緩和される傾向にあるが、WebDAVクライアントにおいては依然としてこの古い制限が適用される場合がある。さらに、日本語のようなASCII文字以外の文字を含むファイル名やフォルダ名を使用すると、システム内部でURLエンコードという処理が行われる。このエンコードによって、見た目には短いパスであっても、実際の内部的なパスの長さは予想以上に長くなってしまう。その結果、深い階層にファイルを保存したり、長い名前のフォルダを使用したりすると、あっという間に260文字の制限を超えてしまい、ファイルにアクセスできなくなってしまうといった問題が発生する可能性がある。

これらとは別に、データ通信の安全性を確保する「TLS」という技術に関連した問題も発生することがある。WebDAVクライアントがサーバーと通信する際、使用する暗号化方式（暗号スイート）をネゴシエートするが、WindowsのWebDAVクライアントが対応する暗号スイートの範囲が、最新のサーバーが提供するものよりも狭い場合がある。これにより、Windowsの標準的なファイル共有プロトコルであるSMB（Server Message Block）では問題なく接続できるサーバーなのに、WebDAVクライアントでは接続が失敗するといった事態が発生する。筆者の経験では、より新しいTLS 1.3やECDHE暗号スイートを強制することで接続が可能になったケースもあるが、これがトラブルシューティングをさらに複雑にすることがある。

では、これらの問題を回避し、「本当に」機能する解決策は何だろうか。

一つは、LAN環境内で利用する場合、OS標準のSMB（Server Message Block）機能を使ってネットワークドライブをマッピングする方法だ。これはWindowsにネイティブに搭載されている機能であり、外部のドライバーを必要とせず、パスの長さ制限も緩和されているため、多くの場合は最適な解決策となる。家庭内や企業内のローカルネットワークでファイルを共有する際には、まずこのSMBの利用を検討すべきだ。

もう一つは、「カーネルモードマウント」と呼ばれる、より高度な方法だ。これはWinFspのような特殊なソフトウェアをベースにして、ネットワーク上のストレージをWindowsに対して「実際のドライブレター」として登録するものだ。この方法を用いると、前述のファイルロック機能が適切に実装され、ローカルに書き込みキャッシュが保持されるためパフォーマンスも向上する。また、認証情報がキャッシュされ、ネットワーク接続が一時的に切れても、自動的に再接続してクリーンに動作を再開する信頼性がある。特に、古いソフトウェアが「X:...」のように、必ず物理的なドライブレターを指定してファイルを読み書きすることを要求する場合、このカーネルモードマウントが唯一の解決策となることが多い。これは、一般的なネットワークドライブの割り当てでは得られない「本当のドライブ」としての機能を提供する。

どちらの解決策が自分の状況に合っているかを見分けるには、次のように考えると良い。もし、人間が手動でファイルを移動したり、コピーしたりするだけであれば、NASベンダーが提供する同期クライアントやSMBマッピングで十分な場合が多い。しかし、あるプログラムが自動的に、そして安定したパスでファイルを読み書きする必要がある場合は、エクスプローラーに表示される「ショートカット」のようなネットワークロケーションではなく、「本当のボリューム」として認識されるドライブが必要になる。

システムに導入する前に、そのマウント方法が本当に機能するかを確認するための3つの簡単なテストがある。一つ目は、「ディスクの管理」ツールを開いて、割り当てたドライブが「ボリューム」として表示されるかを確認することだ。二つ目は、Officeアプリケーションやデータベースソフト、あるいはインストーラーのような、ファイルを排他的に開いて書き込むタイプのアプリケーションを使って、そのドライブに問題なく書き込みができるか試すこと。多くの「私の環境では動いています」というデモンストレーションは、この二つ目のテストで失敗することが多い。そして三つ目は、ネットワーク接続を一時的に切断し、その後再接続した際に、ローカルに保存されたファイルが破損することなく、元の状態に再同期できるかを確認することだ。これらのテストをクリアできれば、そのマウント方法は信頼性が高いと言えるだろう。

筆者も、WinFspをベースとしたWebDAV/NASマウント用のソフトウェアを開発しており、これはカーネルモードマウントを実現する一つの手段である。しかし、もしSMBであなたの用途が満たされるのであれば、無理に別のツールを使う必要はない。目的と用途に合わせて、最適な解決策を選ぶことが最も重要だ。