# Running Google Chrome GUI in WSL

By Corey J. Gallon · 2024-08-25 · https://gallon.me/running-google-chrome-gui-in-wsl.html

---

This was working for me a while ago but today, when I tried, it was not. 

```bash
❯ 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](https://github.com/microsoft/wslg/wiki/Diagnosing-%22cannot-open-display%22-type-issues-with-WSLg).

The solution was simple and immediate:

```bash
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.

```python
%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](https://github.com/microsoft/wslg/wiki/Diagnosing-%22cannot-open-display%22-type-issues-with-WSLg/_history)

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