wslg: Cannot launch gui apps with 2.0.12

Not sure if this survives a WSL virtual machine reboot.

I’m using Arch Linux and have the same issue. I created a fix for this that runs those commands as a systemd service (iirc Fedora comes with systemd as well, but regardless of your distro, as long as it uses systemd, it should work). This means that the service will run those commands on boot.

This is under the assumption that running those commands does not lead to any unforeseen side effects (I haven’t seen any so far, from my understanding, those commands are fine to run…).

1. Creating the systemd service file

Start by creating a systemd service file at the following location, /etc/systemd/system/. You can name the service file whatever you like, however, keep in mind that the name of the file must have a suffix of service. Then open the file with your preferred text editor. In my case, I ran the following:

sudo nano /etc/systemd/system/x11-symlink.service

Note: nano creates a file if it doesn’t exist by default, if your text editor doesn’t do this, you’ll need to create the file first with touch.

2. Write the scripts for the service

To preface this part, I personally never had anything mounted on /tmp/.X11-unix, so running the umount command for that would result in an error. I would recommend running this command on your terminal just to see if you actually need it or not.

In the service file, add the following contents to it:

[Unit]
Description=Setup X11 Symlink

[Service]
Type=oneshot
ExecStartPre=/bin/umount /tmp/.X11-unix
ExecStartPre=/bin/rm -rf /tmp/.X11-unix
ExecStart=/bin/ln -s /mnt/wslg/.X11-unix /tmp/.X11-unix

[Install]
WantedBy=multi-user.target

If you do not need to run the umount command, you should remove it, otherwise the service will fail and exit.

Now you can save and exit the file.

3. Enable the service

To enable the service, we first need to reload systemd to recognize the new service:

sudo systemctl daemon-reload

Then we can enable the service on boot:

sudo systemctl enable x11-symlink.service

Note: the name of the service would be the name of the file you created earlier, make sure this matches.

At this point, you can restart WSL and verify if the service worked by running:

sudo systemctl status x11-symlink.service

If you want to manually start the service without having to restart WSL, you can run the following directly:

sudo systemctl start x11-symlink.service

To verify that it did work, run ls /tmp/.X11-unix and you should see something like X0 or X1, indicating your display.

Hope this helps, lmk if you need extra clarification.

Disabling systemd in /etc/wsl.conf is a permanent workaround, but not an option for me

Have had a similar problem with GUI applications after updating to WSL 2.0.12.0:

$ xclock
Error: Can't open display: :0

$ wsl.exe --version
WSL version: 2.0.12.0
Kernel version: 5.15.133.1-1
WSLg version: 1.0.59
MSRDC version: 1.2.4677
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.19045.3570

Fixed by running the following commands:

sudo umount /tmp/.X11-unix
sudo rm -rf /tmp/.X11-unix
sudo ln -s /mnt/wslg/.X11-unix /tmp/.X11-unix

and GUI applications were working again.

Not sure if this survives a WSL virtual machine reboot.

This solution was found here: https://github.com/microsoft/wslg/issues/558#issuecomment-1260817709

I confirm also here same behaviour. Temporarily fixed with this command as root (Does not survive at reboot): rm -rf /tmp/.X11-unix && ln -s /mnt/wslg/.X11-unix /tmp/

Still there with 2.1.3.0

I did try to raise the visibility of this issue by reporting it again in the WSL repo (https://github.com/microsoft/WSL/issues/11064) but the ticket got closed because it didn’t have “steps to reproduce” even though I pointed to this ticket. 😦