MENU

Windows更新後にWSLから共有フォルダーをマウントできない原因と修正手順【KB5129195】

Windows11

Windows Updateの適用後、WSLやLinux仮想環境そのものは起動するのに、Windows側の共有フォルダーだけが表示されない、またはアクセスできなくなることがあります。

2026年9月のWindowsセキュリティ更新後に発生した場合は、Host Compute Service（HCS）が管理するLinux仮想マシンで、Plan 9によるホストフォルダー共有を利用している環境の既知の問題に該当する可能性があります。

Windows 11 バージョン24H2／25H2では、基本的にKB5129195またはそれ以降の累積更新を適用し、Windowsを再起動します。ただし、一時的な回避策としてグループポリシーを変更していた管理環境では、更新前にそのポリシーを再有効化する必要があります。([Microsoft Learn][1])

ITtripTOOLS
その「面倒」、無料で解決。 ITtripがつくる、6つの道具。 無料ツール一覧へ すべて無料・追加課金なし
先頭0を守るCSV編集こわさないCSV PDFに直接書き込みかけるPDF 写真＋説明をPDFに写レポ スマホ⇄PCで共有コピペ便 · 文章・写真 みんなの日程を調整日程Fit 匿名質問・投票を集めるKOEQ
目次

最初に今回の既知の問題へ該当するか確認する

共有フォルダーをマウントできない原因は、Windows Updateだけとは限りません。まず、症状が次の条件に当てはまるか確認してください。

確認項目今回の問題に近い状態
発生時期2026年9月のWindows更新後に発生した
Linux環境WSLなど、HCSが管理するLinux仮想環境
仮想マシンの状態Linux仮想環境自体は正常に起動する
発生している問題Windowsホスト側のフォルダーだけが見えない、または開けない
共有方式Plan 9を利用したホストフォルダー共有
エラー例Plan 9のドライブ共有がマウントされていない旨のエラー
WindowsWindows 11 バージョン24H2／25H2など

Microsoftの案内では、影響を受けた仮想マシンは正常に起動する一方で、WindowsホストからPlan 9で共有されたフォルダーがLinuxゲスト側に表示されない、またはアクセスできない状態になるとされています。WSLも影響を受けるアプリケーションの一つとして挙げられています。([Microsoft Learn][1])

反対に、次のような症状は別の原因である可能性が高くなります。

  • Linux仮想マシン自体が起動しない
  • Hyper-Vの仮想マシン全般を起動できない
  • mount -t cifs で接続するNASやファイルサーバーだけをマウントできない
  • Windows側のドライブ自体がBitLockerなどでロックされている
  • /etc/fstab に登録した特定のマウントだけが失敗する
  • Windows更新前から同じ症状が発生していた

通常のHyper-V仮想マシンでも、Plan 9によるホスト共有を使用していない場合は、今回の既知の問題には該当しません。([Microsoft Learn][1])

HCSとPlan 9による共有とは

Host Compute Serviceは、Windows上の仮想マシンやコンテナーを管理するために利用される仕組みです。

今回問題になったPlan 9共有は、Windowsホスト側にあるフォルダーを、Linux仮想環境から利用できるようにする経路です。一般的なネットワーク上のSMB共有とは異なり、仮想環境とホストOSの統合機能として動作します。

そのため、Windows側のフォルダーが見えなくなったからといって、すぐに次のような操作を行っても解決しない場合があります。

  • Linux側のSMB設定を変更する
  • mount.cifsをインストールし直す
  • Windowsのファイル共有を有効にする
  • ネットワーク資格情報を削除する
  • ファイアウォールの受信規則を追加する

Plan 9共有の不具合であれば、修正すべき対象はLinux側のSMB設定ではなく、Windows側の更新プログラムです。

WSLが今回の対象か確認する

WSLを利用している場合は、PowerShellまたはコマンドプロンプトで次のコマンドを実行します。

wsl --list --verbose

表示例は次のようになります。

  NAME      STATE           VERSION
* Ubuntu    Running         2

VERSIONが2なら、そのディストリビューションは軽量な管理対象仮想マシン上で動作しています。WSL 1は管理対象仮想マシンを使用しないため、今回のHCS管理Linux仮想マシンという条件とは異なります。([Microsoft Learn][2])

WSL全体の状態は、次のコマンドでも確認できます。

wsl --status

WindowsとWSLのバージョン情報を記録しておく場合は、次のコマンドも利用できます。

wsl --version
winver

管理者やサポート担当者へ問い合わせる場合は、次の情報を伝えると切り分けが早くなります。

  • Windows 11のバージョン
  • OSビルド
  • WSLのバージョン
  • 対象ディストリビューションがWSL 1かWSL 2か
  • 問題が発生し始めた日
  • 直前にインストールされたWindows更新プログラム
  • 見えなくなったWindows側フォルダーのパス
  • 表示されたエラーメッセージ

Windows更新後に共有フォルダーを復旧する手順

Windows 11のバージョンを確認する

Windowsキー + Rを押し、次の文字列を入力して実行します。

winver

表示された画面で、Windows 11が24H2または25H2か確認してください。

KB5129195は、Windows 11 バージョン24H2および25H2向けの帯域外更新プログラムです。KB5129195を直接適用した場合のOSビルドは、次のとおりです。

Windows 11KB5129195適用後のOSビルド
バージョン25H226200.9457
バージョン24H226100.9457

すでにKB5129195より新しい累積更新をインストールしている場合は、これより大きいOSビルドが表示されることがあります。([マイクロソフト サポート][3])

24H2／25H2以外のWindowsで同様の問題が発生している場合は、KB5129195を無理に適用するのではなく、そのWindowsバージョン向けに提供されている最新の累積更新を確認してください。

一時回避策でグループポリシーを変更したか確認する

Microsoftが案内した一時的な回避策を、グループポリシーで適用していた管理環境では注意が必要です。

Plan 9ホスト共有の問題に対する一時回避策を適用していた場合は、次の順序で対応します。

  1. 回避策として変更したグループポリシーを再有効化する
  2. KB5129195またはそれ以降の修正を含む更新をインストールする
  3. Windowsを再起動する
  4. Linux環境から共有フォルダーを確認する

ポリシー名や設定値が分からない場合は、推測でローカルグループポリシーを変更しないでください。Intune、Active Directoryのグループポリシー、構成管理ツールなど、最初に回避策を配布した方法と同じ方法で戻す必要があります。

個人所有のPCで、回避策を適用した覚えがない場合は、通常、このポリシー操作は不要です。

RDS向けの回避策と混同しない

KB5129195では、Plan 9ホスト共有の問題だけでなく、Remote Desktop Servicesの問題も修正されています。

ただし、グループポリシーによる一時回避策の扱いが異なります。

問題KB5129195適用前のグループポリシー操作
Plan 9ホスト共有回避策で変更したポリシーを再有効化する必要がある
Remote Desktop Services一時回避策を適用していても事前操作は不要

同じ更新プログラムで修正される問題でも、適用条件は同じではありません。RDS向けの手順を、そのままWSLやPlan 9共有の問題へ流用しないでください。([Microsoft Learn][1])

KB5129195またはそれ以降の更新をインストールする

個人用PCでは、次の順に開きます。

設定
→ Windows Update
→ 更新プログラムのチェック

利用可能な更新をインストールしてください。

KB5129195は累積更新プログラムで、Windows UpdateおよびMicrosoft Updateから自動的にダウンロード、インストールされます。Windows Update for BusinessやWSUSを利用する組織では、管理者が設定した更新ポリシーに従って配布されます。([マイクロソフト サポート][3])

すでにKB5129195より新しい累積更新が表示されている場合は、通常は新しい方を適用します。Microsoftも、修正を含む最新の更新プログラムを利用することを推奨しています。([Microsoft Learn][1])

Microsoft Update Catalogから手動導入する場合

Microsoft Update Catalogから手動でインストールする場合は、PCのCPUアーキテクチャに合ったパッケージを選択する必要があります。

また、環境によってはチェックポイント累積更新プログラムを先にインストールし、その後にKB5129195を適用する必要があります。複数のMSUファイルが表示された場合は、Microsoftの掲載順を無視して対象KBだけを単独で実行しないでください。([マイクロソフト サポート][3])

一般利用者は、特別な理由がなければWindows Updateからインストールする方が安全です。

Windowsを再起動する

更新プログラムのインストール後は、WSLのウィンドウを閉じるだけではなく、Windowsを再起動してください。

Microsoftの修正手順でも、グループポリシーを再有効化し、更新をインストールした後に再起動することが案内されています。([Microsoft Learn][1])

再起動を保留した状態では、更新済みのコンポーネントと更新前の仮想環境が混在し、正しく確認できない可能性があります。

再起動後に共有フォルダーを確認する

Windowsの再起動後、PowerShellでWSLの状態を確認します。

wsl --list --verbose

対象ディストリビューションを起動します。

wsl

WindowsのCドライブを確認する場合は、Linux側で次のコマンドを実行します。

ls -la /mnt/c

対象が別のドライブや専用の共有フォルダーである場合は、実際のマウント先へ読み替えてください。

マウント情報からPlan 9やDrvFsに関連する項目を確認する場合は、次のように実行できます。

mount | grep -Ei '9p|drvfs'

