I'm running RHEL 10.2 with GNOME 49 and trying to display an X11 application from inside a Podman container. The container uses a custom internal network created with `podman network create --internal pod_dev`, so it needs to retain its own network identity and IP address. I pass the expected DISPLAY, XAUTHORITY, X11 socket, and related environment variables and mounts into the container, but the application still cannot connect to the display. The same setup works on Fedora 44 and Ubuntu. Using host networking (`--network=host`) makes the X application work, but that is not an option because the container must have its own IP. What should I check or configure on RHEL to make X11 forwarding work with an isolated Podman network?
3 Answers
The first thing I'd verify is the Xauthority cookie. With a custom Podman network, the container usually has a different hostname, and the cookie may have been created for the host's hostname instead. Compare `xauth list` inside the container with the container's `hostname`. As a quick test, run the container with `--hostname $(hostname)`. If that works, create a cookie that is not tied to one specific hostname, mount it into the container, and set `XAUTHORITY` to that mounted path. For example: `xauth nlist $DISPLAY | sed -e 's/^.... /ffff/' | xauth -f /tmp/.podman.xauth nmerge -`. Then bind-mount `/tmp/.podman.xauth` into the container.
It may help to isolate whether this is an X11 authentication problem or a networking problem. First test X forwarding to a normal host or loopback target without involving the container. Once that works, test the container address separately. SSH X forwarding can be useful for troubleshooting, although an internal network may prevent you from connecting directly to the container unless an SSH service or another reachable entry point is configured. On RHEL, also check SELinux denials and firewall rules, since both can interfere with access to the X socket or related connections.
The part I'm unclear about is how SSH would reach a container on an internal custom network when there isn't an SSH service exposed. I'll separate the host X-forwarding test from the container test and also check SELinux and firewall logs.
At minimum, the container needs access to the X11 Unix socket, usually by mounting `/tmp/.X11-unix`, along with a valid Xauthority file and the correct `DISPLAY` value. Since host networking works, the socket and basic environment are probably close to correct; the hostname-specific Xauthority entry is a particularly likely difference when switching to a custom network. If the socket is mounted but access is still denied, inspect the container's SELinux context and audit logs rather than repeatedly adding environment variables.
I tried a different Xauthority approach before and it didn't work, but I'll test this exact method. Thanks for taking the time to help.