Accessing a File in Two Different WSL2 Installations on Windows

You can access files across two different WSL2 Linux distributions by leveraging the shared Windows filesystem. Since both instances run on the same Windows host, they can read and write to the same directories in /mnt/c or other mounted drives. This eliminates the need for complex network shares like Samba and allows seamless collaboration between distros.

The Shared Filesystem Architecture

Windows Subsystem for Linux 2 (WSL2) operates as a lightweight virtual machine. However, it maintains a persistent bridge to the Windows host operating system. This bridge mounts your Windows drives into the Linux environment at specific mount points. By default, the primary drive is accessible at /mnt/c. Any file stored here is visible to every WSL2 instance running on that Windows machine. This architecture means that if you install Ubuntu and Debian side-by-side, both distributions see the exact same data in /mnt/c/Users/YourName/Documents. You do not need to configure IP addresses, set up SSH keys between distros, or manage synchronization services. The Windows kernel handles the file I/O, ensuring consistency.

Step-by-Step Guide to Cross-Distro Access

To modify a file from two different installations, follow these concrete steps. This method assumes you have two distinct WSL2 distributions installed, such as Ubuntu and Kali Linux.

1. Identify the Target Directory: Choose a folder on your Windows drive where the file resides. For example, C:\Projects\SharedFile.txt.
2. Open the First Distribution: Launch your terminal for the first distro (e.g., Ubuntu). Navigate to the shared location using the command:

   cd /mnt/c/Projects

   Verify the file exists with ls -l SharedFile.txt.
3. Edit the File: Use your preferred text editor. For instance, open the file in Vim:

   vim SharedFile.txt

   Make your changes and save them.
4. Open the Second Distribution: Launch your second distro (e.g., Debian). Navigate to the identical path:

   cd /mnt/c/Projects

   Notice that the file appears instantly. It contains the modifications made in the first distro.
5. Modify Again: Open and edit the file again. Both instances reflect the current state of the file on the disk.

This process works because the underlying NTFS filesystem is accessed directly through the drvfs driver in WSL2. There is no caching layer that isolates one distro from another when writing to /mnt/c.

Important Considerations for Line Endings

When editing files in WSL2 that are also used by Windows applications, be aware of line ending differences. Linux uses LF (\n), while Windows uses CRLF (\r\n). If you edit a file in WSL2 and then open it in Notepad on Windows, it may appear as a single long line. Conversely, Windows editors might introduce extra characters when saving. To mitigate this, use tools like dos2unix or unix2dos within your WSL2 terminals. Alternatively, configure your Windows text editor to handle Unix-style line endings natively. This ensures compatibility regardless of which distribution modifies the file.

Why Samba Is Unnecessary Here

Many users initially consider setting up a Samba share to allow communication between Linux environments. While Samba is excellent for cross-platform sharing between Windows and Linux, it adds unnecessary complexity for intra-WSL2 communication. Configuring a Samba server requires managing authentication, permissions, and network interfaces within the virtualized environment. By using the native /mnt/c mount, you bypass all networking overhead. The performance is often superior because the data does not traverse a virtual network stack; it goes straight to the Windows filesystem API. This approach is simpler, more secure, and less prone to configuration errors. For related troubleshooting, you might encounter issues where your default distribution is not found. You can resolve this by checking your WSL configuration settings, similar to how one addresses the WSL_E_DEFAULT_DISTRO_NOT_FOUND Error on Windows.

Performance and Permissions

Accessing files via /mnt/c is fast, but it is slightly slower than accessing native Linux filesystems located within the WSL2 ext4.vhdx file. Microsoft recommends keeping source code and large datasets within the Linux filesystem for optimal build times. However, for configuration files, scripts, and small documents, the shared directory approach is perfectly adequate. Permissions can sometimes behave unexpectedly. Files created in /mnt/c will retain their Windows ownership attributes. When you view them in Linux, they may show generic permissions. To change permissions, you must use chmod and chown commands carefully, understanding that these changes affect the Windows security descriptor. If you need to copy binary files or specific binaries between your WSL2 environment and Windows, ensure you understand the format implications. Referencing guides on Copying "bin" file to windows (WSL2) can help clarify how executable formats are handled during transfer.

Frequently Asked Questions

Can I edit the same file simultaneously in both distros?

Yes, you can open the file in both terminals, but concurrent writes can cause conflicts. It is safer to close the file in one distro before editing it in the other to prevent data corruption.

Does this work for WSL1 as well?

Yes, WSL1 also mounts Windows drives at /mnt/c, so the same principle applies. However, WSL2 is recommended for better performance and full Linux kernel compatibility.

How do I fix permission denied errors on /mnt/c?

This usually happens if the Windows file has restrictive ACLs. Run wsl --shutdown and restart your distro, or adjust the file properties in Windows Explorer to grant access to your user account.

Is there a limit to the number of distros that can access these files?

No, any WSL2 distribution running on the same Windows host can access the same /mnt/c paths. There is no inherent limit to the number of simultaneous readers or writers.

What happens if I delete a file in one distro?

The file is permanently deleted from the Windows filesystem. All other distros will immediately lose access to it. Always verify the path before executing deletion commands.