WSL2 Can’t Access Windows Files? Mounts and Permissions That Matter

The mental model: what WSL2 is actually doing

WSL2 is not “Linux running on Windows” in the warm, fuzzy sense people imply. It’s a real Linux kernel running in a lightweight VM (Hyper-V based), with Windows providing integration plumbing. That plumbing is what you’re fighting when Windows files “disappear” or permissions feel haunted.

Inside WSL2 you typically have two classes of storage:

• The Linux filesystem (ext4 inside a VHDX) for your distro, living under /. This is fast and behaves like Linux expects.
• Windows files exposed to Linux via DrvFS mounts, usually under /mnt/c, /mnt/d, etc. This is a compatibility layer that maps NTFS semantics into something Linux can use.

That mapping is the source of most confusion. Linux permissions are simple mode bits + ownership. Windows permissions are ACLs, inherited rules, deny entries, and “it depends” baked into the OS. DrvFS tries to represent Windows objects like Linux files. Sometimes it succeeds. Sometimes it lies politely.

Operationally, you should choose your battleground:

• If you’re compiling, indexing, or doing lots of small-file operations: put the repo in the Linux filesystem (~/src) and access it from Windows via \\wsl$.
• If you must keep files on NTFS: treat /mnt/c like a network filesystem with quirks. Tune mount options. Avoid relying on chmod/chown unless you enable metadata.

One quote to keep your SRE brain switched on: Hope is not a strategy. — General Gordon R. Sullivan. In file systems, “hope it’ll mount like last time” is how you end up debugging at 2 a.m.

Short joke #1: DrvFS is like a translator at a loud bar—mostly accurate, occasionally inventing meaning, always convinced it’s helping.

Interesting facts and history (because the details matter)

• WSL1 and WSL2 are different beasts. WSL1 translated Linux syscalls to Windows NT internals; WSL2 runs an actual Linux kernel in a VM.
• DrvFS predates WSL2. The Windows-drive mounting concept existed in WSL1, but the underlying implementation and performance characteristics changed with the VM boundary.
• Case sensitivity is not universal on Windows. NTFS can be case-preserving and optionally case-sensitive per directory; historically, Win32 APIs treated paths as case-insensitive by default.
• NTFS permissions are ACL-based. Linux mode bits are a simplification that doesn’t represent deny rules, inheritance, or multiple principals cleanly.
• WSL2 storage lives in a VHDX. Your distro’s root filesystem is inside a virtual disk file; moving it between machines or backing it up is possible but needs care.
• Windows file indexing and antivirus scanning matter. Touching many files on NTFS from WSL2 can trigger Windows-side scanning, which looks like “Linux is slow” while Windows does the work.
• 9P and Plan 9 ideas show up in the ecosystem. Some cross-OS file sharing mechanisms borrow concepts similar to remote filesystem protocols; cross-boundary file ops are never free.
• Permission mapping is configurable. DrvFS mount options like metadata, uid, gid, umask, and fmask change what Linux thinks it sees.

Fast diagnosis playbook: find the bottleneck in minutes

When “WSL2 can’t access Windows files” hits, your job is to separate: mount issue, permission issue, path/interop issue, or performance/timeouts. Here’s the fastest path I’ve found that doesn’t devolve into superstition.

First: is the drive mounted the way you think?

• Check mount and look for type drvfs on /mnt/c (or your configured mount root).
• If the mount is missing or wrong, fix automount or /etc/fstab before touching permissions.

Second: is the failure about Linux permissions or Windows ACLs?

• Test create/write as your Linux user in a known folder on C: (like your Windows user profile).
• If you can read but not write, it’s almost always an NTFS ACL or corporate policy tool (EDR, controlled folder access), not “chmod.”

Third: is it a performance failure disguised as “cannot access”?

• If tools time out, hang, or behave flaky on /mnt/c, replicate the same operation under ~ (Linux ext4). If it’s fast there, you’re seeing Windows boundary overhead.
• When in doubt: move the workload to Linux filesystem and expose it back to Windows via \\wsl$.

Fourth: check for cross-platform “gotchas”

• Case sensitivity conflicts, invalid filename characters, symlink behavior, and line ending tooling can make “access” look broken.
• Confirm you’re not writing files with names Windows can’t represent, then expecting them to behave under NTFS.

Mounts that matter: DrvFS, VolFs, and where your bits really live

