Fix virtiofs bind mounts exposing files as root-owned (#40719)

[Stephen Halter (halter73)]

Add the 'metadata' option to virtiofs shares created via HcsVirtualMachine::AddShare (the WSLC/Docker container path). Without this option, the virtiofs device host cannot persist per-file uid/gid in NTFS extended attributes, so all files default to uid=0/gid=0 regardless of the creating user.

This matches the behavior of the regular distro mount path (WslCoreVm::AddVirtioFsShare) which receives metadata/uid/gid options from the Linux init's ConvertDrvfsMountOptionsToPlan9.

Also adds a regression test (WindowsMountsVirtioFsFileOwnership) that verifies file ownership is preserved on virtiofs mounts.

Fixes #40719

Summary of the Pull Request

Fix virtiofs bind mounts exposing all files as root-owned when used via WSLC containers (e.g., Docker Desktop bind mounts). Add metadata to the virtiofs share options in HcsVirtualMachine::AddShare so the device host persists per-file uid/gid in NTFS extended attributes.

PR Checklist

• Closes: virtiofs=true: file created by non-root user on Windows bind mount is exposed as root-owned and cannot be reopened for write #40719
• Communication: I've discussed this with core contributors already. If work hasn't been agreed, this work might be rejected
• Tests: Added/updated if needed and all pass
• Localization: All end user facing strings can be localized
• Dev docs: Added/updated if needed
• Documentation updated: If checked, please file a pull request on our docs repo and link it here: #xxx

Detailed Description of the Pull Request / Additional comments

When virtiofs=true is set in .wslconfig, Docker bind mounts go through HcsVirtualMachine::AddShare which creates a virtiofs device for the shared Windows folder. Previously, the options passed to the device were just "ro" (read-only) or "" (read-write) — missing the metadata option.

Without metadata, the virtiofs device host (wsldevicehost.dll) cannot store per-file ownership in NTFS extended attributes. All files appear as uid=0 gid=0 regardless of which user created them, and non-root users cannot reopen files they just created.

The regular distro drvfs mount path (MountVirtioFs → WslCoreVm::AddVirtioFsShare) already receives metadata/uid/gid options from the Linux init's ConvertDrvfsMountOptionsToPlan9, which is why standard /mnt/c mounts work correctly with virtiofs. The WSLC container path was simply missing this option.

Fix: Change line 583 of HcsVirtualMachine.cpp:

// Before:
std::wstring options = ReadOnly ? L"ro" : L"";
// After:
std::wstring options = ReadOnly ? L"ro;metadata" : L"metadata";

Validation Steps Performed

1. Reproduced the bug using the exact Docker repro steps from virtiofs=true: file created by non-root user on Windows bind mount is exposed as root-owned and cannot be reopened for write #40719 on WSL 2.7.3.0 / Docker 29.5.2 / Windows 10.0.26200.8390. Confirmed files show uid=0 gid=0 with virtiofs and correct ownership with 9p fallback.

2. Verified the fix by deploying the patched wslservice.exe and re-running the repro — files now retain the creating user's uid/gid.

3. Added regression test WSLC_TEST_METHOD(WindowsMountsVirtioFsFileOwnership) in WSLCTests.cpp that:

   • Mounts a Windows folder with virtiofs enabled
   • Creates a file and chowns to uid 1000:100, then verifies stat reports 1000 100
   • Uses su nobody to create a file as uid 65534, then verifies ownership is 65534

4. Confirmed test fails on current main (stat reports 0 0 without the fix) and passes with the fix.

5. Build verification: Both wslservice.exe and wsltests.dll compile successfully.

[Copilot]

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

Enable VirtioFS metadata option for Windows folder mounts so Linux file ownership (uid/gid) is persisted, and add a regression test validating ownership preservation.

Changes:

• Always include metadata in VirtioFS mount options (including read-only mounts).
• Add a Windows test that validates chown persistence and non-root file creation ownership on a VirtioFS-mounted Windows folder.

Show a summary per file

File	Description
test/windows/WSLCTests.cpp	Adds a regression test validating VirtioFS ownership persistence for chown and non-root file creation.
src/windows/service/exe/HcsVirtualMachine.cpp	Ensures VirtioFS mount options include metadata so ownership is preserved.

Copilot's findings

• Files reviewed: 2/2 changed files
• Comments generated: 3

[Blue (OneBlue)]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[Blue (OneBlue)]

The new test failed in the CI:

Command: /bin/sh -c rm -f /virtiofs-ownership-test/nonroot.txt && su -s /bin/sh '#65534' -c 'touch /virtiofs-ownership-test/nonroot.txt' && stat -c '%u' /virtiofs-ownership-test/nonroot.txt didn't return expected code (0). ExitCode: 1, Stdout: '', Stderr: 'su: user #65534 does not exist or the user entry does not contain all the required fields '

I think the easiest fix here would be to use the nobody account since it's already available in the VHD

[Stephen Halter (halter73)]

/azp run

[azure-pipelines]

Commenter does not have sufficient privileges for PR 40733 in repo microsoft/WSL

[Copilot]

Copilot's findings

• Files reviewed: 2/2 changed files
• Comments generated: 5

[Blue (OneBlue)]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[Blue (OneBlue)]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[Copilot]

Review details

• Files reviewed: 2/2 changed files
• Comments generated: 1
• Review effort level: Low

[Blue (OneBlue)]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[Copilot]

Review details

• Files reviewed: 2/2 changed files
• Comments generated: 0 new
• Review effort level: Low

[Stephen Halter (halter73)]

Blue (@OneBlue) The CI was green, so I probably should have left it, but I decided to address the Copilot PR feedback. Do you mind kicking it again?

[Blue (OneBlue)]

/azp run

[Blue (OneBlue)]

LGTM, thank you !

[Blue (OneBlue)]

/azp run

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[Copilot]

Pull request overview

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

Suppressed comments (2)

test/windows/WSLCTests.cpp:3879

• This unmount call omits the AcquireVmLease argument, while other tests pass it explicitly. Passing TRUE here avoids depending on an implicit default and keeps lease semantics consistent across the mount tests.

        VERIFY_ARE_EQUAL(result.Output[1], std::string("65534\n"));

        VERIFY_SUCCEEDED(session->UnmountWindowsFolder(mountPoint));
    }

test/windows/WSLCTests.cpp:3851

• This mount call omits the AcquireVmLease argument, unlike other Windows mount tests in this file which pass it explicitly (e.g., ..., TRUE). Relying on an implicit default here makes the test’s VM/lease behavior ambiguous and can change if the interface signature/defaults change. Pass TRUE explicitly to match the established pattern.

This issue also appears on line 3876 of the same file.

        static constexpr auto mountPoint = "/virtiofs-ownership-test";

        VERIFY_SUCCEEDED(session->MountWindowsFolder(testFolder.c_str(), mountPoint, false));

[Blue (OneBlue)]

Apologies Stephen Halter (@halter73), I was too slow to merge this, and now the change got conflicted. Do you mind refreshing your branch ? I will prioritize merging this once done

[Copilot]

Review details

Suppressed comments (1)

test/windows/WSLCTests.cpp:3928

• UnmountWindowsFolder is also called without the AcquireVmLease parameter, unlike other mount tests in this file which pass TRUE. Make this explicit for consistency and to avoid depending on a default argument (see wslc.idl:750).

        VERIFY_SUCCEEDED(session->UnmountWindowsFolder(mountPoint));

• Files reviewed: 2/2 changed files
• Comments generated: 1
• Review effort level: Lite

[Blue (OneBlue)]

/azp run

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[Copilot]

Review details

Suppressed comments (1)

test/windows/WSLCTests.cpp:3901

• The new regression test doesn’t verify that the mounted filesystem is actually virtiofs. If the environment falls back to 9p/plan9 for any reason, the ownership assertions can still pass and the test won’t catch regressions in the virtiofs path. Also, the scope-exit cleanup calls throwing std::filesystem::remove_all in a destructor context; using the error_code overload avoids terminate-on-throw during cleanup (and makes failures non-fatal).

        auto testFolder = std::filesystem::current_path() / "test-folder-virtiofs-ownership";
        std::filesystem::create_directories(testFolder);
        auto cleanup = wil::scope_exit_log(WI_DIAGNOSTICS_INFO, [&]() { std::filesystem::remove_all(testFolder); });

        static constexpr auto mountPoint = "/virtiofs-ownership-test";

        VERIFY_SUCCEEDED(session->MountWindowsFolder(testFolder.c_str(), mountPoint, false, TRUE));

• Files reviewed: 2/2 changed files
• Comments generated: 0 new
• Review effort level: Lite

[Blue (OneBlue)]

/azp run

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[Stephen Halter (halter73)]

Blue (@OneBlue) I think this is green again. Do you need anything else from me?

[etrinh]

I dream this fix will one day improve virtiofs on wsl2 usability...
Meanwhile, docker VMM virtiofs integration is incredible...

[Blue (OneBlue)]

Sorry for the delay, this is merged now !