Return to Answer

What's not working

Let's start with summarizing what you are attempting:

1. Take a Kali ext4 filesystem
2. Share that via the 9p protocol (WSL2 does this for you automatically)
3. Connect to it from Windows (again, WSL2 does this for you automatically)
4. Map a Windows drive letter to that network drive
5. Mount that drive in Ubuntu via 9p/drvfs
6. chroot into that mount point

The main problem occurs early in the process, at step #3 (perhaps even #2). At this point, since Windows doesn't understand Linux symlinks, as you've noticed, these are just turned into files.

Attempting to then turn around and mount this drive back into another WSL instances doesn't turn these back into links.

How to get it running

At least one method is to use the /mnt/wsl cross-distro mount point. The downside is that this is a tmpfs mount created by WSL, and your mount point inside it will need to be recreated after each WSL restart.

From Kali:

sudo mount --bind / /mnt/wsl/kali -o "X-mount.mkdir"

From Ubuntu:

chroot /mnt/wsl/kali
mount -t proc proc /proc

There should be an relatively easy way to get Kali to automount itself using /etc/fstab with the X-mount.mkdir option so that Kali's mount will automatically create the needed directory after each restart. However, I haven't tested this yet myself.

Note that there are a few WSL things that won't "work" without additional effort inside the chroot:

• The Windows Path will not automatically be appended to the Linux PATH (solvable via some env magic and other techniques)
• Windows drives will not automatically be mounted at, for example, /mnt/c, etc. (solvable via /etc/fstab from within Ubuntu to mount the drives into the Kali fs).
• Even if the drive is mounted, running a Windows .exe won't work (solvable by bind mounting the Interop socket location from Ubuntu to the Kali fs)
• On Windows 11, WSLg will not work (Solvable by bind mounting the WSLg/X11 socket from Ubuntu to Kali)

What's not working

Let's start with summarizing what you are attempting:

1. Take a Kali ext4 filesystem
2. Share that via the 9p protocol (WSL2 does this for you automatically)
3. Connect to it from Windows (again, WSL2 does this for you automatically)
4. Map a Windows drive letter to that network drive
5. Mount that drive in Ubuntu via 9p/drvfs
6. chroot into that mount point

The main problem occurs early in the process, at step #3 (perhaps even #2). At this point, since Windows doesn't understand Linux symlinks, as you've noticed, these are just turned into files.

Attempting to then turn around and mount this drive back into another WSL instances doesn't turn these back into links.

How to get it running

At least one method is to use the /mnt/wsl cross-distro mount point.

From Kali:

sudo mount --bind / /mnt/wsl/kali -o "X-mount.mkdir"

If you'd like for the mount to be done automatically each time you restart Kali, then:

sudo sh -c "grep '/mnt/wsl/kali' /proc/mounts >> /etc/fstab"

Then vi /etc/fstab and add the option X-mount.mkdir to the mount.

From Ubuntu:

chroot /mnt/wsl/kali
mount -t proc proc /proc

Note that there are a few WSL things that won't "work" without additional effort inside the chroot:

• The Windows Path will not automatically be appended to the Linux PATH (solvable via some env magic and other techniques)
• Windows drives will not automatically be mounted at, for example, /mnt/c, etc. (solvable via /etc/fstab from within Ubuntu to mount the drives into the Kali fs).
• Even if the drive is mounted, running a Windows .exe won't work (solvable by bind mounting the Interop socket location from Ubuntu to the Kali fs)
• On Windows 11, WSLg will not work (Solvable by bind mounting the WSLg/X11 socket from Ubuntu to Kali)

See another one of my answer's on Ask Ubuntu which cover a couple of these solutions (Interop and WSLg). I've actually solved the problem with mounting Windows drives as well, but I haven't had a chance to update the info there yet.

What's not working

Let's start with summarizing what you are attempting:

1. Take a Kali ext4 filesystem
2. Share that via the 9p protocol (WSL2 does this for you automatically)
3. Connect to it from Windows (again, WSL2 does this for you automatically)
4. Map a Windows drive letter to that network drive
5. Mount that drive in Ubuntu via 9p/drvfs
6. chroot into that mount point

The main problem occurs early in the process, at step #3 (perhaps even #2). At this point, since Windows doesn't understand Linux symlinks, as you've noticed, these are just turned into files.

Attempting to then turn around and mount this drive back into another WSL instances doesn't turn these back into links.

How to get it running

At least one method is to use the /mnt/wsl cross-distro mount point. The downside is that this is a tmpfs mount created by WSL, and your mount point inside it will need to be recreated after each WSL restart.

From Kali:

sudo apt install bindfs # not installed by default on minimal WSL Kali
sudo mkdir /mnt/wsl/kali
sudo mount --bind / /mnt/wsl/kali

From Ubuntu:

chroot /mnt/wsl/kali
mount -t proc proc /proc

There should be an relatively easy way to get Kali to automount itself using /etc/fstab with the X-mount.mkdir option so that Kali's mount will automatically create the needed directory after each restart. However, I haven't tested this yet myself.

Note that there are a few WSL things that won't "work" without additional effort inside the chroot:

• The Windows Path will not automatically be appended to the Linux PATH (solvable via some env magic and other techniques)
• Windows drives will not automatically be mounted at, for example, /mnt/c, etc. (solvable via /etc/fstab from within Ubuntu to mount the drives into the Kali fs).
• Even if the drive is mounted, running a Windows .exe won't work (solvable by bind mounting the Interop socket location from Ubuntu to the Kali fs)
• On Windows 11, WSLg will not work (Solvable by bind mounting the WSLg/X11 socket from Ubuntu to Kali)

