Cannot access btrfs drive from Windows

[Hashbrown777]

Environment

Windows build number: Microsoft Windows [Version 10.0.21337.1010]
Your Distribution version: Release:        10
Whether the issue is on WSL 2 and/or WSL 1: Linux version 5.4.91-microsoft-standard-WSL2 (oe-user@oe-host) (gcc version 9.3.0 (GCC)) #1 SMP Mon Jan 25 18:39:31 UTC 2021

Steps to reproduce

• give wsl a disk wsl --mount \\.\PHYSICALDRIVE1 --bare
• format it in btrfs sudo mkfs.btrfs /dev/sdc
• mount the filesystem sudo mount -o ssd,noatime,space_cache,commit=120,compress /dev/sdc /mnt/test
• optional, be incredibly liberal with permissions chown $USERNAME:$USERNAME /mnt/test; chmod ugo+rwx /mnt/test
• attempt to open \\wsl$\Debian\mnt\test in explorer

WSL logs: wsl.etl.log

Expected behavior

Windows has access to the btrfs drive.

Actual behavior

"is not accessible. You might not have permission to use this network resource. Contact the administrator of this server to find out if you have access permissions.

Attempt to access invalid address."

The exact same issue was reported on the original blogpost about --mount but the fix is sshfs-specific

[OneBlue]

Thanks for the reporting this @Hashbrown777.

So I see the chmod command running on /mnt/test, but the explorer error message is about /mnt/sneak. Can you share the output of ls -la /mnt/sneak to validate that the permissions on that folder are correct ?

On top of that, when mounting disks manually with mount, the non-elevated mount namespace needs to be used for the mountpoint to be accessible in the Windows explorer.

More details here.

[Hashbrown777]

Hi @OneBlue
Unfortunately it has to be done with root

The access to the directory tree higher up is fine, explorer can open the directory fine once umounted, atop this I mounted directly to /sneak and ~/sneak and both fail.

The same is true of \\wsl$\Debian\home\hashbrown if the $ makes any difference.

[Hashbrown777]

Ah yes, test was just a part of the cutdown steps for others to repro, sneak is what I was actually calling it (and in the real case it's mounted from luks-cryptopen's dev-mapper but the repro steps say dev-sdc; but this isn't a part of the issue if you follow the repro steps yourself).

You could probably get the bug if you create a fake block device as a file in linux, and format that as btrfs, no need for wsl --mount at all, but I haven't tried.

[OneBlue]

@Hashbrown777 : Makes sense.

Have you tried mounting your drive under /mnt/wsl as suggested here ?

(detailed explanations on the issue).

[Hashbrown777]

@OneBlue
Same issue unfortunately

[OneBlue]

Interesting, because it looks like you can access the parent folder, let's validate that this isn't a permission issue.

Can you share the output of:

ls -la /mnt/wsl

If your WSL user doesn't have access to that folder, adding: -o "uid=$USER" should do the trick

[Hashbrown777]

@OneBlue I think the easiest way for you check these suggestions is to test them yourself

.{
	$location = '/mnt/wsl'
	$mount = "$location/test"
	$device = '~/test.img'

	'Mount?'
	pause
	bash -c (@"
		sudo rm -rf $mount $device 2>/dev/null
		fallocate -l 1G $device
		sudo mkfs.btrfs -f $device
		sudo mkdir $mount
		sudo chown -R `$USER $mount
		chmod ugo+rwx $mount
		sudo mount \
			-o ssd,noatime,space_cache,commit=120,compress \
			$device \
			$mount
		sudo chown -R `$USER $mount
		chmod ugo+rwx -R $mount
		ls -la $mount $mount/..
		df -T | grep 'btrfs'
	"@ -replace '\r','')

	'Test access?'
	pause
	explorer "\\wsl$\$(
		wsl -l `
		| %{ $_ -replace '\x00','' } `
		| ?{ $_ -match '^.+(?=\s+\(Default\)$)' } `
		| %{ $Matches.Values }
	)$($mount -replace '/','\')"
	explorer "\\wsl$\$(
		wsl -l `
		| %{ $_ -replace '\x00','' } `
		| ?{ $_ -match '^.+(?=\s+\(Default\)$)' } `
		| %{ $Matches.Values }
	)$($location -replace '/','\')"

	'Unmount?'
	pause
	bash -c "sudo umount $mount;rm $device"
	
	explorer "\\wsl$\$(
		wsl -l `
		| %{ $_ -replace '\x00','' } `
		| ?{ $_ -match '^.+(?=\s+\(Default\)$)' } `
		| %{ $Matches.Values }
	)$($mount -replace '/','\')"
}

This will;

1. create a file device,
2. format it with btrfs,
3. mount it at the given location,
4. make sure everyone has access and it's owned by the user,
5. show the permissions of the mount and its parent,
6. attempt to open the folder in explorer (fails, opens 'Documents'),
7. opens the parent in explorer (to let you click on test yourself, generating the error message),
8. unmounts and cleans up, and finally
9. proves there's nothing wrong with permissions by opening up the unmounted folder in-position within explorer

Let me know if you make any progress, ta

After unmounting

[OneBlue]

@Hashbrown777 : Indeed I can repro the same behavior.

I'll have a deeper look and update this issue when I'll have more info.

[OneBlue]

@Hashbrown777: The root cause is an issue in the plan9 server running inside WSL.

The problem was that when a mountpoint is accessed, the code would check for the device on which the file is, and fail if no matching mountpoint is found in /proc/self/mountinfo (and that appears to be the case for btrfs mounts). The reason for that logic is to prevent access to drvfs shares ( /mnt/X ) from the linux 9p server.

So we made a code change to not disallow file accesses on this scenario, which solves this issue.
The fix will now work its way through the Windows release pipeline and will eventually reach a future insider build.

[bpulliam]

The fix is incoming, but will be in the next Insider switch.

[Hashbrown777]

Do we know when this might be coming? Is the fix in the [wsl] kernel we can compile ourselves?

I've pulled the latest kernel from git since Win11 dropped on my insider machine, re-installed btrfs-progs, tried accessing through \\wsl\, \\wsl$\ & [a new one I just discovered] \\wsl.localhost\ and also mounting within /mnt/wslg but still no luck.

When is "the next Insider switch", @bpulliam. Is there a timeframe for it "work[ing] its way through the Windows release pipeline" @OneBlue?

[Hashbrown777]

Still non-functional in Win 11 21H2 Insider Build 22000.168

Any updates?

[OneBlue]

@Hashbrown777: Unfortunately the fix still hasn't made it to insider builds. It will hopefully be in the next one.

[Hashbrown777]

Yesterday I received a Windows Subsystem for Linux WSLg Preview - 1.0.27 update, and it's working now.

So now the host machine has access to the btrfs mounts via P9, but I can't see a way to let other machines on the network see it. I'm guessing there's no way for the host to re-share, forward, or expose WSL2 shares?

I was hoping to leverage the efficiency you guys have made with the direct P9 and not have to host samba or tunnel through ssh..
We can access WSL2 mounts via \\wsl.localhost\: is this a planned enhancement to be able to do something like \\wsl.otherHost\?

I'm having other issues with disks disconnecting, and such, but they're not related to this issue.

[OneBlue]

There aren't any plans to do something like that right now. \wsl.localhost only resolves in the current machine and isn't at all exposed at the networking level.

Exposing this to other machines would require an actual networking protocol, with all the authentication & security requirements that this would imply.

Overall if you wish to share a wsl mountpoint to other machines, I'd recommend looking at ssh tunnels or samba as you mentioned (nfs and sftp might also be valid options, maybe with better performance if you want to remotely access those mountpoints from wsl).

[jpeeler]

@OneBlue Sorry to comment on a closed issue, but did this fix make it to non-insider builds (running 22000.376)? I'm experiencing the same error. Using a raid1 mirror if that matters.

[OneBlue]

@PEELER: Yes the fix should be on that build. If you're seeing this issue can you detail repro steps and share logs ?

[jpeeler]

Thanks for the quick response! https://aka.ms/AAfe74a

The terminal commands are as follows:

wsl --mount \\.\PHYSICALDRIVE0 --bare
wsl --mount \\.\PHYSICALDRIVE1 --bare

Start Ubuntu 20.04:

$ cd /mnt/wsl
$ mkdir mymnt
$ lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0   256G  0 disk
sdb      8:16   0 339.8M  1 disk
sdc      8:32   0   7.3T  0 disk
└─sdc1   8:33   0   7.3T  0 part
sdd      8:48   0   7.3T  0 disk
└─sdd1   8:49   0   7.3T  0 part
sde      8:64   0   256G  0 disk /
$ sudo btrfs filesystem show
Label: 'btrfs1'  uuid: 33d49740-da04-403b-b6df-89dcc63a4dc3
        Total devices 2 FS bytes used 1.91TiB
        devid    1 size 7.28TiB used 1.91TiB path /dev/sdd1
        devid    2 size 7.28TiB used 1.91TiB path /dev/sdc1
$ sudo btrfs device scan
$ sudo mount /dev/sdc1 mymnt/
$ ls -l
total 20
drwxr-xr-x 1 jpeeler jpeeler 188 Jan  5 20:08 mymnt
-rw-r--r-- 1 root    root    197 Jan  5 21:43 resolv.conf
$ ls -l mymnt/
... (files are present)

When navigating to \\wsl.localhost\Ubuntu-20.04\mnt\wsl\mymnt, get the error "attempt to access invalid address."

[0xr0bert]

This happens to me as well!

[OneBlue]

Thanks for the logs @jpeeler.

Actually, it turns out that the fix is not on your build yet, sorry for the miscommunication.

To work around this, you could install the latest WSL from the store, which has the fix.

[jpeeler]

Yes, that did solve the problem.

Unfortunately, using the same hardware with an older (but up to date) install I get the error as presented on #7527. If you're willing to continue to assist, I can upload logs there just as I did here.

(Edit: commented on the issue with a workaround.)

[OneBlue]

Interesting, can you share the output you get with logs ? I'd be curious to have a look at it.

[Natetronn]

Thanks for the logs @jpeeler.

Actually, it turns out that the fix is not on your build yet, sorry for the miscommunication.

To work around this, you could install the latest WSL from the store, which has the fix.

I had this issue as well and can confirm installing WSL Preview fixed the issue. I can now see the @ and @home etc. from within File Explorer (whereas before I could only access those directories via WSL itself.)

Thank you!