Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot access Dev Drive files from WSL2 after Windows Update #12156

Open
1 of 2 tasks
kirk-marple opened this issue Oct 11, 2024 · 36 comments
Open
1 of 2 tasks

Cannot access Dev Drive files from WSL2 after Windows Update #12156

kirk-marple opened this issue Oct 11, 2024 · 36 comments

Comments

@kirk-marple
Copy link

Windows Version

Microsoft Windows [Version 10.0.26100.2152]

WSL Version

2.3.24.0

Are you using WSL 1 or WSL 2?

  • WSL 2
  • WSL 1

Kernel Version

5.15.153.1-2

Distro Version

Ubuntu 24.04

Other Software

WSL version: 2.3.24.0
Kernel version: 5.15.153.1-2
WSLg version: 1.0.65
MSRDC version: 1.2.5620
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.26100.1-240331-1435.ge-release
Windows version: 10.0.26100.2152

Repro Steps

For months I've been running WSL2/Ubuntu, and accessing folders on my Win11 Dev Drive through VS Code Remote.

My Win11 laptop rebooted last night, and then today I can't access anything on that Dev Drive through VS Code/WSL2 Remote.

I've tried uninstalling the distro and reinstalling; tried remounting the drive... nothing works.

I see some older bugs similar to this, but they have been closed with no solution.

Expected Behavior

Same access to Dev Drive files using VS Code/WSL2.

Actual Behavior

My d: drive (Dev Drive) is no longer accessible through VS Code/WSL2.

Looking at the mounts, the d: drive is obviously messed up.

kirk@DEV-USSEASUR6:/mnt$ ls -l
total 0
drwxrwxrwx 1 kirk kirk 4096 Oct 11 15:28 c
d--------- 0 kirk kirk    0 Dec 31  1969 d
drwxrwxrwt 2 root root   60 Oct 11 16:13 wsl
drwxrwxrwt 7 root root  300 Oct 11 16:14 wslg

Here's my wsl.conf:

kirk@DEV-USSEASUR6:/mnt$ cat /etc/wsl.conf
[boot]
systemd=true

Diagnostic Logs

Image

VS Code logs:

[2024-10-11 23:28:43.545] Extension version: 0.88.4
[2024-10-11 23:28:43.546] L10N bundle: none
[2024-10-11 23:28:43.575] authorityHierarchy: wsl+ubuntu
[2024-10-11 23:28:43.575] WSL extension activating for a local WSL instance
[2024-10-11 23:28:43.591] Resolving wsl+ubuntu, resolveAttempt: 1
[2024-10-11 23:28:43.591] NodeExecServer run: C:\WINDOWS\System32\wsl.exe --status
[2024-10-11 23:28:43.638] WSL feature installed: true (wsl --status)
[2024-10-11 23:28:43.638] NodeExecServer run: C:\WINDOWS\System32\wsl.exe --list --verbose
[2024-10-11 23:28:43.679] 1 distros found
[2024-10-11 23:28:43.680] Starting VS Code Server inside WSL (wsl2)
[2024-10-11 23:28:43.680] Windows build: 26100. Multi distro support: available. WSL path support: enabled
[2024-10-11 23:28:43.680] Scriptless setup: false
[2024-10-11 23:28:43.680] No shell environment set or found for current distro.
[2024-10-11 23:28:43.776] WSL daemon log file: 
[2024-10-11 23:28:43.778] Connecting to daemon started by other WSL window... 5.15.153.1-microsoft-standard-WSL2 Ubuntu
[2024-10-11 23:28:43.778] WSL resolver response: 127.0.0.1:51854
[2024-10-11 23:28:43.778] To debug connection issues, open a local browser on http://127.0.0.1:51854/version
[2024-10-11 23:28:43.792] NodeExecServer run: C:\WINDOWS\System32\wsl.exe -d Ubuntu -e /home/kirk/.vscode-server/bin/384ff7382de624fb94dbaf6da11977bba1ecd427/node -e const net = require('net'); process.stdin.pause(); const client = net.createConnection({ host: '127.0.0.1', port: 34255 }, () => { client.pipe(process.stdout); process.stdin.pipe(client); }); client.on('close', function (hadError) { console.error(hadError ? 'Remote close with error' : 'Remote close'); process.exit(hadError ? 1 : 0); }); client.on('error', function (err) { process.stderr.write(err && (err.stack || err.message) || String(err)); });
[2024-10-11 23:28:43.868] NodeExecServer run: C:\WINDOWS\System32\wsl.exe -d Ubuntu -e /home/kirk/.vscode-server/bin/384ff7382de624fb94dbaf6da11977bba1ecd427/node -e const net = require('net'); process.stdin.pause(); const client = net.createConnection({ host: '127.0.0.1', port: 34255 }, () => { client.pipe(process.stdout); process.stdin.pipe(client); }); client.on('close', function (hadError) { console.error(hadError ? 'Remote close with error' : 'Remote close'); process.exit(hadError ? 1 : 0); }); client.on('error', function (err) { process.stderr.write(err && (err.stack || err.message) || String(err)); });
[2024-10-11 23:28:44.090] Download in background is enabled
Copy link

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-networking-logs.ps1, following the instructions here

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