Most people learn one path: /mnt/c. Then they assume it’s “just a folder.” It isn’t. It’s a mounted filesystem of type drvfs, and its mount options decide everything from visible permissions to whether chmod does anything.

DrvFS mount points: /mnt/c is a policy choice

By default, WSL auto-mounts fixed drives under /mnt/<driveletter>. That behavior can be changed in /etc/wsl.conf. That change can also break scripts, CI steps, or developer muscle memory—so treat it like an API change.

Linux filesystem inside WSL2: your real performance zone

Inside the WSL2 VM, your distro’s root filesystem is ext4 (typically) and behaves like a normal Linux machine. If your workload is “Linux-y” (node_modules churn, Rust builds, Python venv, git operations), keeping it on ext4 is the difference between “it works” and “my laptop is a space heater.”

Where mounts go wrong

Common mount failure modes I’ve seen in production-ish developer fleets:

• Automount disabled: no /mnt/c, or only some drives appear.
• Drive letter changes: removable media, BitLocker unlock states, or corporate disk management policies shift letters.
• fstab errors: a malformed entry can prevent expected mounts and leave you debugging “permissions” when the filesystem isn’t even there.
• Network paths: mapping Windows network drives is not the same as local NTFS. You may need a different approach (and expectations).

Mount options that actually change behavior

The mount options are where you decide whether Linux permissions are “real” (metadata) or “projected” (mask-based). Here’s the operational truth:

• Without metadata: chmod/chown mostly won’t persist because there’s nowhere to store POSIX ownership on plain NTFS files as DrvFS presents them.
• With metadata: WSL stores extra metadata (think “extended attributes”) to preserve Linux mode bits and ownership mappings. This makes Linux tooling happier, but can surprise Windows tooling and other machines.
• uid/gid/umask/fmask/dmask: useful when you want consistent ownership and modes for everything on that mount, especially without metadata.

There’s no universally “correct” option set. There is only “correct for what you run” and “correct for what your team expects.” Pick one and standardize it.

Permissions that matter: NTFS ACLs vs Linux mode bits

When Linux says “permission denied,” it’s telling you the syscall failed. That doesn’t mean the Linux mode bits are wrong. It could be:

• Windows ACL denies the action (explicitly or via inherited policy).
• Windows “controlled folder access” blocks writes to protected directories.
• EDR/antivirus hooks block or delay access until timeout.
• The file is locked by a Windows process with sharing modes that don’t match what Linux expects.

Understand the mapping: who owns what?

By default, DrvFS often presents Windows files as owned by your Linux user (or sometimes root-like defaults depending on config) with permissive-looking mode bits. Those bits are not the authority; NTFS ACLs are.

If you enable metadata, Linux ownership and mode bits can become more meaningful within WSL. But Windows apps still enforce NTFS ACLs and may ignore or trample POSIX-like metadata.

What “chmod doesn’t work” really means

On DrvFS without metadata, chmod is like yelling at a painting: you feel productive, nothing changes. The correct fix is to either:

• Enable metadata so chmod has somewhere to persist.
• Stop relying on chmod/chown and manage access via Windows ACLs (Explorer, icacls, group policy).
• Move the workload to the Linux filesystem where POSIX permissions are native.

Symlinks: the quiet permission trap

Symlinks from Linux to Windows paths and vice versa can fail in ways that look like permissions. Windows symlink creation may require Developer Mode or admin rights depending on policy. Also: a symlink that resolves to a Windows path inherits Windows ACL behavior. Your Linux process doesn’t get a magic exemption.

Short joke #2: I’ve seen “fix permissions” run so many times it deserves a loyalty card—buy nine chmods, get the tenth free, still broken.

Practical tasks: commands, outputs, and what to decide next

These are real tasks I’d run on a fleet laptop or a dev workstation while someone says “WSL2 can’t access files.” Each task includes: command, sample output, what it means, and the decision you make.

Task 1: Confirm you’re in WSL2 (not WSL1)

cr0x@server:~$ uname -r
5.15.133.1-microsoft-standard-WSL2

What it means: A kernel string containing microsoft and WSL2 indicates you’re running the WSL2 kernel.

Decision: If it’s WSL1, file access semantics and perf differ; adjust expectations and consider upgrading the distro to WSL2.

Task 2: See what’s mounted and whether C: is DrvFS

cr0x@server:~$ mount | grep -E ' /mnt/c |drvfs'
C:\ on /mnt/c type drvfs (rw,noatime,uid=1000,gid=1000,case=off)

