7

I have been setting up Ubuntu on Windows 10 WSL 2 so that I can start to ssh into a workstation at my school. I haven't had issues with ssh-ing into the remote computer, but haven't been able to open a GUI with an X server.

Ubuntu 20.04.1 LTS

Windows 10.0.19041 N/A Build 19041

Issue: Whenever I try to open an X server GUI I get this- after a minute pause: Can't Open Display Error

I am running VcXsrv xLaunch with these settings that I have found in other guides.

Display settings Client startup Extra settings

I make sure to run export DISPLAY=$(cat /etc/resolv.conf | grep nameserver | awk '{print $2}'):0 before I make any attempts, but I have also added it to ~/.bashrc so it shouldn't really matter.

I have modified the ssh_config and sshd_config files to uncomment the X11 forwarding.

ssh_config sshd_config

Just in case it is important, I have been using xeyes or xclock to test.

I have been having a really tough time with this so I would appreciate absolutly anything that helps push me in the right direction. I would be happy to provide any additional information if it could help solve this issue.

Thanks to everyone!!

Quick Edit: I realized that I don't have a .Xauthority file and I am unable to generate one (gives xauth: (argv):1: unable to open display ":0". when I try). I'm not sure if this is part of the issue.

Edit: Based on a suggestion from @harrymc I created a new vcxsrv profile using these flags: "C:\Program Files\VcXsrv\vcxsrv.exe" :0 -ac -terminate -lesspointer -multiwindow -clipboard -wgl -dpi auto

I ran netstat -abno|findstr 6000 in an admin Powershell, and got this result, but I'm not sure how to interpret it.

Next, I installed terminator to test my changes, but no GUI window was opened and my terminal gave me these messages, with a several minute delay between [1] 47, and the second message.

Edit: Changed ~/.bashrc to export DISPLAY=localhost:0.0. The error remains basically the same Error: Can't open display: localhost:0.0. I am attempting to debug the DISPLAY command now.

Paul
  • 231

6 Answers6

12

I came here several years later with a similar problem. As others have mentioned, none of the setting DISPLAY variables is necessary anymore. For me, starting X applications suddenly stopped working one day, while Wayland applications still worked.

There is a document Diagnosing "cannot open display" type issues with WSLg providing some possible solutions to the problem.

GUI application support in WSL2 is provided by wslg. The way it works is that it starts a separate system container with a readonly root file system, but apparently sharing the same network interface and having your container file system mounted. In the system container it starts Weston as a Wayland server and Xwayland as an X server. You can open a shell in the system container by running wsl --system, although you can't do much there apart from verifying that Xwayland is running.

Some parts of the system container are mounted into your Linux container at /mnt/wslg. You can inspect some log files there.

For me the problem was about /tmp/.X11-unix. It needs to be a symlink to /mnt/wslg/.X11-unix, but for me it was an empty directory. I temporarily fixed the problem like this:

rmdir /tmp/.X11-unix && ln -s /mnt/wslg/.X11-unix /tmp/.X11-unix

However, the symlink was removed again every time WSL was started. This seems to have been caused by either my tmp.mount or systemd-tmpfiles-setup.service of systemd, which clears the /tmp directory. I solved it by creating this file in /etc/systemd/system/wslg.service:

[Unit]
Description=symlink /tmp/.X11-unix
After=systemd-tmpfiles-setup.service

[Service] Type=oneshot ExecStart=rmdir /tmp/.X11-unix ExecStart=ln -s /mnt/wslg/.X11-unix /tmp/

[Install] WantedBy=sysinit.target

An then enabling it using systemctl enable wslg.

cdauth
  • 517
6

I was able to solve the issue thanks to a similar post I made on Github. Thanks to moloned there for the help.

I changed my display to this as you suggested:

export DISPLAY="grep nameserver /etc/resolv.conf | sed 's/nameserver //':0"

This didn't solve this issue... BUT in that link you posted, I looked at some of >the solutions people were offering. I decided to check VcXsrv's firewall >permissions and discovered it never even created a profile for itself when I >installed it.

I went to Control Panel > System and Security > Windows Defender Firewall > >Advanced Settings > Inbound Rules > New Rule... > Program > %ProgramFiles%\VcXsrv\vcxsrv.exe > Allow the connection > checked >Domain/Private/Public > Named and Confirmed Rule.

And it worked!!! I've been working on this for 3 days, I don't know how it has >taken this long to find the solution, but I am so grateful for your help @moloned!

Link to my thread on Github

Paul
  • 231
2

Update for users finding this question in late 2022 or later.

Remove all export DISPLAY settings in your startup files!

It's not needed anymore. With recent WSL the system takes care of that. You also don't need third-party X server software, as WSLg is now available on Windows 10 Build 19044+.

I repeat.

You do no longer need to export the DISPLAY variable!

You can see it is not mentioned anywhere in the official documentation anymore.

Backstory

I, and many with me, use non-default name servers, so I can't use that trick to refer to my local system. Instead I have a static value for IPv6 localhost in /etc/hosts.

# This is to always have a named host address for servers on WSL, like sshd
# Usually I use 127.0.0.1 instead.
::1     wsl

And the same in Windows c:\Windows\System32\drivers\etc\hosts

Then I had set the DISPLAY variable in ~/.bashrc like this.

export DISPLAY=wsl:0.0

When testing both thunderbird and mousepad start fine.

But if I tried to start firefox/firefox-esr I got failed access to DISPLAY.

$ firefox-esr
Error: cannot open display: wsl:0.0

Basically, thunderbird never cared what DISPLAY was set to. Perhaps that is why it worked for me. It started even back when the variable was set to the wrong IP.

But, now, with no DISPLAY variable manually set, firefox works great!

Information about my Windows 10 system.

$ uname -a
Linux pappa 5.15.79.1-microsoft-standard-WSL2 #1 SMP Wed Nov 23 01:01:46 \
UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

$ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 22.04.1 LTS Release: 22.04 Codename: jammy

> wsl --version WSL-version: 1.0.3.0 Kernelversion: 5.15.79.1 WSLg-version: 1.0.47 MSRDC-version: 1.2.3575 Direct3D-version: 1.606.4 DXCore-version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp Windows: 10.0.19045.2364

> wsl -l -v NAME STATE VERSION

  • Ubuntu Running 2 Debian Stopped 2

NVIDIA Geforce GTX 1070, driver 527.56

Apps that I tested.

$ thunderbird --version
 Thunderbird 102.6.1

$ mousepad --version Mousepad 0.5.8

$ firefox --version Mozilla Firefox 108.0.1

$ firefox-esr --version Mozilla Firefox 102.6.0esr

Even something heavy like GIMP runs fine.

$ gimp --version
GNU Image Manipulation Program version 2.10.30

And finally... (this is with no export DISPLAY set anywhere)

$ set | grep DISPLAY
DISPLAY=:0
WAYLAND_DISPLAY=wayland-0
1

For users with old(ish) WSL2 Ubuntu installation who experiencing Can't open display error, the easy fix is:

wsl --unregister ubuntu
wsl --install -d ubuntu
wsl --update

Run Ubuntu --> register your user name and password, then:

# Install X-service
sudo apt update
sudo apt install x11-apps
# Test
env | grep -i display
# Should return:
# WAYLAND_DISPLAY=wayland-0
# DISPLAY=:0
xeyes &
xcalc
0
export DISPLAY=$(grep nameserver /etc/resolv.conf | sed 's/nameserver //'):0

I suspect HTML or the markdown tool ate your backquotes. The above is working for me in my .profile running bash shell from a pretty fresh WSL2 Unbuntu installation. I'm not currently willing to install the Windows development version for native gpu support, but VcXsrv works fine for now.

0

@NoSubstitute's answer is correct, what I was missing is that I had to update my WSL.
I was on WSL 2, but apparently WSLg, the part that makes WSL compatible with Wayland/X server, is bundled in the newer versions.

I've done the following steps to update:

  • wsl --update
  • wsl --shutdown (will restart wsl)

Then you can run env | grep DISPLAY and see that the required vars are set.

EcksDy
  • 101