Click here for more info on logging
If you choose to email these logs instead of attaching to the bug, please send them to [email protected] with the number of the github issue in the subject, and in the message a link to your comment in the github issue and reply with '/emailed-logs'.

View similar issues

Please view the issues below to see if they solve your problem, and if the issue describes your problem please consider closing this one and thumbs upping the other issue to help us prioritize it!

Open similar issues:

Closed similar issues:

Note: You can give me feedback by thumbs upping or thumbs downing this comment.

@kirk-marple
Copy link
Author

Copy link

Diagnostic information
Detected appx version: 2.3.24.0

@barrettg
Copy link

barrettg commented Oct 14, 2024

I am also experiencing the same sudden loss of drive access. I've even created a new DevDrive to no avail. When I do a directory listing in /mnt it shows odd permissions:

barrettg@BARRETT-CORSAIR:/mnt$ ls -lh
total 0
drwxrwxrwx 1 barrettg barrettg 4.0K Oct 13 09:51 c
d--------- 0 barrettg barrettg    0 Dec 31  1969 d
d--------- 0 barrettg barrettg    0 Dec 31  1969 e
drwxrwxrwt 5 root     root      120 Oct 13 09:51 wsl
drwxrwxrwt 7 root     root      300 Oct 13 09:51 wslg

d and e being DevDrives. If I sudo su to the root user, I can access the mounts. I've tried changing the permissions and it makes no difference.

@apif
Copy link

apif commented Oct 14, 2024

Idem...

@clemlesne
Copy link

Same issue there

@laazik
Copy link

laazik commented Oct 20, 2024

Exact same behaviour. Dev drive is accessible only as root, permissions are completely messed up. Other NTFS drives are working correctly. Also the junction created under NTFS does not work under WSL.

root@DESKTOP-0ME7V3Q:~# ls -l /mnt
total 4
drwxrwxrwx 1 marek marek 4096 Oct 18 04:07 c
drwxrwxrwx 2 root  root  4096 Jun 15  2021 e
d--------- 0 root  root     0 Jan  1  1970 h
drwxrwxrwt 4 root  root   100 Oct 20 22:57 wsl
drwxrwxrwt 7 root  root   300 Oct 20 22:57 wslg

@laazik
Copy link

laazik commented Oct 20, 2024

Exact same behaviour. Dev drive is accessible only as root, permissions are completely messed up. Other NTFS drives are working correctly. Also the junction created under NTFS does not work under WSL.

root@DESKTOP-0ME7V3Q:~# ls -l /mnt
total 4
drwxrwxrwx 1 marek marek 4096 Oct 18 04:07 c
drwxrwxrwx 2 root  root  4096 Jun 15  2021 e
d--------- 0 root  root     0 Jan  1  1970 h
drwxrwxrwt 4 root  root   100 Oct 20 22:57 wsl
drwxrwxrwt 7 root  root   300 Oct 20 22:57 wslg

/emailed-logs

@craigloewen-msft
Copy link
Member

Hi folks, thank you for the logs and feedback! We have investigated this error and believe we have found an initial fix for it. We're looking at when and how we can service this out, and I will keep this thread up to date with any news once it's available. Thank you!

@wanstr
Copy link

wanstr commented Oct 22, 2024

For me it's KB5044400. Got the same issue, but works again after I uninstalled the update. Pausing windows update for now.

@AdamBraden
Copy link

To provide an update on this issue:

A recent bug was discovered that prevents access to Dev Drives from within WSL. The issue impacts the following updates:

• Windows 11 WIP Release Preview update KB5044384 (build 26100.2152)
• Windows 11 WIP Dev update KB5044374 (build 26120.2122) and KB5044400 (build 26120.2130)

For users that have recently updated to the retail release of Window 11 24H2 (10.0.26100), we recommend you turn OFF “Get the latest updates as soon as they’re available.

If your system is impacted by this bug, your data will not accessible from within WSL. The dev drives and data are accessible from Windows.

