The "Failed to connect to the bus, Missing X server or DISPLAY" error occurs because WSL2 lacks a graphical interface by default. To resolve this, you must install and configure an X server on Windows, set the
DISPLAY environment variable in your Linux session, and ensure Chrome can access it via proper permissions.
Understanding the Root Cause
WSL2 (Windows Subsystem for Linux 2) is designed primarily as a command-line environment. It does not include a built-in X Window System server, which is required to render graphical user interfaces like Google Chrome. When you attempt to launch a GUI application, the Linux process looks for a display server defined by the
DISPLAY environment variable. If this variable is unset or points to a non-existent server, the application fails with the specific error messages regarding the bus connection and missing display.
Additionally, even if the
DISPLAY variable is set, the security protocols of the X11 protocol may block the connection. By default, X11 servers on Windows often restrict incoming connections from remote clients unless explicitly allowed. This results in a failure to connect to the message bus, preventing the browser from initializing its graphics context. Solving this requires bridging the Windows host's graphical capabilities with the Linux guest's request for a display surface.
Installing an X Server on Windows
Before configuring WSL, you need a robust X server running on your Windows host. While older solutions suggested Xming, modern alternatives offer better performance and compatibility with WSL2's networking stack.
Error launching Chrome on WSL Ubuntu discusses similar graphical hurdles, but the foundation remains the same: you need a listening service on port 6000.
Popular choices include VcXsrv, MobaXterm, or Microsoft's own official X server integration in newer builds. For most users, installing VcXsrv is the most straightforward path. Download the installer from the official source and run it. During installation, you do not need to change default settings unless you have specific network requirements. Once installed, you should launch the XLaunch utility. Configure it to start without access control if you are testing locally, or enable "No Access Control" to allow connections from localhost. Ensure the display number is set to 0, which corresponds to the standard
:0 address used by most applications.
If you prefer an all-in-one solution, MobaXterm includes a built-in X server that activates automatically when you open an SSH session. This eliminates the need for separate configuration steps for the X server itself, though you still need to point WSL to the correct IP address.
Configuring the DISPLAY Variable in WSL
With the X server running on Windows, you must tell your Ubuntu instance where to send its graphical output. The challenge in WSL2 is that the virtual machine receives a dynamic IP address each time it restarts. Hardcoding an IP address in your
.bashrc file will likely break after a reboot or network reset.
To handle this dynamically, add the following lines to your
~/.bashrc or
~/.profile file. This script detects whether you are running inside WSL and queries the Windows host's IP address automatically.
# Set DISPLAY for WSL2
if [ -n "$WSL_INTEROP" ]; then
# Get the IP address of the Windows host
export DISPLAY=$(grep nameserver /etc/resolv.conf | head -n 1 | awk '{print $2}'):0
else
# Fallback for WSL1 or other environments
export DISPLAY=:0
fi
# Ensure the X server allows connections
export LIBGL_ALWAYS_INDIRECT=1
After adding these lines, save the file and reload your shell configuration by running
source ~/.bashrc. You can verify that the variable is set correctly by echoing it:
echo $DISPLAY. It should return something like
172.x.x.x:0, where
x.x.x.x is the IP address of your Windows machine.
Allowing Connections and Launching Chrome
Even with the correct IP, the X server might reject the connection due to X11 security extensions. To fix this, you need to modify the access control list on the Windows side. If you are using VcXsrv, right-click the icon in the system tray, go to Properties, and ensure that "Disable access control" is checked. This allows any local client to connect without authentication, which is safe for development environments on personal machines.
For users employing MobaXterm, the X server usually handles permissions automatically, but you may need to ensure the "Local X server" checkbox is enabled in the settings.
Once the server is configured and the
DISPLAY variable is active, you can attempt to launch Chrome. Run the command
google-chrome or
google-chrome-stable in your terminal. If successful, the browser window will appear on your Windows desktop. Note that the first launch might be slow as Chrome initializes its sandbox and graphics drivers within the WSL context.
If you encounter permission denied errors, you may need to run
xhost +local: on the Windows side before launching Chrome. This command grants local users permission to connect to the X server. However, relying on
xhost is less secure than disabling access control in the X server settings permanently for local use.
Troubleshooting Common Issues
Sometimes Chrome fails to launch despite correct configuration. One common issue is related to hardware acceleration. WSL2 does not support direct GPU acceleration for X11 apps in the same way native Windows does. If Chrome crashes immediately upon opening, try launching it with hardware acceleration disabled by running
google-chrome --disable-gpu.
Another potential problem arises if you are using a firewall that blocks inbound connections on port 6000. Although the connection is technically local, some strict firewall configurations may interfere. Ensure that your antivirus or Windows Defender Firewall allows the X server executable to communicate on private networks.
Finally, remember that WSL2 shares the same network namespace as the Windows host for many operations, but the IP addressing scheme is distinct. If
grep nameserver /etc/resolv.conf returns an IPv6 address or a loopback address, your configuration might be outdated. In such cases, restarting the WSL instance with
wsl --shutdown followed by a fresh launch often resolves stale network states.
Frequently Asked Questions
Why does my DISPLAY IP change every time I restart WSL?
WSL2 runs as a lightweight utility VM, and its network interface is assigned a dynamic IP address via DHCP. Unlike physical machines or containers with static IPs, WSL2 regenerates its network stack frequently. Using the
resolv.conf method ensures your script always fetches the current active IP of the Windows host, preventing broken links after reboots.
Can I use Wayland instead of X11 for better performance?
Currently, most GUI applications in WSL2 rely on X11 forwarding because Wayland support in WSL is still experimental and limited. While projects like WSLg provide native Wayland integration in Windows 11, third-party X servers remain the standard for custom setups. Switching to Wayland requires deep changes to both the Windows host and the Linux kernel, making X11 the practical choice for now.
Is it safe to disable access control in VcXsrv?
Disabling access control allows any application on your local machine to draw windows on your screen. For a personal development machine, this risk is minimal. However, if you share your computer or work in a public environment, consider keeping access control enabled and manually granting permissions using
xhost + only when needed.
What if Chrome opens but shows a blank white screen?
A blank screen usually indicates that Chrome started but failed to initialize its graphics pipeline. This is often caused by conflicts between Chrome's hardware acceleration and the emulated graphics environment. Adding the
--disable-gpu flag forces Chrome to use software rendering, which bypasses the problematic hardware abstraction layer and typically restores functionality.
Does this solution work for other GUI apps like VS Code?
Yes, the same principles apply to any X11-based application. You can launch Visual Studio Code for Linux by setting the
DISPLAY variable and running
code .. The key requirement is that the application must be compiled for Linux and capable of connecting to an external X server. Not all GUI apps behave identically, so testing with simple tools like
xclock is recommended before tackling complex editors.