Share via

WSL 2: "Access is denied" error appearing all of a sudden after months of use. Nothing changed (?)

Pablo Reig 20 Reputation points
2026-06-15T11:55:30.14+00:00

I am unable to mount the WSL instance I've been using for months, and access the files contained within. I'd rather not lose those files if it can be helped.

Windows version: Windows 10; Version 22H2 (OS Build 19045.6466).

WSL version (obtained from running wsl --version):

• WSL version: 2.7.3.0
• Kernel version: 6.6.114.1-1
• WSLg version: 1.0.73
• MSRDC version: 1.2.6676
• Direct3D version: 1.611.1-81528511
• DXCore version: 10.0.26100.1-240331-1435.ge-release

Error message (verbatim):

wsl: Mirrored networking mode is not supported: Windows version 19045.6466 does not have the required features.
Falling back to NAT networking.
Failed to attach disk 'D:\UbuntuMoved\ext4.vhdx' to WSL2: Access is denied.
Error code: Wsl/Service/CreateInstance/MountDisk/HCS/E_ACCESSDENIED

[process exited with code 4294967295 (0xffffffff)]
You can now close this terminal with Ctrl+D, or press Enter to restart.

Note: I’m aware about what the "mirrored networking" thing means. I tried setting it up once for a uni project before I figured out it wasn’t available on Windows 10. I heavily doubt it has anything to do with the “Access is denied” issue, but I could always be wrong. I've been getting the "mirrored networking" error message for months now without further issue, well before the "access is denied" thing happened.

Failing .vhdx file’s metadata:

fsutil file layout D:\UbuntuMoved\ext4.vhdx

********* File 0x00010000000006bd *********
File reference number   : 0x00010000000006bd
File attributes         : 0x00000821: Read only | Archive | Compressed
File entry flags        : 0x00000000
Link (ParentID: Name)   : 0x00010000000006bc: HLINK Name   : \UbuntuMoved\ext4.vhdx
Creation Time           : 11/18/2025 11:59:04
Last Access Time        : 6/4/2026 18:23:27
Last Write Time         : 6/1/2026 12:41:05
Change Time             : 6/10/2026 9:59:22
LastUsn                 : 0
OwnerId                 : 0
SecurityId              : 791
StorageReserveId        : 0
Stream                  : 0x010  ::$STANDARD_INFORMATION
    Attributes          : 0x00000000: *NONE*
    Flags               : 0x0000000c: Resident | No clusters allocated
    Size                : 72
    Allocated Size      : 72
Stream                  : 0x030  ::$FILE_NAME
    Attributes          : 0x00000000: *NONE*
    Flags               : 0x0000000c: Resident | No clusters allocated
    Size                : 84
    Allocated Size      : 88
Stream                  : 0x080  ::$DATA
    Attributes          : 0x00000800: Compressed
    Flags               : 0x00000010: Has Parsed Information
    Size                : 104,003,010,560 (96.9 GB)
    Allocated Size      :  75,218,980,864 (70.1 GB)
    Vdl                 : 104,003,010,560 (96.9 GB)
    Extents             : 1,648,617 Extents
Stream                  : 0x020  ::$ATTRIBUTE_LIST
    Attributes          : 0x00000000: *NONE*
    Flags               : 0x00000000: *NONE*
    Size                : 262,144
    Allocated Size      : 262,144
    Extents             : 1 Extents

What I did differently before the failure:

Nothing, really! I've been working with that wsl instance for many months at this point. Specially for the past weeks, with uni finals rush season and all. After a short break of a couple days from not using the wsl instance, trying to boot it up again fails and displays the above error message.

I’d rather not lose all the data within, but it’s unimportant enough that it wouldn’t be the end of the world.

Many months ago, I moved the file from my main drive to a secondary drive in a different partition. Hence why it’s called “UbuntuMoved”. It worked just fine for a couple months after the fact, so I doubt that’s the cause of the issue.

I’ve also been using that same secondary drive to store backups from a different program. Perhaps that has something to do with it (?). Drive is NTFS, btw.

Steps already taken to attempt to fix the issue:

  • tried changing permissions of .vhdx file; unsure if it succeeded.
  • Tried uncompressing .vhdx file and the driver containing it. Unsure if it succeeded, or if it was even compressed in the first place (I was just following some suggestions by an AI chatbot).

Any help would be greatly appreciated. I know just the tiniest bit of WSL and Linux to be able to use it for uni projects, but not much beyond that! Perhaps this issue has an obvious solution, but I'm lost here. If all else fails, installing a new instance and losing the data wouldn't be the end of the world, but I'd like to understand what went wrong and how to avoid in the future.

Windows for home | Other | Files, folders, and storage
0 comments

Answer accepted by question author

Lychee-Ng 22,005 Reputation points Microsoft External Staff Moderator
2026-06-16T12:38:38.3866667+00:00

Hi Pablo Reig,

I know that you're worried about losing your files, so the good news is that in this type of error, your data is very likely still intact. What’s happening here is that WSL can’t attach the virtual disk, not that the data inside it has been erased.

From the metadata you shared, the file is marked Read-only and Compressed, which is not suitable for WSL. The virtual disk used by WSL must be stored as a normal, writable, uncompressed NTFS file. When compression or certain attributes are applied, the Hyper‑V disk layer can reject it with a generic ACCESSDENIED error.

  1. Press Win + X > open Windows PowerShell / Terminal (Admin)
  2. Run the following commands to clear the attributes:
    1. attrib -R "D:\UbuntuMoved\ext4.vhdx"
    2. compact /U "D:\UbuntuMoved\ext4.vhdx"
  3. Verify the changes:
    1. attrib "D:\UbuntuMoved\ext4.vhdx"
    2. compact /Q "D:\UbuntuMoved\ext4.vhdx"
  4. Make sure the file is NOT read-only nor compressed
  5. Once done, restart WSL by running wsl --shutdown then wsl.

Even if you didn’t change anything manually, this can happen when Windows applies compression automatically (especially if the folder or drive has compression enabled) or backup software modifies the file attributes. To avoid this in the future:

  • Do not store WSL .vhdx files on compressed drives or folders
  • Avoid letting backup tools directly manage the .vhdx
  • If possible, keep the distro in the default WSL location
  • Ensure the drive has no compression/encryption.

As long as the .vhdx file is still present, your data is very likely safe. If WSL starts but shows other errors, then you can proceed with the repair steps already suggested.

If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Was this answer helpful?

1 person found this answer helpful.

1 additional answer

Sort by: Most helpful
Most helpful Newest Oldest

  1. AI answer

    2026-06-15T11:56:05.4733333+00:00

    The error indicates that WSL cannot attach the ext4.vhdx disk and is returning E_ACCESSDENIED. When WSL cannot mount a distribution disk, one supported recovery path is to mount and repair the VHD manually, then detach it and start WSL again.

    Follow these steps to attempt recovery of the existing VHD and restore write access:

    1. Shut down all WSL instances
      • Open PowerShell as Administrator and run: 
             wsl.exe --shutdown
    2. Mount the VHD directly with WSL
      • Still in elevated PowerShell, mount the VHD in bare mode (replace the path with the actual path to your file, which in this case is D:\UbuntuMoved\ext4.vhdx): 
             wsl.exe --mount D:\UbuntuMoved\ext4.vhdx --vhd --bare
      • If this command fails with a sharing or access error, ensure no other process (for example, backup software or Docker Desktop) is using the file. Close those applications and retry.
    3. Identify the block device inside WSL
      • From the same elevated PowerShell window, list the block devices exposed to WSL: 
             wsl.exe lsblk
      • Note the device name corresponding to the mounted VHD, typically something like sdc (system distribution is sda).
    4. Run filesystem repair on the ext4 filesystem
      • Use e2fsck to check and repair the ext4 filesystem on that device (replace <device> with the name from the previous step, e.g., sdc): 
             wsl.exe sudo e2fsck -f /dev/<device>
      • This checks the ext4 filesystem used by WSL distributions and repairs errors that can cause mount failures.
      • If there is only a single distribution installed and lsblk reports the ext4 file in use, temporarily install another distribution so lsblk and e2fsck can run, then uninstall it after repair.
      • If Docker Desktop is running and you see Wsl/Service/CreateInstance/MountVhd/HCS/ERROR_SHARING_VIOLATION, close Docker Desktop and rerun the command.
    5. Unmount the disk from WSL
      • After e2fsck completes successfully, unmount the disk: 
             wsl.exe --unmount
    6. Start the distribution normally
      • Now start the distribution again (from Start menu or wsl.exe -d <YourDistroName>). If the repair succeeded and the access issue was due to filesystem or mount problems, the distribution should mount and become writable again.
    7. Avoid temporary in‑memory remounts for long‑term use
      • It is technically possible to remount a read‑only filesystem as read‑write from inside WSL with: 
             sudo mount -o remount,rw /
      • However, this only affects the in‑memory mount; changes are lost when the distribution restarts. For persistent recovery, use the wsl.exe --mount + e2fsck procedure above.

    If these steps complete without errors and the distribution starts, the data in the VHD should be accessible again. If wsl.exe --mount itself continues to fail with E_ACCESSDENIED even from elevated PowerShell and with all other consumers closed, the problem is outside what is covered here (for example, external security or backup tools locking the file), and the next step would be to ensure nothing else is holding a handle to ext4.vhdx before repeating the repair steps.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.