The workaround is to uninstall the update, and turn off Updates until this is fixed.

A fix has been identified will be released in an upcoming servicing update.

@meronmks
Copy link

I had exactly the same problem.
However, KB5044384 could not be uninstalled as a required component, so I reverted from 24H2 to 23H2 to avoid it.
If you are experiencing problems and have recently updated to 24H2, you should consider reverting.

@IsmailHassani
Copy link

For now the only solution for me is to place the data folder in my C drive till issue is fixed.

@johnnykang
Copy link

there is no easy way to uninstall KB5044384. The uninstallation process always unsuccessful.

Any better way to uninstall that update at all?

@dev-nextprogress
Copy link

Exact same for me.
For those who just work locally with the dev drive.
I am not sure how the .NET tooling does it under the hood, but containerizing the project using .NET SDK Container build-type actually still works without moving the solution off of the dev drive. It can be added to an existing Dockerfile-type build (in VS just go to Add -> Docker Support and select .NET SDK Container build type). It adds some entries in the csproj which can easily be removed later if desired. But it does create and run a container and that container shows in Docker Desktop just like any other. Quite remarkable. I have only done a smoke test and have not dug into any details but wanted to share in case that might be a good temporary workaround for some.

@jahanarun
Copy link

Same issue and I don't have the KB5044384 installed. So, no way for me to "fix" the issue.
I am on the Windows 11 Insider build 26120.2200

@danyalahmed
Copy link

+1

4 similar comments
@gicastel
Copy link

+1

@BladeMF
Copy link

BladeMF commented Oct 28, 2024

+1

@michaeldtaylor
Copy link

+1

@jonaslang1
Copy link

+1

@MaltseF
Copy link

MaltseF commented Nov 1, 2024

+1

1 similar comment
@kasparsdaugulis
Copy link

+1

@johnnykang
Copy link

Omg, seriously guy, can we stop the +1 ? It is not helping. Tap on the emoji or the subscribe button will do!

@KristiansKaneps
Copy link

+1

@saeed-neorelm
Copy link

saeed-neorelm commented Nov 5, 2024

happening on 2.3.13.0 . here's --version:

WSL version: 2.3.13.0
Kernel version: 6.6.36.3-1
WSLg version: 1.0.63
MSRDC version: 1.2.5326
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.26100.1-240331-1435.ge-release
Windows version: 10.0.26120.2200

here's ls -la

total 8
drwxr-xr-x  7 root root 4096 Apr 25  2024 .
drwxr-xr-x 19 root root 4096 Nov  5 16:56 ..
drwxrwxrwx  1 user user 4096 Nov  5 13:03 c
drwxrwxrwx  1 user user 4096 Nov  5 13:03 d
d---------  0 user user    0 Jan  1  1970 e
drwxrwxrwt  2 root root   60 Nov  5 16:51 wsl
drwxrwxrwt  8 root root  320 Nov  5 16:56 wslg

@sageikosa
Copy link

stumbled into this myself today DevDrive not accessible through WSL2, nor docker desktop "Access Denied"

@sageikosa
Copy link

using .NET SDK containers helped me get past this, not sure what voodoo it does that gets around the WSL devdrive inaccessibility, but forward is good enough for me

@AdamBraden
Copy link

FYI - for folks on the Windows Insiders Dev Channel - the fix is in the latest flight 10.0.26120.2213.

https://blogs.windows.com/windows-insider/2024/11/04/announcing-windows-11-insider-preview-build-26120-2213-dev-channel/

@cubano100pct
Copy link

I reported this same issue on ticket 12220 which was closed as duplicate to this ticket. My logs are on that ticket, if you need it.

@johnnykang
Copy link

johnnykang commented Nov 8, 2024

FYI - for folks on the Windows Insiders Dev Channel - the fix is in the latest flight 10.0.26120.2213.

https://blogs.windows.com/windows-insider/2024/11/04/announcing-windows-11-insider-preview-build-26120-2213-dev-channel/

Do you know if there is any way to get that patch without going through the Windows Insiders?

@PhotoAtomic
Copy link

PhotoAtomic commented Nov 9, 2024

A fix has been identified will be released in an upcoming servicing update.

@AdamBraden is there any target date for the servicing update?

@MatthewSteeples
Copy link

@PhotoAtomic Looks like it's today!

@AdamBraden
Copy link

As @MatthewSteeples and @johnnykang mentioned, this is fixed in the latest update to 24H2 - KB5046617 (OS Build 26100.2314)

@clansty
Copy link

clansty commented Nov 14, 2024

Upgraded and fixed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests