Windows 11とWSL2を使い、Markdownの保管場所をWSL内に置いています。Claude CodeやCodexのようなCLI型のAIにファイルを読み書きさせるなら、Linux側にまとめたほうが扱いやすいからです。
そのディレクトリをWindows版ObsidianからVaultとして開こうとしたところ、次のエラーで止まりました。
EISDIR: illegal operation on a directory, watch
先に結論を書くと、UNCパスの表記を変えるだけでは解決しませんでした。現実的な構成は次の2つです。
- Windows版Obsidianを使い、Vaultの実体もWindows側へ置く
- VaultをWSL側に残し、Linux版ObsidianをWSLgで動かす
どちらを選ぶかは、Markdownの「正本」をWindowsとWSLのどちらへ置きたいかで決まります。私は2番目を選びました。
発生したエラー
最初に試したのは、Windows版ObsidianからWSL内のディレクトリを直接指定する方法でした。
\\wsl.localhost\Ubuntu\home\<LinuxUser>\life
エクスプローラーからは中身を表示できます。しかし、ObsidianでVaultとして開くと、ディレクトリの監視処理でEISDIRが発生しました。
指定されたRedditスレッドでも同じエラーが再現されています。wslpath.exe -wでWindows形式へ変換する案も出ていますが、変換後も実体はWSLのファイルシステムです。今回の問題は単純なパス表記ではなく、Windows版Obsidianのファイル監視とWSLのUNCパスの組み合わせにあると見るのが自然です。
Obsidian Forumにも、WSL内のVaultをWindows版から扱うことに関する機能リクエストが長く残っています。そのため、UNCパスを直接開く構成に固執せず、どちらかのOSへ処理を揃えることにしました。
確認した環境
今回確認した構成は次のとおりです。
Host OS: Windows 11
Linux environment: WSL2 + WSLg
Obsidian: 1.12.7（Flathub版）
Installation: Flatpak / system
Vault: WSL2のLinuxファイルシステム内
Microsoftの公式ドキュメントでは、WSL2でLinux GUIアプリをWindowsデスクトップ上へ表示できます。ただし、これは完全なLinuxデスクトップを起動する仕組みではなく、LinuxアプリのウィンドウをWindows上で利用するための統合です。
回避策1：VaultをWindows側へ置く
Windows版Obsidianを使い続けたいなら、この方法がいちばん素直です。
たとえば、Vaultを次へ作ります。
C:\Users\<WindowsUser>\Documents\Obsidian Vault
同じディレクトリは、WSLから次のパスで参照できます。
/mnt/c/Users/<WindowsUser>/Documents/Obsidian Vault
日常的に短いパスで使いたければ、WSL側へシンボリックリンクを作れます。
ln -s \
"/mnt/c/Users/<WindowsUser>/Documents/Obsidian Vault" \
"/home/<LinuxUser>/vault"
リンク先として指定する/home/<LinuxUser>/vaultは、事前に同名のファイルやディレクトリが存在しない状態にしておきます。
この構成では、ObsidianとVaultがどちらもWindows側に揃います。WSLのGitやAIツールは/mnt/cまたはシンボリックリンク経由で同じファイルを編集します。
注意点は性能です。Microsoftは、Linuxのコマンドラインから作業するファイルはWSLのLinuxファイルシステムへ置くことを推奨しています。/mnt/cを経由する処理は、Linuxファイルシステム内で完結する場合より遅くなることがあります。小規模なMarkdown Vaultなら許容できる可能性がありますが、大量検索やGit操作を頻繁に行うなら確認したほうがよいでしょう。
回避策2：Linux版ObsidianをWSLgで動かす
VaultをWSL側に残したい場合は、ObsidianもWSL側へ揃えます。画面はWSLgによってWindowsデスクトップへ表示されるため、操作感は通常のデスクトップアプリに近いです。
今回はFlatpak版を使用しました。
sudo apt update
sudo apt install -y flatpak
sudo flatpak remote-add --if-not-exists \
flathub https://flathub.org/repo/flathub.flatpakrepo
sudo flatpak install -y flathub md.obsidian.Obsidian
Vaultのパスを渡して起動します。
flatpak run md.obsidian.Obsidian /home/<LinuxUser>/life
この構成では、Obsidian、Git、検索コマンド、AIツールが同じLinuxパスを見ます。WindowsとWSLの境界をまたぐファイル監視がなくなり、Vaultを移動する必要もありません。
日常利用では、長いFlatpakコマンドを毎回入力しないよう、次のようなラッパースクリプトを用意しました。
#!/usr/bin/env bash
set -euo pipefail
VAULT_PATH="${1:-/home/<LinuxUser>/life}"
exec flatpak run md.obsidian.Obsidian "$VAULT_PATH"
これをPATHの通った場所へopen-obsidianという名前で配置すると、次の1行で起動できます。
open-obsidian
open-obsidianはObsidianやWSLの標準コマンドではなく、自分で作った起動用ラッパーです。
2方式の比較
| 観点 | VaultをWindowsへ置く | ObsidianをWSLで動かす |
|---|---|---|
| Vaultの実体 | Windows | WSL |
| Obsidian | Windows版 | Linux版 |
| WSLからのアクセス |
/mnt/c経由 |
Linuxネイティブ |
| Windowsアプリとの連携 | しやすい | 用途によりひと手間 |
| Linux側のGit・検索 | 性能差を確認したい | 相性がよい |
| WSL停止中の利用 | 可能 | 不可 |
| 向いている人 | ObsidianとWindows操作が中心 | WSLのCLI・AI操作が中心 |
判断基準はシンプルでした。
- Windows版Obsidianを中心に使うなら、VaultもWindowsへ置く
- WSL内のGit、開発ツール、AIが中心なら、ObsidianもWSLで動かす
「Windows版からWSLのUNCパスを直接開く」という中間構成は一見便利ですが、今回のようにファイル監視で詰まる可能性があります。
今回採用した構成
私は、WSL内のMarkdownをAIが継続的に読み書きする運用を優先しました。そのため、Vaultを移さず、Flatpak版ObsidianをWSLへ入れています。
Windows 11
└─ WSL2
├─ Vault: /home/<LinuxUser>/life
├─ Git / CLI / AI tools
└─ Obsidian（Flatpak）
└─ WSLgでWindowsデスクトップへ表示
実機ではObsidian 1.12.7がFlathubからsystem installationとして導入され、Vault内の.obsidianディレクトリも確認できています。普段はopen-obsidianで同じVaultを開いています。
注意点
WSLg版にも弱点はあります。WSLが停止していると起動できず、Flatpakのランタイムも含めてLinux側で管理する必要があります。日本語入力、GPU描画、クリップボード、プラグインなどは環境ごとに確認したほうが安全です。
また、Redditのコメントは公式仕様ではなく、ユーザーが試した回避策です。今回も、UNC Vaultで起きるすべてのエラー原因を断定するものではありません。重要なVaultを移動する前にはバックアップを取り、小さなテストVaultで挙動を確認してください。
まとめ
EISDIR: illegal operation on a directory, watchに遭遇したとき、パス表記の修正だけで粘るより、アプリとVaultを同じOS側へ揃えるほうが安定しました。
私のようにWSL内のCLIやAIを中心に使うなら、Linux版ObsidianをWSLgで動かす構成が自然です。Windows版Obsidianが中心なら、VaultをWindowsへ移してWSLから/mnt/c経由で触る構成が分かりやすいでしょう。
Obsidianをどこへ入れるかより先に、Markdownの正本をどこへ置きたいかを決める。今回の問題は、それで整理できました。