What's not working

Let's start with summarizing what you are attempting:

1. Take a Kali ext4 filesystem
2. Share that via the 9p protocol (WSL2 does this for you automatically)
3. Connect to it from Windows (again, WSL2 does this for you automatically)
4. Map a Windows drive letter to that network drive
5. Mount that drive in Ubuntu via 9p/drvfs
6. chroot into that mount point

The main problem occurs early in the process, at step #3 (perhaps even #2). At this point, since Windows doesn't understand Linux symlinks, as you've noticed, these are just turned into files.

Attempting to then turn around and mount this drive back into another WSL instances doesn't turn these back into links.

How to get it running

At least one method is to use the /mnt/wsl cross-distro mount point. The downside is that this is a tmpfs mount created by WSL, and your mount point inside it will need to be recreated after each WSL restart.

From Kali:

sudo mount --bind / /mnt/wsl/kali -o "X-mount.mkdir"

From Ubuntu:

chroot /mnt/wsl/kali
mount -t proc proc /proc

There should be an relatively easy way to get Kali to automount itself using /etc/fstab with the X-mount.mkdir option so that Kali's mount will automatically create the needed directory after each restart. However, I haven't tested this yet myself.

Note that there are a few WSL things that won't "work" without additional effort inside the chroot:

• The Windows Path will not automatically be appended to the Linux PATH (solvable via some env magic and other techniques)
• Windows drives will not automatically be mounted at, for example, /mnt/c, etc. (solvable via /etc/fstab from within Ubuntu to mount the drives into the Kali fs).
• Even if the drive is mounted, running a Windows .exe won't work (solvable by bind mounting the Interop socket location from Ubuntu to the Kali fs)
• On Windows 11, WSLg will not work (Solvable by bind mounting the WSLg/X11 socket from Ubuntu to Kali)

What's not working

Let's start with summarizing what you are attempting:

1. Take a Kali ext4 filesystem
2. Share that via the 9p protocol (WSL2 does this for you automatically)
3. Connect to it from Windows (again, WSL2 does this for you automatically)
4. Map a Windows drive letter to that network drive
5. Mount that drive in Ubuntu via 9p/drvfs
6. chroot into that mount point

The main problem occurs early in the process, at step #3 (perhaps even #2). At this point, since Windows doesn't understand Linux symlinks, as you've noticed, these are just turned into files.

Attempting to then turn around and mount this drive back into another WSL instances doesn't turn these back into links.

How to get it running

At least one method is to use the /mnt/wsl cross-distro mount point. The downside is that this is a tmpfs mount created by WSL, and your mount point inside it will need to be recreated after each WSL restart.

From Kali:

sudo mkdir /mnt/wsl/kali
sudo mount -t bind / /mnt/wsl/kali

From Ubuntu:

chroot /mnt/wsl/kali
mount -t proc proc /proc

There should be an relatively easy way to get Kali to automount itself using /etc/fstab with the X-mount.mkdir option so that Kali's mount will automatically create the needed directory after each restart. However, I haven't tested this yet myself.

Note that there are a few WSL things that won't "work" without additional effort inside the chroot:

• The Windows Path will not automatically be appended to the Linux PATH (solvable via some env magic and other techniques)
• Windows drives will not automatically be mounted at, for example, /mnt/c, etc. (solvable via /etc/fstab from within Ubuntu to mount the drives into the Kali fs).
• Even if the drive is mounted, running a Windows .exe won't work (solvable by bind mounting the Interop socket location from Ubuntu to the Kali fs)
• On Windows 11, WSLg will not work (Solvable by bind mounting the WSLg/X11 socket from Ubuntu to Kali)

What's not working

Let's start with summarizing what you are attempting:

1. Take a Kali ext4 filesystem
2. Share that via the 9p protocol (WSL2 does this for you automatically)
3. Connect to it from Windows (again, WSL2 does this for you automatically)
4. Map a Windows drive letter to that network drive
5. Mount that drive in Ubuntu via 9p/drvfs
6. chroot into that mount point

The main problem occurs early in the process, at step #3 (perhaps even #2). At this point, since Windows doesn't understand Linux symlinks, as you've noticed, these are just turned into files.

Attempting to then turn around and mount this drive back into another WSL instances doesn't turn these back into links.

How to get it running

At least one method is to use the /mnt/wsl cross-distro mount point. The downside is that this is a tmpfs mount created by WSL, and your mount point inside it will need to be recreated after each WSL restart.

From Kali:

sudo apt install bindfs # not installed by default on minimal WSL Kali
sudo mkdir /mnt/wsl/kali
sudo mount --bind / /mnt/wsl/kali

From Ubuntu:

chroot /mnt/wsl/kali
mount -t proc proc /proc

There should be an relatively easy way to get Kali to automount itself using /etc/fstab with the X-mount.mkdir option so that Kali's mount will automatically create the needed directory after each restart. However, I haven't tested this yet myself.

Note that there are a few WSL things that won't "work" without additional effort inside the chroot:

• The Windows Path will not automatically be appended to the Linux PATH (solvable via some env magic and other techniques)
• Windows drives will not automatically be mounted at, for example, /mnt/c, etc. (solvable via /etc/fstab from within Ubuntu to mount the drives into the Kali fs).
• Even if the drive is mounted, running a Windows .exe won't work (solvable by bind mounting the Interop socket location from Ubuntu to the Kali fs)
• On Windows 11, WSLg will not work (Solvable by bind mounting the WSLg/X11 socket from Ubuntu to Kali)