How to Access Files Between Windows and WSL Correctly

Moving files between Windows and WSL works in both directions, but through different mechanisms — understanding the underlying bridge helps you use both correctly rather than fighting unexpected performance or permission behavior.

Step 1: access Windows drives from inside WSL

cd /mnt/c/Users/YourName/Documents
ls /mnt/c

Every Windows drive letter is mounted under /mnt/ inside WSL — /mnt/c for your C: drive, /mnt/d for D:, and so on.

Step 2: access WSL’s Linux filesystem from Windows

File Explorer address bar:
\\wsl$\Ubuntu\home\yourusername\

Or, on newer WSL versions:

\\wsl.localhost\Ubuntu\home\yourusername\

Windows treats your WSL distro’s filesystem as a network location, browsable directly through File Explorer or any Windows application’s file-open dialog.

Step 2b: browse WSL files from any Windows application’s open/save dialog

The \\wsl$\ or \\wsl.localhost\ path isn’t limited to File Explorer specifically — any Windows application’s standard file open or save dialog accepts the same network path, letting a Windows-native application (an image editor, a document viewer) reach into your Linux distro’s files directly without needing to copy them out first.

Step 3: open the current Linux directory in File Explorer directly

explorer.exe .

Run from inside a WSL shell, this opens Windows Explorer directly at your current Linux working directory — genuinely convenient for switching to GUI file management mid-task.

Step 4: open the current Windows-accessible directory from an actual Windows path in WSL

cd "$(wslpath 'C:\Users\YourName\Documents')"

wslpath converts a Windows-style path into the equivalent WSL path, useful when you have a Windows path (copied from Explorer, for instance) and need the WSL-side equivalent.

Step 5: decide where a given project’s files should actually live

Working primarily from Linux-side tools (a Node.js
  or Python project you build and run from WSL)?
  → keep it on the Linux-native filesystem (~/projects/)

Working primarily from Windows-side tools, only
  occasionally touching it from WSL?
  → /mnt/c is fine

This isn’t an arbitrary preference — cross-filesystem access through the 9P bridge carries real per-operation overhead, which compounds significantly for workloads doing many small file operations.

Step 6: copy files between the two filesystems when needed

cp -r /mnt/c/Users/YourName/project ~/project
cp -r ~/project /mnt/c/Users/YourName/project-backup

Copying, rather than only ever accessing files in place, is the right move whenever you’re about to do sustained, intensive work on a project currently living on the “wrong” filesystem for your primary tooling.

Step 7: understand case sensitivity differences

Linux filesystems are case-sensitive; NTFS (Windows’ filesystem) is not by default — a project relying on case-sensitive filenames can behave unexpectedly if kept under /mnt/c and touched by tools on both sides, since NTFS won’t distinguish File.txt from file.txt the way ext4 does.

Step 8: verify performance-sensitive work is actually on the right filesystem

time cp -r some-large-directory /tmp/test-copy

If a routine file operation feels unexpectedly slow, checking whether you’re working against /mnt/c when you should be Linux-native is the first, most common explanation worth ruling out.

Why understanding both access directions matters, not just one

Most WSL guidance focuses on accessing Windows files from Linux, since that’s the more commonly needed direction — but knowing the \\wsl$\ (or \\wsl.localhost\) path for the reverse direction, and explorer.exe . as a shortcut, rounds out genuinely comfortable day-to-day use of both environments together.

Choosing consistently, not just for one project at a time

Once you’ve settled on a rule for where a given kind of project lives, applying it consistently across every new project avoids re-deriving the decision, and re-discovering the performance gap, from scratch every time a new repository gets cloned.

Enabling DrvFs metadata mode if Linux-style permissions matter to you

By default, files accessed under /mnt/c don’t carry genuine, persistent Linux-style permission bits — what you see is synthesized from mount defaults rather than stored per file. If your workflow genuinely needs chmod/chown to persist meaningfully on Windows-side files, DrvFs’s metadata mode (configured via automount options in /etc/wsl.conf) stores that information in NTFS extended attributes instead, at the cost of added complexity worth reserving for cases where you’ve confirmed you actually need it.

Recognizing when a slowdown is specifically this cross-filesystem cost

If a specific operation — cloning a repository, running a dependency install — feels slower than expected, timing the identical operation from both /mnt/c and your Linux home directory quickly confirms whether the cross-filesystem bridge is the actual cause, rather than guessing at a different explanation (network latency, a misconfigured tool) that isn’t actually the bottleneck.

Symlinks behave differently depending on which side created them

A symbolic link created on the Linux side generally isn’t interpreted the same way by Windows-native tools browsing the same path via \\wsl.localhost\, and vice versa for Windows-native shortcuts or junctions viewed from Linux. If a script or workflow depends on symlink behavior working identically from both sides, test that specific behavior directly on your own setup rather than assuming it transfers seamlessly across the bridge without any adjustment.

Related:

Sources: