Adding SSHFS mounted shares between 2 NAMED LAN clients, with an mDNS python script

Loading

Install OpenSSH Server:

Bash

sudo apt update
sudo apt install openssh-server
Configure SSHD: (Optional, but good for setup)
Edit /etc/ssh/sshd_config (e.g., sudo nano /etc/ssh/sshd_config):

Ensure Port 22 is uncommented or set to your desired port.

Ensure ListenAddress 0.0.0.0 to allow connections from any IP within WSL2's network (or even LAN if proxied).

PasswordAuthentication yes (for initial testing, but consider SSH keys for long-term security).

Subsystem sftp /usr/lib/openssh/sftp-server (this line should already be there).
Save changes and exit.

Restart SSH service:

Bash

sudo service ssh restart
Crucially: Enable LAN access for PC_B's WSL2 on PC_B's Windows host.
This is identical to the previous explanation for Windows Explorer access because the core problem is how to expose WSL2's internal IP to the LAN.

Preferred (Windows 11 22H2+): Mirrored Mode Networking:
On PC_B's Windows, edit C:\Users\YourWindowsUsername\.wslconfig (create if doesn't exist):

[wsl2]
networkingMode=mirrored
Then, in PowerShell on PC_B, wsl --shutdown and restart your WSL2 distro. This will give PC_B's WSL2 instance an IP directly on your LAN. Note down this IP address.

Alternative (older Win11 or if mirrored mode issues): Port Forwarding:
On PC_B's Windows, in an Administrator PowerShell, set up port forwarding from PC_B's LAN IP to PC_B's WSL2 internal IP (e.g., for port 22, or 2222 if you changed it). Remember to also open a firewall rule on PC_B's Windows for that port.

Part 2: On PC_A (The Client WSL2 Instance)
This is the WSL2 instance where you want to mount the remote files.

Install SSHFS:
SSHFS relies on fuse (Filesystem in Userspace).

Bash

sudo apt update
sudo apt install sshfs
Load FUSE module (usually automatic, but good to check):

Bash

sudo modprobe fuse
(You typically don't need to do this manually in WSL2 anymore as it usually loads on demand).

Create a local mount point:
This is where the remote files will appear.

Bash

mkdir -p remote_babyhp
Mount the remote directory using SSHFS:
Now, from PC_A's WSL2 terminal, execute the sshfs command.

Bash

sshfs stevee@192.168.1.32:/var/www/ remote_hplaptop -o allow_other
Let's break down this command:

sshfs: The command to mount an SSH filesystem.

your_username_on_pc_b: The username you use to log in to WSL2 on PC_B (e.g., stevee).

PC_B_IP_ADDRESS:

If using Mirrored Mode Networking on PC_B: This will be the actual LAN IP address of PC_B's WSL2 instance.

If using Port Forwarding on PC_B: This will be the LAN IP address of PC_B's Windows host, not its WSL2 internal IP.

:/path/to/remote/folder: This is the absolute path to the directory on PC_B's WSL2 instance that you want to mount (e.g., :/home/stevee/my_project). The : separates the host/user from the remote path.

~/remote_pc_b_files: The local mount point you created on PC_A.

-o allow_other: This is important! By default, FUSE mounts are only accessible by the user who mounted them. allow_other makes the mounted filesystem accessible to other users (and processes) on PC_A's WSL2. This is often necessary for applications to interact with the mounted files.

Example:
If your user on PC_B is stevee, PC_B's WSL2 has the LAN IP 192.168.1.105 (via mirrored mode), and you want to mount /var/www from PC_B into ~/hplaptop_www on PC_A:

Bash

sshfs stevee@babyhp:/var/www sshfs_babyhp
OR which PC you on:
sshfs stevee@hplaptop:/var/www sshfs_hplaptop
It will then prompt you for the password for stevee on xx.

To Unmount:
When you're done, unmount the directory:

Bash

sudo umount ~/remote_pc_b_files
Advantages of SSHFS for WSL2-to-WSL2:
Security: SSH provides a secure, encrypted tunnel for file transfer.

No Samba Needed: You avoid the complexities of Samba configuration (smb.conf, smbpasswd, etc.) on the server side.

Familiar Linux Tools: You're using native Linux commands (sshfs, mount, umount) directly within your WSL2 environments.

Flexibility: You can mount specific directories rather than entire shares.

This method is highly recommended for inter-WSL2 file access, offering a clean and secure solution.