What it means: /mnt/c is mounted; options show how permissions and case handling behave.

Decision: If the mount is missing, fix automount. If options aren’t what you need (no metadata, wrong uid), fix /etc/wsl.conf or remount.

Task 3: Check that the path exists and isn’t a broken symlink

cr0x@server:~$ ls -ld /mnt/c /mnt/c/Users
drwxrwxrwx 1 cr0x cr0x 4096 Jan 20 09:10 /mnt/c
drwxrwxrwx 1 cr0x cr0x 4096 Jan 20 09:10 /mnt/c/Users

What it means: Directory entries exist and are accessible from Linux’s point of view.

Decision: If ls itself errors, this is mount/interop, not app-level permissions.

Task 4: Reproduce the failure with a minimal write test

cr0x@server:~$ touch /mnt/c/Users/cr0x/Desktop/wsl_write_test.txt
touch: cannot touch '/mnt/c/Users/cr0x/Desktop/wsl_write_test.txt': Permission denied

What it means: Linux attempted the write; Windows/DrvFS rejected it.

Decision: Suspect NTFS ACL, controlled folder access, or corporate endpoint controls. Test writing in a less-protected directory (like /mnt/c/Users/cr0x), then fix Windows-side permissions/policies or move workload.

Task 5: Test write in the user profile root (often less protected)

cr0x@server:~$ mkdir -p /mnt/c/Users/cr0x/wsl_scratch
cr0x@server:~$ echo ok > /mnt/c/Users/cr0x/wsl_scratch/test.txt
cr0x@server:~$ cat /mnt/c/Users/cr0x/wsl_scratch/test.txt
ok

What it means: Writes work in this location. The earlier failure is location/policy-specific.

Decision: Put WSL-write workloads in a writable location or adjust Windows security settings for the blocked folder (with your security team, not by wishful thinking).

Task 6: Identify the mount options that control permission projection

cr0x@server:~$ findmnt -no SOURCE,TARGET,FSTYPE,OPTIONS /mnt/c
C:\ /mnt/c drvfs rw,noatime,uid=1000,gid=1000,case=off

What it means: No metadata option; ownership is projected via uid/gid mapping.

Decision: If you need chmod/chown semantics for build tools, enable metadata (and accept the trade-offs) or move the repo into ext4.

Task 7: Check current WSL automount config

cr0x@server:~$ cat /etc/wsl.conf
[automount]
enabled = true
root = /mnt/
options = "metadata,uid=1000,gid=1000,umask=022,fmask=111"

What it means: Automount is enabled; DrvFS mounts will include metadata and specific masks.

Decision: If enabled is false or options are missing, fix this file, then restart WSL to apply.

Task 8: Apply config changes by restarting WSL (from inside Linux)

cr0x@server:~$ wsl.exe --shutdown

What it means: Terminates all WSL instances; next launch re-reads config and remounts drives.

Decision: Do this after editing /etc/wsl.conf or when mounts look stale.

Task 9: Verify metadata behavior via chmod on DrvFS

cr0x@server:~$ cd /mnt/c/Users/cr0x/wsl_scratch
cr0x@server:~$ echo hi > permtest.sh
cr0x@server:~$ chmod +x permtest.sh
cr0x@server:~$ ls -l permtest.sh
-rwxr-xr-x 1 cr0x cr0x 3 Jan 20 10:02 permtest.sh

What it means: If chmod persists and the execute bit shows up, metadata is working (or execute bits are being projected by masks).

Decision: If execute bit refuses to stick, you’re not using metadata (or fmask blocks it). Fix mount options or stop placing executables on DrvFS.

Task 10: Spot obvious Windows locks by trying a rename

cr0x@server:~$ mv /mnt/c/Users/cr0x/wsl_scratch/test.txt /mnt/c/Users/cr0x/wsl_scratch/test.txt.bak
mv: cannot move '/mnt/c/Users/cr0x/wsl_scratch/test.txt' to '/mnt/c/Users/cr0x/wsl_scratch/test.txt.bak': Device or resource busy

What it means: “Device or resource busy” on DrvFS often indicates Windows has an open handle with incompatible sharing flags, or an AV/EDR is holding it.

Decision: Close Windows apps touching the file (editors, indexers). If persistent, consider excluding the path (with policy approval) or move workload to ext4.

Task 11: Compare performance: Windows mount vs Linux filesystem

