Skip to content

Start the plan9 server on WSL2 even when automount and mountFsTab are…#41057

Open
Lsseeker wants to merge 2 commits into
microsoft:masterfrom
Lsseeker:patch-1
Open

Start the plan9 server on WSL2 even when automount and mountFsTab are…#41057
Lsseeker wants to merge 2 commits into
microsoft:masterfrom
Lsseeker:patch-1

Conversation

@Lsseeker

Copy link
Copy Markdown

Fixes #41056

On WSL2, when /etc/wsl.conf has both automount.enabled = false and
automount.mountFsTab = false, init never starts the plan9 file server, so
\\wsl.localhost\<distro> / \\wsl$\<distro> are inaccessible.

The guard in ConfigInitializeInstance() requires
(Config.AutoMount || Config.MountFsTab) because the server "requires a DrvFs
mount for the socket file". That rationale only applies to WSL1: on WSL2,
StartPlan9Server() binds an hvsocket (UtilBindVsockAnyPort) and never uses
the socket path — the initialize message carries an empty Plan9SocketOffset
(see the trace excerpt in #41056).

This change exempts WSL2 (UtilIsUtilityVm()) from the mount requirement:

  • WSL1 behavior is unchanged.
  • WSL2 with this configuration now takes exactly the same code path as the
    default configuration (where automount is enabled and the server starts).
  • Anyone intentionally relying on this option combination to disable the 9p
    server can use the dedicated setting (Config.Plan9Enabled) instead.

Testing: verified by code inspection and the ETW trace attached to #41056
(LxInitMessageInitializeResponse carries
Plan9Port = LX_INIT_UTILITY_VM_INVALID_PORT while FeatureFlags = 0). I
don't currently have a local build environment, so this has not been build- or
runtime-tested on my side — happy to add a regression test if you can point me
at the right harness.

… disabled

The (AutoMount || MountFsTab) guard exists because on WSL1 the plan9
socket file lives on a DrvFs mount. WSL2 serves over an hvsocket and
never uses the socket path, so the guard unintentionally disabled
\\wsl.localhost access for distros with both options turned off.

Fixes microsoft#41056
@Lsseeker Lsseeker requested a review from a team as a code owner July 11, 2026 10:54
Copilot AI review requested due to automatic review settings July 11, 2026 10:54
@Lsseeker

Copy link
Copy Markdown
Author

@microsoft-github-policy-service agree

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR fixes a WSL2 regression where disabling both automount.enabled and automount.mountFsTab prevents init from starting the Plan9 server, making \\wsl.localhost\<distro> / \\wsl$\<distro> inaccessible. It updates the Plan9-server startup guard so WSL2 (utility VM) no longer depends on DrvFs mount-related settings that only matter for WSL1.

Changes:

  • Update the Plan9 server start condition to allow WSL2 (UtilIsUtilityVm()) even when AutoMount and MountFsTab are both false.
  • Update the surrounding comment to clarify the WSL1-only DrvFs socket-path dependency.

Comment thread src/linux/init/config.cpp Outdated
Comment thread src/linux/init/config.cpp Outdated
Updated comments for clarity regarding Plan 9 server requirements on WSL1 and WSL2.
Copilot AI review requested due to automatic review settings July 11, 2026 11:02

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Plan9 file server is never started on WSL2 when both automount.enabled and automount.mountFsTab are false, making \\wsl.localhost inaccessible

2 participants