Automount tries to mount inaccessible drives

[shoffmeister]

Version

Microsoft Windows [Version 10.0.22621.608]

WSL Version

• WSL 2
• WSL 1

Kernel Version

5.10.102.1

Distro Version

Ubuntu 22.04

Other Software

Google Drive

Repro Steps

• naked Windows 11 Pro installation
• create user1
• install Google Drive for user1; authenticate

--> user1 now has access to Google Drive data on drive G: (the default drive configured by Google Drive)

• install Ubuntu 22.04
  // works fine

• create user2, log into user2
  // do note that local disk G: (see above - Google Drive) is not accessible to user2 (because it is tied to user1)

• install Ubuntu 22.04

• start Ubuntu 22.04

--> init: (1) ERROR: MountPlan9WithRetry:285: mount drvfs on /mnt/g ... path=G:\ ... failed: 13

Expected Behavior

Automount should not attempt to mount inaccessible drives; Windows 11 Pro itself reports

which is totally correct and fair.

With Automount not attempting mount that drive, there will be no error message (expected behaviour)

Actual Behavior

Error message in console: An error occurred mounting one of your file systems. Please run 'dmesg' for more details.

dmesg contains init: (1) ERROR: MountPlan9WithRetry:285: mount drvfs on /mnt/g ... path=G:\ ... failed: 13

Diagnostic Logs

No response

[shoffmeister]

Note that failure to mount is discussed extensively in #7565.

This here is an actionable request to fix the automounter in the specific case where the Windows user (user2) has no access to the drive (on the Windows side). It simply does not make sense to automount any such device (on the Linux side).

[Vinfall]

Quoted from claudiusraphael in #7435:

This affects:

• network drives, samba shares, nfs
• drives not recognized by Windows due to filesystems like zfs, btrfs, etc.
• drives not recognized by Windows due to partition-id, no matter the content is readable

It also contradicts the default configuration for Windows developer-setup, namely show empty drives, which are automatically assigned drive-letters and can not be disabled anymore.

This is a BUG. Period.

If automagic recognition of mounts is enabled by default (which brings a whole bag of issues as it effectively works against the sandboxing-approach wsl is based on) there must be either full recognition on the host side, so the client can not fail, or it must be a sane preconfigured set. The fact that it even attempts to scan and access anything besides a separate directory in the users tree is scary, but on the other hand not allowing the use of host filesystemdrivers for extfs, btrfs, zfs, etc. and not allowing to map a partition to wsl that is set on the host drive is just nonsense.

The root cause for ALL of these is WSL's problematic yet invasive default setting of automounting ANY disk with an assigned drive letter, despite Windows' incapability of mounting such filesystems.

Solve this single issue would immediately close these issues as they are just different symptoms of the same bug:

• network drives: Network drive not being auto mounted #6289
• encrypted drives: An error occurred mounting one of your file systems. Please run 'dmesg' for more details. #7435, An error occurred mounting one of your file systems. Please run 'dmesg' for more details. #7565
• unrecognized filesystems: WSL automount failure #4101 (maybe),WSL2 keeps trying (and fails) to mount ESP partition #9122

Two solution I think would work:

1. not automount unrecognized disk on Windows side (just by detecting whether Windows can recognize it)
2. enhance Windows capability for mounting various filesystem & network drives (the panacea, but would require a lot more work)

[Svetoslav92]

I want to argue with this one because I have similar scenario and makes my WSL2 unusable for what I want.
I want to mount ext2 partition which is inaccessible from Windows. Yes, you discovered the --mount option but it is lacking the ability to disable caching. If I edit text file from wsl shared path from windows it does not get reflected until some kind of buffer fills up. Because I edit only text files this buffer will fill up in a year time in order to flush it to the disk - just unusable. That's why I tried to mount the drive from within WSL with the mount statement (plus -o sync) but since the disk in windows is detected as unformatted it wants me to initialize it first before be able to assign drive letter (which will format the disk unwantedly to NTFS etc). Drive letter which is a must inside WSL mount.
So I am stuck with the --mount option without a chance to remove the buffer/cache.
Does anyone know if it is possible to use mount() which is as I can see the base function behind the linux mount and use it, by providing hard disk address etc but not drive letter?

[microsoft-github-policy-service]

This issue has been automatically closed since it has not had any activity for the past year. If you're still experiencing this issue please re-file this as a new issue or feature request.

Thank you!