Where Are the Wayland and X11 Sockets on Linux?
Wayland sockets live in XDG_RUNTIME_DIR under WAYLAND_DISPLAY; X11 sockets live in /tmp/.X11-unix.
Last updated
Linux clients find their display server through sockets. Wayland uses $XDG_RUNTIME_DIR/$WAYLAND_DISPLAY, typically /run/user/1000/wayland-0. X11 uses /tmp/.X11-unix/Xn for display :n, with ~/.Xauthority gating access. XWayland bridges the two, appearing as both at once.
The split explains half of all cannot-open-display tickets. Wayland clients with no fallback fail silently when WAYLAND_DISPLAY is unset; X clients fail when DISPLAY points at a missing socket. Listing the runtime dir and the X11-unix folder shows what actually exists before blaming the app.
Where Linux stores this, by platform
$XDG_RUNTIME_DIR/$WAYLAND_DISPLAY
Per-user runtime dir, usually /run/user/<uid>. wayland-0 default; ls wayland-* shows live displays. XWayland sockets for X apps appear in /tmp/.X11-unix instead.
/tmp/.X11-unix
Xn socket per display number, world-writable sticky dir. Pair with DISPLAY=:n and ~/.Xauthority. Container guides bind-mount this whole folder.
Frequently asked questions
GUI apps suddenly cannot open. Are the sockets the problem?
Check WAYLAND_DISPLAY and XDG_RUNTIME_DIR first. A missing or stale socket means the compositor is gone or the variables point elsewhere, which breaks every client at once rather than one app.
How do I give a container access to my display?
Bind-mount the socket into the container and export the matching variables. Wayland needs the $XDG_RUNTIME_DIR/$WAYLAND_DISPLAY socket; X11 needs /tmp/.X11-unix plus DISPLAY and Xauthority. ArchWiki documents both recipes.
Notice an outdated path? Let us know.