cr0x@server:~$ time bash -lc 'mkdir -p /mnt/c/Users/cr0x/wsl_scratch/io && for i in $(seq 1 5000); do echo $i > /mnt/c/Users/cr0x/wsl_scratch/io/f_$i; done'
real	0m22.381s
user	0m3.112s
sys	0m9.847s

What it means: That’s a lot of overhead for tiny file operations on DrvFS.

Decision: If your build does similar patterns (node, git, pip), stop using /mnt/c for the repo.

cr0x@server:~$ time bash -lc 'mkdir -p ~/io && for i in $(seq 1 5000); do echo $i > ~/io/f_$i; done'
real	0m2.941s
user	0m1.812s
sys	0m1.006s

What it means: ext4 in WSL2 is dramatically faster for metadata-heavy workloads.

Decision: Keep repos and build artifacts in the Linux filesystem; use Windows access via \\wsl$ if needed.

Task 12: Confirm distro disk usage (VHDX pressure can cause weirdness)

cr0x@server:~$ df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb       100G   78G   22G  79% /

What it means: Your Linux filesystem has limited free space. Low space can turn normal operations into failures.

Decision: Clean up build artifacts, docker layers, or caches. If you hit 100%, fix that before blaming mounts.

Task 13: Diagnose ownership expectations (who am I, really?)

cr0x@server:~$ id
uid=1000(cr0x) gid=1000(cr0x) groups=1000(cr0x),27(sudo)

What it means: Confirms uid/gid, useful when mount options force ownership mapping.

Decision: If mount shows different uid/gid than your user, fix mount options or you’ll get “why is everything owned by 1001?” confusion forever.

Task 14: Confirm case sensitivity behavior on the mount

cr0x@server:~$ findmnt -no OPTIONS /mnt/c | tr ',' '\n' | grep -E '^case='
case=off

What it means: DrvFS is treating paths case-insensitively for lookups.

Decision: If you have repos with files differing only by case, don’t keep them on /mnt/c. Put them on ext4 to avoid cross-tool chaos.

Task 15: Verify access from Windows to WSL files (reverse direction)

cr0x@server:~$ explorer.exe .

What it means: Opens Windows Explorer at the current Linux directory via WSL integration.

Decision: If Windows can’t browse or errors out, you may have WSL integration issues or policy restrictions; this affects workflows that expect Windows tools to access WSL files.

Task 16: Check fstab entries that might override automount

cr0x@server:~$ cat /etc/fstab
C:\ /mnt/c drvfs metadata,uid=1000,gid=1000,umask=022,fmask=111 0 0

What it means: You’re explicitly mounting C:. This overrides defaults and can conflict with automount settings.

Decision: If things are weird, simplify: either use automount with wsl.conf, or manage mounts in fstab—don’t play both sides unless you enjoy surprises.

Three corporate mini-stories from the trenches

Mini-story 1: The incident caused by a wrong assumption

A product team standardized on “keep the monorepo on C:\ so Windows tools work, and WSL just uses /mnt/c.” It sounded reasonable. It even worked during the pilot, when the repo was small and the developer machines were fresh.

Then they rolled it out to a few dozen engineers. Build times ballooned, tests started timing out, and a handful of builds began failing with sporadic “file not found” errors. The first wave of debugging focused on the build system. Naturally. Nobody wants to admit the filesystem is the culprit because it feels like blaming the ground for tripping.

The actual failure mode: the build generated tens of thousands of small files under /mnt/c, which triggered Windows-side scanning and indexing. Under load, file operations became slow enough that tools hit internal timeouts and started behaving nondeterministically. Some devs “fixed it” by disabling security tools, which created a different kind of incident waiting to happen.

The correction was boring and effective: move active repos into WSL ext4 (~/src), and access them from Windows editors via \\wsl$ where needed. They kept a small Windows-side checkout only for workflows that truly required native Windows paths. The incident wasn’t a build bug. It was an assumption bug.

Mini-story 2: The optimization that backfired

An infra-minded developer tried to “fix permissions once and for all” by enabling metadata on DrvFS across the fleet and setting permissive umasks. The goal: make Linux tools behave more like Linux, especially around executables and git hooks.

The rollout went smoothly—until a Windows-based backup agent and a couple of IDE plugins started reacting badly. Some tools interpreted the extra metadata in ways that changed file attributes or triggered rescans. On a few machines, massive folder trees began churning: timestamp updates, attribute flips, and repeated “changed files” notifications.