確認すべきポイントは次のとおりです。

  • Windows側の対象フォルダーが表示される
  • ディレクトリ内のファイル一覧を取得できる
  • 読み取りが必要なファイルを開ける
  • 書き込み可能な共有では、テストファイルを作成できる
  • 「Plan 9共有がマウントされていない」というエラーが消えている

本番データでいきなり書き込みテストをせず、削除して問題のない一時フォルダーで確認すると安全です。

KB5129195を適用しても直らない場合

更新履歴を確認する

次の順に開きます。

設定
→ Windows Update
→ 更新の履歴

KB5129195または、それより新しい累積更新が正常にインストールされているか確認します。

「インストールに失敗しました」と表示されている場合は、共有設定を変更する前にWindows Updateの失敗を解決する必要があります。

WSLだけを完全に停止して再起動する

Windowsを再起動済みでも状態が改善しない場合は、PowerShellでWSLを完全停止してから起動し直します。

wsl --shutdown

その後、対象ディストリビューションを再度起動します。

wsl

wsl --shutdownは、実行中のすべてのWSLディストリビューションとWSL 2の軽量仮想マシンを終了するコマンドです。保存していない作業がないことを確認してから実行してください。([Microsoft Learn][4])

Linux側の自動マウント設定を確認する

Windows更新とは別に、WSLの設定変更によってWindowsドライブがマウントされなくなることもあります。

次のファイルを確認します。

cat /etc/wsl.conf

[automount]の設定で自動マウントが無効化されていないか確認してください。

また、独自のマウント設定を使用している場合は、次のファイルも確認します。

cat /etc/fstab

記述ミス、存在しないパス、古い認証情報、利用できないドライブを指定していると、そのマウントだけが失敗することがあります。

SMB共有とPlan 9共有を区別する

次のようなコマンドで接続している場合は、Plan 9ではなくSMB共有です。

sudo mount -t cifs //server/share /mnt/share

SMB共有であれば、確認対象は次のように変わります。

  • サーバー名を名前解決できるか
  • サーバーへ通信できるか
  • ユーザー名とパスワードが正しいか
  • SMBのバージョン指定が適切か
  • Windows Defender ファイアウォールで遮断されていないか
  • NASやファイルサーバーが稼働しているか

WindowsホストのPlan 9共有に対する修正を適用しても、別サーバー上のSMB共有の認証エラーは解消しません。

すぐにWSLを登録解除しない

共有フォルダーが見えないだけの状態で、次のコマンドを実行するのは避けてください。

wsl --unregister <ディストリビューション名>

wsl --unregisterを実行すると、そのディストリビューションに保存されているデータ、設定、インストール済みソフトウェアが削除されます。今回のようなWindows更新に起因する共有不具合に対して、最初に行う操作ではありません。([Microsoft Learn][4])

再インストールを検討する場合でも、先にwsl --exportなどで必要なデータを退避してください。

共有フォルダーを復旧するときの確認順序

Windows更新後にWSLなどから共有フォルダーをマウントできなくなった場合は、次の順番で対応します。

  1. Linux仮想環境自体が正常に起動するか確認する
  2. Windowsホスト側のフォルダーだけが見えない状態か確認する
  3. WSLの場合はwsl --list --verboseでWSL 2か確認する
  4. Windows 11のバージョンと更新履歴を確認する
  5. 一時回避策でグループポリシーを変更していた場合は再有効化する
  6. KB5129195またはそれ以降の累積更新をインストールする
  7. Windowsを再起動する
  8. Linux側から対象フォルダーとマウント情報を確認する
  9. 改善しなければWSL設定、fstab、SMB共有など別の原因を調べる

重要なのは、「Linuxが起動しない問題」と「Linuxは起動するがPlan 9ホスト共有だけが使えない問題」を分けて考えることです。

今回の条件に一致するなら、Linuxディストリビューションの再インストールやネットワーク共有の再設定を始める前に、Windows側へ修正済みの累積更新が適用されているか確認してください。
[1]: https://learn.microsoft.com/en-us/windows/release-health/status-windows-11-25h2 “Windows 11, version 25H2 known issues and notifications | Microsoft Learn”
[2]: https://learn.microsoft.com/en-us/windows/wsl/compare-versions “Comparing WSL Versions | Microsoft Learn”
[3]: https://support.microsoft.com/en-us/servicing/os/windows-11/2026/09/kb5129195-windows-11-24h2-25h2-security-update “September 14, 2026—KB5129195 (OS Builds 26200.9457 and 26100.9457) Out-of-band | Microsoft Support”
[4]: https://learn.microsoft.com/en-us/windows/wsl/basic-commands “Basic commands for WSL | Microsoft Learn”

Windows11
Hyper-V Windows 11 WSL Host Compute Service

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次