Running Google Chrome GUI in WSL
This was working for me a while ago but today, when I tried, it was not.
❯ google-chrome
[541540:541540:0825/114954.251188:ERROR:ozone_platform_x11.cc(244)] Missing X server or $DISPLAY
[541540:541540:0825/114954.251464:ERROR:env.cc(258)] The platform failed to initialize. Exiting.
There’s a good wiki on this available here.
The solution was simple and immediate:
export DISPLAY=:0
Importantly, this doesn’t carry through to a Jupyter notebook. To make this work in Jupyter notebooks, you need to use the %env magic command.
%env DISPLAY=:0
Let me re-read your post carefully to match your voice.Your style is direct and practical — problem statement, error output, brief context, solution, done. No fluff. You show rather than explain, and you trust the reader to follow along. Here's an update that matches:
Update: December 2025
Different failure mode this time. Chrome launched but no window appeared.
❯ google-chrome
[3365071:3365071:1205/114205.717359:ERROR:dbus/object_proxy.cc:573] Failed to call method: org.freedesktop.DBus.Properties.GetAll: object_path= /org/freedesktop/UPower/devices/DisplayDevice: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files
Created TensorFlow Lite XNNPACK delegate for CPU.
No X11 error. $DISPLAY was set correctly. But xeyes also ran without showing a window. The process was running, just invisible.
The wiki says /tmp/.X11-unix should be a symlink to /mnt/wslg/.X11-unix. Mine was a directory:
❯ ls -la /tmp/ | grep X11
drwxrwxrwx - root 24 Nov 12:12 .X11-unix
Tried to remove it:
❯ sudo rm -r /tmp/.X11-unix
rm: cannot remove '/tmp/.X11-unix/X0': Read-only file system
A read-only tmpfs was mounted on top:
❯ mount | grep X11
none on /tmp/.X11-unix type tmpfs (ro,relatime)
The culprit is a race condition between two systemd mechanisms. The xserver-common package includes /usr/lib/tmpfiles.d/x11.conf:
D! /tmp/.X11-unix 1777 root root 10d
This creates /tmp/.X11-unix as a directory during systemd-tmpfiles-setup.service. WSLg's wslg.service runs after and tries to bind-mount over it, resulting in the broken read-only state. Apps connect to what looks like an X socket but renders nowhere.
The fix is to override the tmpfiles rule so it creates a symlink instead:
echo 'L+ /tmp/.X11-unix - - - - /mnt/wslg/.X11-unix' | sudo tee /etc/tmpfiles.d/wslg-x11.conf
Then fix the current state:
sudo umount /tmp/.X11-unix
sudo rm -r /tmp/.X11-unix
ln -s /mnt/wslg/.X11-unix /tmp/.X11-unix
This survives wsl --shutdown. The L+ directive removes whatever exists and creates a symlink, so tmpfiles and WSLg stop fighting.
Preserving the above-linked wiki for posterity below
Diagnosing "cannot open display" type issues with WSLg
Steve Pronovost edited this page on May 7, 2021 · 3 revisions
On category of issues that we have seen popping up is folks having trouble getting their GUI application to properly connect to WSLg's X server. This page is meant as a quick guide to diagnose this type of connection issue as well as list the currently known problem we're working on fixing.
Verify you are running on Windows build 21364+
From a Windows command prompt, type ver to verify which build you are running.
E:\wsl>ver
Microsoft Windows [Version 10.0.21367.1000]
You must be running on Windows build version 21364+ for WSLg to work. This version of Windows is currently only available through the Windows Insider program. See https://www.microsoft.com/en-us/windowsinsider/ to join the insider program and help us validate pre-released version of Windows.
DISPLAY environment variable
WSLg's X server is running on display 0. The DISPLAY environment variable must have the value :0 for GUI application to connect to the right display. You can verify what the value of your DISPLAY environment variable is per below.
spronovo@OFFICE:~$ echo $DISPLAY
:0
This environment variable is initialize as part of WSL's INIT. If it is unset or has a value other than :0, than you likely have a profile script that is changing it's value that you'll want to hunt down. You can also reset that environment variable like below.
export DISPLAY=:0
X11 display socket
X servers create their socket under /tmp/.X11-Unix. This directory must exist and must be linked to /mnt/wslg/.X11-Unix where WSLg built-in X server create it's socket. You can verify the mapping exist and is the expected link per below.
spronovo@OFFICE:~$ ls -la /tmp/.X11-unix
lrwxrwxrwx 1 spronovo spronovo 19 Apr 21 15:28 /tmp/.X11-unix -> /mnt/wslg/.X11-unix
This link is setup during WSL's INIT. If this directory doesn't exist, something likely caused it be removed in your environment that needs to be tracked down.
You can re-create the link manually to try things out.
sudo rm -r /tmp/.X11-unix
ln -s /mnt/wslg/.X11-unix /tmp/.X11-unix
X11 server running?
If the X server is running, you should see an X0 socket
spronovo@OFFICE:~$ ls /tmp/.X11-unix
X0
If you don't please open an issue and attach /mnt/wslg/weston.log to the bug.
Known issues
You can verify the version of WSLg you are running per below:
spronovo@OFFICE:~$ cat /mnt/wslg/versions.txt
WSLg ( x86_64 ): 1.0.17+3.Branch.master.Sha.a526dfd5ad03d126bb2d8c528f6c3563e86a40da
Mariner: VERSION="1.0.20210224"
FreeRDP: e4a2fc2053bd8c5f99455fcd08ffee7e5591567a
weston: fd961f5cd116c9358d82ce94d139c1578e21bd00
pulseaudio: 2f0f0b8c3872780f15e275fc12899f4564f01bd5
mesa:
Complex monitor arrangement (Fixed in WSLg 1.0.19)
There is a known issue in WSLg 1.0.17 that if you have a combination of vertically and horizontally aligned monitor, Weston may hit an invalid assert and restart. Effectively crashing and restarting the X server on every connection attempt.
You can verify if this is what you are hitting per below
cat /mnt/wslg/weston.log | grep isConnected_V
if you see something like
weston: ../libweston/backend-rdp/rdpdisp.c:481: disp_monitor_validate_and_compute_layout: Assertion `isConnected_V == true' failed.
Then you are hitting this problem. The workaround at the moment is to stack all of your monitor either vertically, or horizontally, but not use a mix of both.
Setting /tmp in /etc/fstab
There is a known issue at the moment (https://github.com/microsoft/wslg/issues/43) where configuring /tmp in /etc/fstab will overwrite the /tmp/.X11-unix link previously described. The workaround at the moment is to either avoid configuring /tmp, or manually recreating the link
ln -s /mnt/wslg/.X11-unix /tmp/.X11-unix
Still having a problem?
Please open an issue and include the following
- Run the following command and provide the output:
spronovo@OFFICE:~$ cat /mnt/wslg/versions.txt
WSLg ( x86_64 ): <current>
Mariner: VERSION="1.0.20210224"
FreeRDP: 5f083fa0b97d433d6204985f6047886e29c1c61e
weston: 16de531f00aa3dfd17e0de74c8f49e9fd7cec617
pulseaudio: 2f0f0b8c3872780f15e275fc12899f4564f01bd5
mesa: 2ad0684038f5732f7e4bd1a391ec9d833685fb48
spronovo@OFFICE:~$ echo $DISPLAY
:0
spronovo@OFFICE:~$ ls -la /tmp/.X11-unix
lrwxrwxrwx 1 root root 19 Apr 21 12:12 /tmp/.X11-unix -> /mnt/wslg/.X11-unix
spronovo@OFFICE:~$ ls -la /tmp/.X11-unix/
total 0
drwxrwxrwx 2 root root 60 Apr 21 12:22 .
drwxrwxrwt 5 root root 220 Apr 21 12:22 ..
srwxrwxrwx 1 spronovo users 0 Apr 21 12:22 X0
- Attach your /mnt/wslg/weston.log file