The result wasn’t data loss, but it was workflow loss: git status always looked dirty, some Windows tooling slowed down, and people stopped trusting their working copy. The optimization “worked” for Linux semantics but ignored the Windows ecosystem that also touched those files.

The fix was to stop chasing a universal configuration. They limited metadata mounts to specific project directories where Linux semantics were required, and kept default DrvFS behavior elsewhere. Better: they moved most repos to ext4 and treated /mnt/c as a boundary, not a home.

Mini-story 3: The boring but correct practice that saved the day

A security-conscious enterprise team had a rule: no ad-hoc changes to Windows security settings to “make dev tools work.” Instead, they maintained a standard developer folder under the user profile with known-good ACLs, and they documented where WSL workloads were allowed to write.

It annoyed people at first. Engineers love nothing more than having to follow a folder policy when they’re “just trying to run tests.” But then a Windows update introduced stricter behavior for protected folders, and a bunch of machines started throwing Permission denied when WSL tried to write to Desktop or Documents.

Teams without the policy had a scramble: people made local exceptions, some disabled protection, and security had to claw back inconsistent settings. The team with the boring policy? They barely noticed. Their workflows already wrote to the approved scratch/workspace directory, and their repos lived in WSL ext4.

The practical lesson: you can’t outsmart endpoint policy with chmod. You can only design around it.

Common mistakes: symptom → root cause → fix

1) “/mnt/c is missing”

Symptom: ls /mnt/c returns “No such file or directory.”

Root cause: Automount disabled in /etc/wsl.conf, WSL not restarted, or a broken /etc/fstab entry prevented the mount.

Fix: Enable automount or correct /etc/fstab; run wsl.exe --shutdown and relaunch.

2) “Permission denied on Desktop/Documents”

Symptom: Writes fail in user folders that “should be yours.”

Root cause: Windows controlled folder access, corporate endpoint controls, or tightened ACLs on protected folders.

Fix: Use a known-writable directory under your profile (or a team-approved workspace). If policy allows, request an exception through security—not via random local hacks.

3) “chmod +x doesn’t stick on /mnt/c”

Symptom: File remains non-executable after chmod; git hooks fail; scripts won’t run.

Root cause: DrvFS without metadata, or fmask masking execute bits.

Fix: Enable metadata for that mount, or keep executables inside the Linux filesystem. Adjust fmask/umask if you’re projecting permissions.

4) “Everything is owned by root”

Symptom: ls -l shows root root or unexpected uid/gid on /mnt/c.

Root cause: Mount options mapping ownership incorrectly (missing uid/gid), or custom mount in /etc/fstab.

Fix: Set uid=1000,gid=1000 (or your actual IDs) in automount options; restart WSL.

5) “Git status is slow / builds crawl”

Symptom: Small operations are glacial under /mnt/c, fine under ~.

Root cause: Cross-boundary overhead + Windows scanning/indexing + NTFS semantics mismatch for Linux-heavy workloads.

Fix: Move repo to ext4 in WSL2. Access from Windows via \\wsl$. Keep build artifacts off /mnt/c.

6) “Input/output error on /mnt/c”

Symptom: Random I/O errors reading Windows files.

Root cause: Underlying Windows filesystem errors, drive disconnects (external media), or unstable network-backed drives presented as letters.

Fix: Validate the drive health on Windows, avoid external/network drives for critical dev paths, and re-mount after reconnects.

7) “Case-only renames don’t work”

Symptom: Renaming Readme.md to README.md behaves oddly; tools disagree.

Root cause: Case sensitivity settings differ; DrvFS may be case=off.

Fix: Keep such repos on ext4, or enforce naming conventions that don’t rely on case-only differences.

8) “Symlink creation fails”

Symptom: Creating symlinks errors, or links behave differently across sides.

Root cause: Windows policy restrictions on symlink creation; differing semantics between Windows and Linux.

Fix: Prefer Linux-side symlinks within ext4; avoid cross-boundary symlinks when possible; enable the required Windows developer features if allowed.

Checklists / step-by-step plan

Checklist A: “WSL2 can’t see /mnt/c” (mount-level outage)

1. Run mount | grep drvfs and confirm whether C: is mounted at all.
2. Inspect /etc/wsl.conf for [automount] and enabled=true.
3. Inspect /etc/fstab for broken DrvFS entries. Temporarily comment out suspicious lines.
4. Restart WSL with wsl.exe --shutdown.
5. Re-check with findmnt /mnt/c. If it still fails, treat it as Windows/WSL integration trouble, not Linux permissions.

