Return to Answer

In theory (I haven't tried it yet), if you are using Systemd, you could also create a .mount with the proper dependency in place to workaround the issue.

Option 2: A bind mount in /mnt/wsl

Older version of Option 1, left here for posterity. Note that this will work even if the second distribution isn't running yet. Option 1 requires that the distro be running in advance for it to be available in /mnt/wsl.

Adapted from this GitHub comment, you should be able to do:

mkdir /mnt/wsl/otherinstance
wsl.exe -d otherinstance -u root mount --bind / /mnt/wsl/otherinstance/

Honestly, this one scares me a little bit, because the "otherinstance" shuts down soon after the command is run (unless it was already running elsewhere). However, the mount seems stable, probably because (as later comments in that GitHub issue mention) all of the "drives" are available from the WSL2/Hyper-V subsystem anyway; they aren't necessarily dependent on the instance itself.

Regardless, it would be easy to allay my (probably unfounded) fears by simply running the "otherinstance" manually and performing the mount --bind from that instance itself.

Option 3: Use wsl.exe's stdin/stdout

_{(Bonus: This methods works on WSL1 as well)}

Option 4: ssh

Note that setting up ssh on WSL instances isn't all that straightforward, but it's probably easier if you are only accessible it via localhost. At the least, you'll need a separate port number for each instance. I recommend reserving 22 for the Windows host itself (potentially using the Windows OpenSSH Server).

Also note that there's no concept of an init script that runs at startup in WSL, nor any Systemd equivalent. So you'll need to start the ssh server for each instance manually, or find some other method.

If you are using Systemd, you can also create a .mount file to workaround the issue. See @SteveMeierhofer's answer for details.

Option 2: Use wsl.exe's stdin/stdout

_{(Bonus #1: This method works on WSL1 as well)
(Bonus #2: It requires no advance configuration)
(Bonus #3: It will work even if the second distribution isn't running yet. Option 1 requires that the distro be running in advance for it to be available in /mnt/wsl.)}

Option 3: ssh

Note that setting up ssh on WSL instances isn't all that straightforward, but it's probably easier if you are only accessing it via localhost. At the least, you'll need a separate port number for each instance. I recommend reserving 22 for the Windows host itself (potentially using the Windows OpenSSH Server).

Option 4: A bind mount in /mnt/wsl

Older version of Option 1, left here for posterity.

Adapted from this GitHub comment, you should be able to do:

mkdir /mnt/wsl/otherinstance
wsl.exe -d otherinstance -u root mount --bind / /mnt/wsl/otherinstance/

Honestly, this one scares me a little bit, because the "otherinstance" shuts down soon after the command is run (unless it was already running elsewhere). However, the mount seems stable, probably because (as later comments in that GitHub issue mention) all of the "drives" are available from the WSL2/Hyper-V subsystem anyway; they aren't necessarily dependent on the instance itself.

Regardless, it would be easy to allay my (probably unfounded) fears by simply running the "otherinstance" manually and performing the mount --bind from that instance itself.

Updated answer with the method I've been using for some time.

Under recent WSL releases (0.47.1 and later, I believe), a timing issue means that the fstab is processed and mounted before /mnt/wsl (a tmpfs) is mounted. If you are using a recent WSL release, and you find that /mnt/wsl/ does not contain an instances subdirectory, then:

_{Updated, answer with the method I've personally been using for some time.}

Under recent WSL releases (0.47.1 and later, I believe), a timing issue/change means that the fstab is processed and mounted before /mnt/wsl (a tmpfs filesystem) is mounted. If you are using a recent WSL release, and you find that /mnt/wsl/ does not contain an instances subdirectory, then:

_{(Bonus: This methods works on WSL1 as well)}

_{(Credit and thanks to @mtraceur for the comment/suggestion and subsequent edited command. Simplified quoting is always a welcome change!)}

After terminating the WSL distribution and restarting (to process /etc/fstab), your distribution will be available under /mnt/wsl/instances/<distroname> from all other WSL2 distributions.

See my related answer on Ask Ubuntu for details on why this works.

_{¹ (Credit and thanks to @mtraceur for the comment/suggestion and subsequent edited command. Simplified quoting is always a welcome change!)}

After terminating the WSL distribution and restarting (to process /etc/fstab), your distribution will be available under /mnt/wsl/instances/<distroname> from all other WSL2 distributions.

_{² See Option 1.5 if this doesn't work}

See my related answer on Ask Ubuntu for details on why this works.

Option 1.5: /etc/fstab workaround for recent WSL releases

Under recent WSL releases (0.47.1 and later, I believe), a timing issue means that the fstab is processed and mounted before /mnt/wsl (a tmpfs) is mounted. If you are using a recent WSL release, and you find that /mnt/wsl/ does not contain an instances subdirectory, then:

sudo -e /etc/wsl.conf

And add the following:

[automount]
mountFsTab = false

[boot]
command = sleep 5; mount -a

This should wait long enough before processing /etc/fstab to allow /mnt/wsl to be mounted by WSL first.

In theory (I haven't tried it yet), if you are using Systemd, you could also create a .mount with the proper dependency in place to workaround the issue.