How to Fix YaST GUI Not Launching over SSH X11 Forwarding

If YaST’s graphical window fails over SSH, first check whether X11 forwarding works at all. From the client computer, connect with ssh -X admin@server, then test another remote graphical program. If that program opens but YaST reports XIO: fatal IO error 11 on a display such as localhost:11.0, SUSE documents a targeted workaround: run the affected YaST command with QT_XCB_GL_INTEGRATION=none in front of it. For example, use QT_XCB_GL_INTEGRATION=none yast2 disk. This workaround applies to a Qt/OpenGL forwarding failure; it will not repair a missing local X server, an unset DISPLAY, blocked server forwarding, or a YaST module that is not installed.

Start with the quickest checks

The graphical YaST interface needs an X display on the client side and a working SSH X11 tunnel. The SSH client sets a forwarded DISPLAY value on the remote host when forwarding is active. A plain SSH login can still work even when graphics are not forwarded, so a successful terminal session alone does not confirm X11.

1. Make sure the client computer has an active X server or X11-compatible display session. On Windows, SUSE documents enabling X11 forwarding in PuTTY under Connection > SSH > X11; a local X server must also be available.
2. Reconnect with forwarding enabled: ssh -X admin@server. Use your actual account and host name.
3. On the remote shell, check echo "$DISPLAY". With a forwarded display, it should normally show a value such as localhost:10.0 or localhost:11.0. A blank value means the session did not establish X11 forwarding.
4. Launch a small X application that is installed on the remote system. If it cannot open on your local desktop, fix forwarding before troubleshooting YaST.

For example, an administrator connecting from a Linux workstation might use ssh -X ops@server.example, then run an available test application. If the application window appears locally, the SSH tunnel and local display are working. If it does not, an error such as “Can't open display” points to the X11 path rather than a YaST-specific graphics workaround.

Apply SUSE’s YaST-specific workaround

SUSE’s SLES 15 SP7 Deployment Guide documents a case where the YaST GUI over SSH with X forwarding fails with XIO: fatal IO error 11 (Resource temporarily unavailable) on localhost:11.0. Its recommended workaround is to disable Qt’s XCB GL integration for that one command. Run the command for the module you need, for example:

QT_XCB_GL_INTEGRATION=none yast2 disk

For the YaST installation interface, the same guide gives this example:

QT_XCB_GL_INTEGRATION=none yast.ssh

Use the command that matches your task; yast2 disk opens the disk module, while yast.ssh is shown for the installation workflow. Prefixing a single command keeps the setting limited to that launch. Do not add it permanently to a global shell profile unless you have a separate reason to change Qt behavior for other programs.

This fix is especially relevant when X11 itself works but YaST exits or prints the specific XIO error. If the same error persists, test a different module and review the client and server forwarding setup. Other graphics failures can have different causes; the SUSE workaround is not a general cure for every Qt, GPU, or display issue.

Check the SSH server when DISPLAY is empty

On the SUSE server, X11 forwarding must be allowed by the SSH daemon configuration. An administrator can inspect /etc/ssh/sshd_config and confirm that the effective configuration includes:

X11Forwarding yes

Server policy can also be supplied through included configuration files or managed centrally, so do not assume that editing one line is sufficient. After an authorized change, validate the configuration and reload the service:

sudo sshd -t
sudo systemctl reload sshd.service

Keep the current SSH session open while checking the configuration, and test a second login before closing it. A syntax check catches malformed configuration, but it does not establish that the policy is correct or that forwarding works from the client. If you do not administer the SSH server, ask its administrator to check the effective policy rather than editing system files yourself.

Reconnect after any server-side change and repeat the DISPLAY and remote-application tests. If the server reports an authorization problem, inspect whether the remote user has a valid X authorization entry with xauth list. Avoid copying authorization cookies by hand or weakening display access controls to make the window open.

Run YaST with administrative privileges without losing the display

YaST changes system settings and usually needs administrative authorization. A common source of confusion is that the unprivileged user can display a test window, but YaST fails after privilege elevation. The elevated process may not retain the forwarded DISPLAY or the X authorization data needed to connect to it.

Use your organization’s approved privilege-elevation method and check what the YaST process receives. Do not enable direct root SSH login just to get a GUI; SUSE’s security guidance recommends logging in as an unprivileged user and using sudo for root commands. If your sudo policy intentionally filters display-related environment variables, ask an administrator to provide a narrowly scoped approved method. Avoid broad environment-preservation rules or commands that expose the local display to every host user.

The relevant diagnostic distinction is simple: if an X application opened as your normal account but YaST fails only when elevated, concentrate on the privilege and authorization handoff. If both fail as the normal account, return to the SSH client, local X server, and server forwarding settings.

Choose the text interface when graphics are unnecessary

X11 forwarding is useful when a particular workflow genuinely requires the graphical interface, but it adds dependencies and can feel slow over a high-latency connection. YaST also provides an ncurses text interface for terminal sessions. SUSE documents forcing it for the disk module with:

yast2 disk --ncurses

This is a practical choice on a headless server, when the client has no X server, or when the graphical session is unstable. You can also run YaST modules from the command line where their supported options allow it. Check the module list with yast -l, and consult that module’s help rather than assuming every graphical module has equivalent command-line operations.

Symptom-to-action guide

Security and version notes

X11 forwarding is more than a visual convenience: remote graphical programs communicate with the client’s display. Use it only with systems you trust. OpenSSH distinguishes untrusted forwarding with -X from trusted forwarding with -Y; trusted forwarding gives remote X clients broader access to the local display. Start with -X. Only consider -Y for a trusted host when a specific application requires it and your security policy allows it.

The YaST error and workaround above are verified in the SUSE Linux Enterprise Server 15 SP7 Deployment Guide. YaST modules, available graphical backends, and startup behavior can differ across SLES, SLED, and openSUSE releases. Check the documentation for the exact product and version installed on the remote host. Reviewed October 6, 2026.

References: SUSE SLES 15 SP7 Deployment Guide: YaST over SSH; SUSE SLES 15 SP7 Security and Hardening Guide: OpenSSH; SUSE SLES 15 SP7 Guide: X Window System and authentication; SUSE SLES 15 SP7 Administration Guide: YaST text mode and command-line options.