I used to run graphical applications such as Chrome from Docker containers on a Linux host by passing DISPLAY and mounting /tmp/.X11-unix. On Ubuntu 22.04, the same approach now fails with "Can't open display," even though DISPLAY has the same value inside and outside the container. I also tried allowing access with xhost and using x11docker's host-display mode, without success. Is direct GUI access from a container to the host's X server still practical, or are Wayland, Xwayland, shared-memory, and GPU changes making it unreliable? I'm using this for browser-based development and need to interact with Playwright-launched browsers during debugging. I'd prefer a direct connection instead of VNC or a browser-based desktop.
3 Answers
Yes, this still works. Mounting the X11 socket and setting DISPLAY are only part of the setup; the X server also needs to trust the container process. A quick test is `xhost +local:` on the host, followed by the usual Docker options: `-e DISPLAY=$DISPLAY -v /tmp/.X11-unix:/tmp/.X11-unix`. For a less broad permission change, use an Xauthority cookie instead of opening the display to every local process. You can export the cookie with `xauth nlist "$DISPLAY"`, merge it into a file accessible in the container, and pass that file as XAUTHORITY. Also make sure the container has an X11 client library and that the socket corresponding to DISPLAY actually exists. `xhost +` is insecure and should only be used briefly for troubleshooting.
On newer Ubuntu installations, the desktop session may be Wayland even though X applications still run through Xwayland. In that case, inspect both DISPLAY and XAUTHORITY, and pass the host’s Xauthority file into the container rather than relying only on the socket mount. A typical setup is to mount `/tmp/.X11-unix`, set `DISPLAY`, set `XAUTHORITY=/tmp/.docker.xauth`, and mount a prepared cookie file at that path. If the application needs GPU acceleration, you may additionally need the appropriate device access and graphics libraries, but GPU support is separate from basic X authentication. For development, this direct setup remains viable; VNC, Kasm, and similar tools are alternatives rather than requirements.
The goal is to run Playwright and its browsers inside the container while still opening an interactive browser window for debugging. A headless browser works, but I need to see and control the window during development.
The important distinction is that mounting `/tmp/.X11-unix` provides transport, not permission. The X server can reject a perfectly reachable socket when the container lacks the correct authentication cookie or is running as a different user. Check the host session type with `echo $XDG_SESSION_TYPE`, verify the socket selected by `$DISPLAY`, and compare the host’s `XAUTHORITY` value. If the session is Wayland, direct access to the Wayland socket is a different configuration; using Xwayland through DISPLAY is usually the simpler route for legacy X applications.
I tried xhost + and confirmed that DISPLAY is identical inside and outside the container, but the client still reports that it cannot open the display.