missing Dev Drive WSL limitations for `metadata`

[diablodale]

At https://learn.microsoft.com/en-us/windows/dev-drive/#does-dev-drive-work-with-wsl-project-files I think a major limitation exists. By reverse-engineering the logic written across several paragraphs/pages...and then testing myself...it appears that

1. dev drives are ReFS
2. ReFS does not support extended attributes on files
3. WSL2's metadata mount feature needs extended attributes on files to implement *nix chmod user/group/other permissions
4. Therefore, WSL2 silently fails to set permissions correctly on all file hosted by a Dev Drive.

I verified this limitation on Microsoft Windows [Version 10.0.22621.2428], WSL2 Ubuntu 20.04, and dev drive

---

Document Details

⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

• ID: bfda7965-bc34-ab88-fdc9-efef4a5d8a9e
• Version Independent ID: bfda7965-bc34-ab88-fdc9-efef4a5d8a9e
• Content: Set up a Dev Drive on Windows 11
• Content Source: hub/dev-drive/index.md
• Product: dev-environment
• Technology: windows-devhome
• GitHub Login: @mattwojo
• Microsoft Alias: mattwoj

[mattwojo]

Thanks for filing this @diablodale. I just asked a few members of the team about this. It was pointed out that ReFS does now support extended attributes on files in Windows 11.
To clarify, we don't recommend hosting files on Dev Drives for use with distros installed via WSL.. it's not designed for performance gains under that scenario. But are you asking if it's even possible to access files that are stored in a Dev Drive hosted on Windows from a WSL distro? This is saying that you're seeing failures using a distro running with WSL2 when you try to access a file hosted on a Dev Drive on your Windows file system? Trying to find someone to do some testing, but if you can add any more info to help clarify the scenario, would be helpful just to ensure we're understanding the isssue correctly.
Thanks again!

[diablodale]

The failures are 3 and 4 above. The chmod permissions were not correctly set. They were ignored.
The ignoring of WSL chmod permissions is not atypical. It was a behavior of WSL1 and continued for ?years? until Windows added WSL extended attribute support on NTFS. But such did not exist for ReFS. So the old WSL permission problem again reproduced.

Since I opened this issue, windows update has delivered Win 11 23H2 + a november patch. I will setup a repo case today to see if those new bits have corrected the issue. And I will document the setup steps if it reproduces and list them in another post here.

Yes, it is clear from the docs that the "dev drive" is not perf designed for access from WSL. But we (as a development community) are not Windows-only. The 90s are gone ;-) The ability to access files on any partition anywhere is a modern requirement. Non-performant access is a reasonable tradeoff. (It is that way already with WSL's plan9 access to NTFS).

[diablodale]

The permission problem continues to exist.

Setup

• Microsoft Windows [Version 10.0.22631.2506] aka Win11 23H2 with updates
• WSL2 with Ubuntu 20.04 LTS distro

Repro

1. Install Windows as above
2. Enable WSL2
3. Install Ubuntu 20.04 distro from msft store
4. Launch Ubuntu 20.04
5. Edit /etc/wsl.conf https://learn.microsoft.com/en-us/windows/wsl/wsl-config#automount-settings to include

   [automount]
   options = "fmask=0027,dmask=0027,metadata"
   

6. Windows menu, dev drive, click "create a dev drive"
7. click CREATE VHD at the top. 😉yes...start with VHD
8. name=ntfs1, location=c:, size=55gb, choose vhdx, choose dynamically, click create
9. choose GPT, click initialize
10. label=ntfs1a, driveletter=K, NTFS is the only choice, click format
11. Windows menu, dev drive, click "create a dev drive"
12. click CREATE DEV DRIVE at the top 👍Now choose dev drive
13. click CREATE NEW VHD, click next
14. name=refs1, location=c:, size=55GB, choose vhdx, choose dynamically, click create
15. choose GPT, click initialize
16. label=refs1a, driveletter=R, click format
17. Verify you see both drive K (NTFS) and drive R (ReFS dev drive)
18. open a command prompt and type wsl --shutdown
19. wait 10 seconds
20. launch ubuntu 20.04
21. verify you see both K and R mounted with the f/dmask and metadata from step 5.

$ mount | grep K:
drvfs on /mnt/k type 9p (rw,noatime,dirsync,aname=drvfs;path=K:\;uid=1000;gid=1000;fmask=0027;dmask=0027;metadata;symlinkroot=/mnt/,mmap,access=client,msize=262144,trans=virtio)
$ mount | grep R:
drvfs on /mnt/r type 9p (rw,noatime,dirsync,aname=drvfs;path=R:\;uid=1000;gid=1000;fmask=0027;dmask=0027;metadata;symlinkroot=/mnt/,mmap,access=client,msize=262144,trans=virtio)

22. go into each mounted folder for K and R. Create a file, chmod it, and verify the chmod is correctly applied.

Result

Chmod permissions are incorrectly applied to files on the ReFS Dev Drive.
in constrast, they are correctly applied on NTFS.

$ cd /mnt/k
$ echo "hello" > testntfs.txt
$ chmod 666 testntfs.txt
$ ls -l testntfs.txt
-rw-rw-rw- 1 dale dale 6 Nov  8 16:59 testntfs.txt         <--- correct

$ cd /mnt/r
$ echo "hello" > testrefs.txt
$ chmod 666 testrefs.txt
$ ls -l testrefs.txt
-rwxr-x--- 1 dale dale 6 Nov  8 17:00 testrefs.txt         <--- wrong

Expected

The chmod permissions on both files above should be 666 -rw-rw-rw-

[mattwojo]

These are really helpful details - thanks @diablodale! I've shared this with the engineering team and it sounds like it's a compat issue related to ReFS. They are investigating and I'll make sure that updates are shared once I'm aware of any. Thanks again.

[AdamBraden]

@craigloewen-msft - can you close the loop with the WSL team on this issue?