OmniMend
Confirm the error matches the Plan9 issue
Microsoft describes a narrow problem. After the September Windows security update, host folders shared through Plan9 may not appear inside an HCS-managed Linux virtual machine. The visible message can say that no Plan9 drive shares were mounted. Microsoft names Claude Cowork and WSL as examples of affected workflows.
Keep this fix path for a matching host-share failure. Record the app, exact message, host-folder path, and when the problem began. A recent update is useful timing evidence, but timing alone does not prove that the update caused a different virtual-machine, WSL, storage, permission, or network error.
- Exact Plan9 wording after the September update. Continue with the version and build check.
- A standard Hyper-V virtual machine that does not use Plan9. Microsoft places it outside this known issue.
- A general WSL launch, distribution, or command failure. Keep that symptom separate unless the missing host share and Plan9 message are present.
- The host folder itself is missing, moved, or inaccessible in Windows. Resolve the host-side path or permission issue first.
If the error says something else, preserve the wording. Do not force an unrelated failure into the KB5124008 fix path because the dates look similar.
Record the Windows version and OS build
Before changing the system, open Settings > System > About and record the Windows edition, version, and OS build. You can also run winver and capture the version and build shown there. In Settings > Windows Update > Update history, record the recent KB numbers and installation dates.
Also record the affected app, its version, the virtual-machine or WSL environment it starts, the host folder being shared, and the exact time of one failed attempt. Do not include file contents, access tokens, private repository names, or other sensitive paths in a public report.
The version matters because Microsoft released separate September 14 out-of-band updates. Do not choose a package from the KB number in a forum post or from a nearby build number.
Match the Windows version to Microsoft's update
| Windows 11 version | Microsoft's corrective update | Corrected build |
|---|---|---|
| 24H2 | KB5129195 or a later cumulative update | 26100.9457 or later |
| 25H2 | KB5129195 or a later cumulative update | 26200.9457 or later |
| 26H1 | KB5129194 or a later cumulative update | 28000.2956 or later |
Microsoft's KB5129195 page covers Windows 11 versions 24H2 and 25H2. Its fixed-issues section names the HCS-managed Linux virtual-machine failure in which Plan9 host folders were missing. KB5129194 documents the same correction for version 26H1.
A later cumulative update may replace these exact packages. In that case, use the current supported update for the recorded Windows version and confirm that the resulting OS build meets or exceeds the corrected build. Microsoft's Windows release-health dashboard is the current place to check for a later status change.
Install the current update and retest once
Save work in every open app. Keep a portable computer on reliable power. Open Settings > Windows Update, check for updates, and install the current cumulative update offered for the device. On a managed computer, use the organization's approved update channel and maintenance window.
Use Windows Update by default. Do not download an update from a mirror or choose a Microsoft Update Catalog package by name alone. A manual package must match the Windows version and architecture, and an administrator must account for servicing-stack prerequisites and deployment policy.
Restart when Windows requests it. After sign-in, verify the OS build again. Then open the same affected app and test the same host folder once. Record whether the folder appears, whether the exact Plan9 message returns, and the time of the test.
If the share works, keep the before and after builds and stop changing the environment. The successful retest supports the update path, but it does not prove what happened on every affected PC.
If the same Plan9 error remains
First confirm that the installed build actually meets the corrected number for the recorded version. A downloaded package, pending restart, failed installation, or managed deployment status is not the same as a confirmed build.
If the build is current and the exact error persists, preserve the before and after record. Include the Windows edition, version, OS build, installed KB, app and version, exact message, host-folder path with sensitive parts removed, and one controlled retest result.
Send that record to the app vendor or organization administrator. Check Microsoft's release-health entry and the applicable KB page for later notes. Do not respond to an unchanged result by cycling security updates, rebuilding WSL, unregistering distributions, deleting virtual machines, or moving host data.
If a Windows update itself is stuck, use the Windows 11 update guide. If a driver update caused a different hardware or startup symptom, use the driver-update recovery guide. Those branches do not replace the Plan9 build check.
Keep Docker, WSL, and general share failures separate
Plan9 is the shared-folder mechanism in this specific Microsoft issue. The word can appear near broader Linux virtual-machine tooling, but it does not make every WSL, Docker Desktop, Cowork, or Hyper-V problem the same incident.
A command that returns an executable-format error belongs to a different branch; see the Docker Desktop WSL exec-format guide. A missing network share, denied Windows folder, unavailable drive letter, or standard Hyper-V integration problem also needs its own evidence.
Do not copy registry changes, PowerShell reset sequences, WSL unregister commands, or rollback scripts from a report written before September 14. Microsoft now provides a corrective update for the documented Plan9 failure. The safer current sequence is version, update, confirmed build, restart, and one retest.
Where OmniMend fits
On Windows 11 x64, OmniMend 2.0.9 can organize read-only Windows, update, event, configuration, and retest evidence around this symptom. Diagnosis is read-only. A supported repair inside OmniMend requires approval and a result check.
OmniMend does not install KB5129195 or KB5129194, repair Plan9, restore a host share, reset WSL, manage a virtual machine, fix Cowork, support Windows Arm, or guarantee folder access. Microsoft and the affected app vendor remain the primary sources for the update and product-specific support.
If you want a separate evidence record on a supported Windows x64 PC, review OmniMend's diagnostic scope or download OmniMend. Read the privacy information before sharing any report.
Editorial sources
Checked September 15, 2026 against Microsoft's KB5124008 issue note, KB5129195 update for versions 24H2 and 25H2, KB5129194 update for version 26H1, and Windows release health. Microsoft supplies the affected scope, corrected builds, update route, and September 14 resolution date. A current GitHub report using the same Plan9 wording supports symptom language only; it does not replace Microsoft's cause or remedy. OmniMend added the evidence order, safety limits, privacy notes, and product boundary. This article does not claim that every WSL, virtual-machine, or folder-share failure is the KB5124008 issue.