Create a Link Between Local Windows Files and WSL

Creating a link between local Windows files and WSL (Windows Subsystem for Linux) is a useful way to share files between the two environments.

In this guide, I’ll show how to link a folder in Windows to your WSL instance using the ln command, and also explain how to remove a linked folder.

> Create a New Linked Folder for WSL
> Create and Modify Files in the Linked Folder
> Remove a Linked Folder
> Final Thoughts

Create a New Linked Folder for WSL

The ln command in Linux is used to create links between files. In this example, we’ll use a symbolic link to share a folder between the Windows file system and WSL.

First, ensure that you’re familiar with the /mnt/c path, which is where your C: drive is mounted in WSL.

To link a folder from Windows (e.g., a projects folder on your C: drive), use the following command:

# create a symlink at ~/projects pointing at C:\projects
ln -s /mnt/c/projects ~/projects

The -s flag creates a symbolic link (as opposed to a hard link), allowing you to access the folder in both WSL and Windows.

Order matters: the real folder first, the link name second. Checked on Ubuntu 24.04: ln -s /mnt/c/projects ~/projects creates ~/projects pointing at the Windows folder. Swap the two and you get a dead link called projects dropped inside the Windows folder, pointing at a path that does not exist, and ln reports no error either way.

The screenshot shows the shorter ln -s /mnt/c/projects with no destination. That does the same thing, but only when you run it from your home directory, because ln then names the link after the folder it points at and drops it where you are standing. Naming the destination explicitly is the version that works from anywhere, and it is what the rest of this post assumes.

Create and Modify Files in the Linked Folder

Once the link is created, you can create a folder or a file within your WSL environment that is directly tied to your Windows file system.

For example, in the screenshot below I’m creating a new file within the linked folder:

This has created a folder and a file within the linked projects folder, which is located on my Windows file system.

You can view and modify these files from either Windows or WSL.

Remove a Linked Folder

If you no longer need the link, you can easily remove it. First, list the files to check for existing links, then use the rm command to delete the symbolic link:

# show the link itself (ls -l ~/projects would list the Windows folder through it)
ls -ld ~/projects

# Remove the symbolic link (only deletes the link)
rm ~/projects

Note that using rm only removes the symbolic link in the WSL environment; the original folder and files on your Windows drive remain intact:

The chmod Trap on /mnt/c

Run ls -l inside the linked folder and everything shows as rwxrwxrwx, then chmod 600 on a key file or a script changes nothing. That is not the link, it is how WSL mounts Windows drives. Without the metadata mount option, DrvFs has nowhere on NTFS to store Linux permission bits, so it shows your own Windows access on all three positions and chmod can only toggle the Windows read-only attribute. Microsoft documents this in File Permissions for WSL.

If you need real permissions on the Windows side, turn metadata on for the distribution and restart it:

# /etc/wsl.conf, inside the distro
[automount]
options = "metadata"

# then from PowerShell
wsl --shutdown

With metadata on, chmod and chown stick, and new files follow your umask (022 by default). It still cannot give you more access than your Windows account has. For SSH keys and anything Git cares about, the simpler answer is to keep them in the Linux file system and use the link for everything else.

Final Thoughts

Creating links between local Windows files and WSL is a simple and effective way to share files between the two environments. However, it’s important to note that using mounted Windows drives for version-controlled projects can lead to issues, like chmod errors. The permission bits under /mnt/c are the Windows side showing through, as covered above, and the mount itself is slower than the Linux file system, which Access Local Files from Windows Subsystem for Linux (WSL) goes into.

For smoother operation, keep version-controlled projects inside the Linux file system and use the link for moving files across rather than for working in. That keeps the flexibility of reaching both environments without putting your builds and Git operations across the boundary.

---

Related

• Access Local Files from Windows Subsystem for Linux (WSL)
• How to Open WSL Projects in Windows File Explorer
• Setting up SSH Keys in WSL

If SQL Server is part of your day job, my current work lives over at sqldba.blog: production DBA scripts, an error library and the SSMS guide.