Checklist B: “Permission denied” (write failure)

1. Reproduce with touch in the exact directory.
2. Try writing in a less protected path (like /mnt/c/Users/<you>/wsl_scratch).
3. If it works elsewhere, stop. This is not a chmod problem.
4. Decide: move workload to ext4, or fix Windows ACL/policy for that directory.
5. If corporate-managed: open a ticket with the exact path and minimal repro commands, not “WSL is broken.”

Checklist C: “chmod/chown doesn’t work” (Linux tools unhappy)

1. Check mount options with findmnt -no OPTIONS /mnt/c.
2. If metadata is missing, decide whether you truly need POSIX permissions on NTFS.
3. If yes: enable metadata via /etc/wsl.conf or an explicit fstab mount.
4. Restart WSL.
5. Re-test with chmod +x and confirm via ls -l.
6. If still inconsistent: move executables and build outputs to ext4. That’s the grown-up answer.

Checklist D: “Everything is slow” (performance triage)

1. Benchmark a small-file workload on /mnt/c vs ~ (like the loop examples above).
2. If /mnt/c is much slower, stop trying to tune your way out with random flags.
3. Move the repo to ext4. Use Windows tools through \\wsl$ or explorer.exe .
4. Keep only “must be on NTFS” assets on /mnt/c (large media files, shared folders with Windows-only tools).
5. Re-run the benchmark to prove the fix; document it for the next person.

FAQ

1) Why does WSL2 sometimes show weird permissions on /mnt/c?

Because DrvFS is mapping NTFS ACLs into a POSIX-like view. Without metadata, the mode bits are mostly a projection controlled by mount options, not authoritative truth.

2) Should I store my git repo on /mnt/c or in the Linux filesystem?

Put active repos in the Linux filesystem (ext4) unless you have a strong Windows-native requirement. Builds, package managers, and git are typically faster and more reliable there.

3) If chmod doesn’t work on /mnt/c, is WSL broken?

No. It’s expected behavior without metadata. Either enable metadata (accepting trade-offs) or don’t rely on chmod on DrvFS mounts.

4) Why can I read a Windows file but not write it from WSL2?

Reading is often permitted broadly, while writing can be blocked by NTFS ACLs, protected folders, controlled folder access, or endpoint security tooling.

5) What’s the cleanest way to apply wsl.conf mount changes?

Edit /etc/wsl.conf, then restart WSL with wsl.exe --shutdown. A simple distro exit doesn’t reliably reapply automount behavior.

6) Is enabling metadata always a good idea?

No. It improves Linux semantics on NTFS, but it can surprise Windows tooling and create inconsistency if multiple environments touch the same tree. Use it deliberately, ideally only where needed.

7) Why do some operations on /mnt/c hang or time out?

Cross-boundary filesystem operations can be slowed by Windows-side scanning, indexing, file locking semantics, or just the overhead of translating operations. If it’s fast on ext4 and slow on DrvFS, that’s your answer.

8) Can I access WSL files from Windows reliably?

Generally yes via \\wsl$ and explorer.exe integration. For heavy write workloads from Windows apps into the Linux filesystem, test your specific tools—some still behave better on NTFS.

9) Why does a case-only rename behave strangely?

Windows is often case-insensitive by default; Linux is case-sensitive. If your mount is case=off, case-only differences can confuse tools. Keep those repos on ext4.

10) What should I do if corporate security blocks WSL writing to certain folders?

Don’t play whack-a-mole. Use an approved workspace directory, keep repos on ext4, and request policy changes through the proper channel with a minimal repro and business justification.

Conclusion: next steps that don’t waste your week

If WSL2 can’t access Windows files, stop guessing and follow the chain of responsibility:

1. Confirm the mount exists and is DrvFS with the options you think you have.
2. Reproduce with a minimal write to separate mount issues from Windows policy/ACL issues.
3. Decide where the workload lives: Linux filesystem for Linux-y workloads; NTFS only when Windows tooling truly needs it.
4. Standardize configuration (wsl.conf + restart procedure) so fixes don’t evaporate after updates or reboots.

The most reliable “fix” is often architectural: put your fast-changing dev trees in ext4, treat /mnt/c as an integration boundary, and reserve permission tuning for the cases that genuinely require it. That approach is unglamorous. It also works.