Fixing 'Access Is Denied' Errors in WSL After an Update

“Access is denied” or “Permission denied” errors appearing specifically after a WSL or Windows update — for commands and files that worked fine before — usually trace to one of a few specific, common causes rather than a random regression.

Step 1: identify exactly which operation is failing

# reproduce the exact failing command and note the
# exact error text and the specific file/path involved

“Access denied” on a Linux-native file, a file under /mnt/c, and a Windows executable being called from WSL are three different problems with three different likely causes — precisely identifying which is failing narrows the investigation considerably.

Step 2: check for a Windows-side file lock, if the path is under /mnt/c

Confirm no Windows application (an editor, an antivirus scan,
  a sync tool like OneDrive) currently has the specific
  file open or locked

Windows file locking semantics are stricter than Linux’s by default — a file held open by a Windows-side application can produce access-denied errors from the Linux side that wouldn’t occur with the equivalent Linux-native file, a direct consequence of the filesystem bridge between the two systems.

Step 3: check whether file permission bits were reset by the update

ls -la /path/to/file

Some WSL updates have, in specific documented cases, affected how permission bits are translated or preserved for files under /mnt/c specifically — comparing current permissions against what you’d expect (or against a similar unaffected file) can reveal whether bits were unexpectedly reset.

Step 4: check for a changed default umask

umask

A changed default umask value (sometimes introduced by a distro update rather than a WSL platform update specifically) changes the default permissions newly-created files receive, which can look like a permissions regression on new files while leaving old ones unaffected.

Step 5: check ownership specifically, not just permission bits

ls -la /path/to/file
# confirm the owning user matches your current WSL user

A file owned by a different user (sometimes root, if a command was previously run with sudo and created a file without you noticing) produces access-denied errors for your normal user regardless of permission bits — chown to correct ownership is the right fix here, not broadening permission bits.

Step 6: check for an interop-specific permission issue when calling Windows executables

If the specific failure involves calling a Windows executable from WSL, confirm the Windows-side executable and its target files have appropriate Windows-side permissions — this is a genuinely separate permission system from Linux’s, and an access-denied error here may need fixing from the Windows side, not the Linux side.

Step 7: restart WSL2 fully to rule out a stale mount state

wsl --shutdown

Occasionally, a filesystem mount’s permission-translation state can become stale following an update without a full restart — this rules out that specific category of cause before investigating further.

Step 8: avoid reaching for chmod 777 as a first response

Broadly opening permissions to work around an access-denied error masks the actual underlying cause (a lock, an ownership mismatch, a stale mount) without fixing it, and can create a genuine security gap on files that didn’t need broad access in the first place — worth resisting as a quick fix in favor of identifying the actual specific cause first.

Why updates specifically can surface previously-latent permission issues

An update can change default umask values, permission-translation behavior for /mnt/c paths, or file locking interaction subtleties — any of which can surface a permission problem that simply didn’t manifest under the exact previous configuration, which is why “it started after an update” is a genuinely useful diagnostic clue rather than just an annoyance.

Checking whether metadata mode’s permission storage itself changed

If the affected paths are under /mnt/c and DrvFs metadata mode is enabled, an update occasionally changes default mount options in ways that affect how permission bits are stored and interpreted. Reviewing the current automount options in /etc/wsl.conf against what was configured before the update — rather than assuming the configuration itself is untouched — catches this specific, less obvious cause.

When the fix genuinely requires a Windows-side permission change

For interop-related access-denied errors specifically, remember that Windows ACLs are a separate permission system from anything chmod/chown on the Linux side can touch — if a Windows executable or a file it needs to access is the actual target, granting access may require adjusting Windows-side NTFS permissions directly (through File Explorer’s Properties dialog or icacls) rather than any Linux-side command.

Keeping a before/after record when the cause isn’t obvious

If none of these steps immediately reveal the cause, capturing the exact output of ls -la, umask, and the relevant /etc/wsl.conf section right after the update — before making any further changes — gives you (or anyone else helping) an actual record to compare against once a cause is eventually found, rather than relying on memory of what things looked like before you started troubleshooting.

Related:

Sources: