`virtiofs=true`: file created by non-root user on Windows bind mount is exposed as root-owned and cannot be reopened for write

[halter73]

Windows Version

Microsoft Windows [Version 10.0.26200.8457]

WSL Version

2.7.7.0

Are you using WSL 1 or WSL 2?

• WSL 2
• WSL 1

Kernel Version

6.18.26.1-1

Distro Version

No response

Other Software

Docker Desktop 4.76.0 (228118)
Docker Engine 29.5.2

Repro Steps

Set %USERPROFILE%\.wslconfig:

[wsl2]
virtiofs=true

Restart WSL:

wsl --shutdown

From a PowerShell prompt in any Windows directory, create a local repro directory:

$repro = Join-Path (Get-Location) 'wsl-virtiofs-repro'
New-Item -ItemType Directory -Force -Path (Join-Path $repro 'data') | Out-Null

Run this container as UID 1000:

docker run --rm -u 1000:100 --mount "type=bind,source=$repro,target=/config" alpine sh -c 'id; mount | grep " /config "; f=/config/data/file-to-reopen.txt; rm -f "$f" 2>/dev/null || true; printf first > "$f"; echo after_create; ls -ln "$f"; if printf second >> "$f"; then echo append=ok; else echo append=failed; fi; echo after_append_attempt; ls -ln "$f"; printf "contents="; cat "$f"; echo'

Expected Behavior

The file created by UID 1000 should remain writable by UID 1000, or the mount should otherwise preserve behavior compatible with the default Windows-backed WSL/Docker bind mount path.

With virtiofs=true commented out and WSL restarted, the same command succeeds. The Windows drive letter in the mount output is generalized below:

uid=1000 gid=100(users) groups=100(users)
<Windows drive> on /config type 9p (rw,noatime,aname=drvfs;path=<Windows drive>\;uid=0;gid=0;metadata;symlinkroot=/mnt/host/,cache=0x5,access=client,msize=65536,trans=fd,rfd=5,wfd=5)
after_create
-rw-r--r--    1 1000     100              5 Jun  5 19:33 /config/data/file-to-reopen.txt
append=ok
after_append_attempt
-rw-r--r--    1 1000     100             11 Jun  5 19:33 /config/data/file-to-reopen.txt
contents=firstsecond

Actual Behavior

With virtiofs=true, the file is created, but it is immediately exposed as root:root with mode 0644. The same UID that created it cannot reopen it for append/write:

uid=1000 gid=100(users) groups=100(users)
60d56c4b-d352-468b-8ba2-4a96cfd9b211 on /config type virtiofs (rw,noatime)
after_create
-rw-r--r--    1 0        0                5 Jun  5 19:32 /config/data/file-to-reopen.txt
append=failed
after_append_attempt
-rw-r--r--    1 0        0                5 Jun  5 19:32 /config/data/file-to-reopen.txt
contents=first
sh: can't create /config/data/file-to-reopen.txt: Permission denied

Diagnostic Logs

WslLogs-2026-06-05_13-23-13.tar.gz

[github-actions]

Logs are required for review from WSL team

If this a feature request, please reply with '/feature'. If this is a question, reply with '/question'.
Otherwise, please attach logs by following the instructions below, your issue will not be reviewed unless they are added. These logs will help us understand what is going on in your machine.

How to collect WSL logs

Download and execute collect-wsl-logs.ps1 in an administrative powershell prompt:

Invoke-WebRequest -UseBasicParsing "https://raw.githubusercontent.com/microsoft/WSL/master/diagnostics/collect-wsl-logs.ps1" -OutFile collect-wsl-logs.ps1
Set-ExecutionPolicy Bypass -Scope Process -Force
.\collect-wsl-logs.ps1

The script will output the path of the log file once done.

If this is a networking issue, please use .\collect-wsl-logs.ps1 -LogProfile networking instead, following the instructions in Collect WSL logs for networking issues

Once completed please upload the output files to this GitHub issue.

See Collect WSL logs (recommended method).

If you choose to email these logs instead of attaching them to the bug, please send them to wsl-gh-logs@microsoft.com with the GitHub issue number in the subject, and include a link to your GitHub issue comment in the message body, and reply with '/emailed-logs'.

[halter73]

I'm hoping this is a pretty easy repro, but I attached the logs as required.

[github-actions]

Diagnostic information

Issue was edited and new log file was found: https://github.com/user-attachments/files/28652822/WslLogs-2026-06-05_13-23-13.tar.gz
.wslconfig found
Detected appx version: 2.7.7.0

[jzebedee]

I can confirm this same issue, which immediately broke any non-root bind mounts after enabling virtiofs. I expect a lot of people will be ending up here shortly, with the boxofcables article about virtiofs hitting the HN front page.