search

MicrosoftDocs / windows-dev-docs

Conceptual and overview content for developing Windows apps
Creative Commons Attribution 4.0 International
682 stars 1.19k forks source link

missing Dev Drive WSL limitations for `metadata` #4680

Open diablodale opened 11 months ago

diablodale commented 11 months ago

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.

mattwojo commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

The permission problem continues to exist.

Setup

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 commented 10 months ago

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 commented 4 weeks ago

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