Get YaST’s X11 Forwarding Working Over SSH

If YaST exits with XIO: fatal IO error 11 (Resource temporarily unavailable) over SSH, first try the SUSE-documented Qt workaround: QT_XCB_GL_INTEGRATION=none yast.ssh. For an installed SLES system and a specific YaST module, use the same variable before that module, such as QT_XCB_GL_INTEGRATION=none yast2 disk. If no graphical application can open, repair X11 forwarding first: connect with ssh -X, check that the remote shell has a DISPLAY value, and verify the server has X11 forwarding enabled.

SUSE's SLES 15 SP7 Deployment Guide documents this exact XIO failure and both the Qt workaround and ncurses alternative. The passage appears in the remote installation context, so use it as a targeted fix for the matching YaST-over-SSH behavior; it does not establish that every YaST launch failure has the same cause. The checks below separate that case from a missing local X server, disabled SSH forwarding, or an X authentication problem.

1. Confirm X11 forwarding works before troubleshooting YaST

X11 forwarding sends a remote application's window traffic through SSH to an X server on your local computer. Your local machine therefore needs a running X server, and the SSH client must request forwarding. On an X11 desktop, open a fresh terminal and connect like this:

ssh -X admin@server.example.com

Replace the account and host with your own. After login, run:

echo "$DISPLAY"

A value such as localhost:10.0 indicates that SSH set up a forwarded display. It is an example, not a fixed value: the display number may differ. If the output is blank, log out and reconnect with -X. If it remains blank, inspect the client-side SSH settings and the server configuration in the next section. Do not manually set DISPLAY to a guessed value; SSH creates a proxy display for the session.

If you use PuTTY on Windows, enable X11 forwarding in the session's Connection > SSH > X11 settings and make sure a local X server is running. SUSE's deployment guide calls out this requirement. A remote host cannot display a window if the local machine has no X server, even when SSH login succeeds.

2. Check the SLES SSH server and X authentication

On the SLES host, an administrator can inspect the SSH daemon configuration:

sudo grep -i '^X11Forwarding' /etc/ssh/sshd_config
command -v xauth

The effective server policy must permit X11 forwarding, and xauth must be available for the authentication handoff. SUSE documents X11Forwarding Yes as the server-side setting and notes that SSH sets the remote DISPLAY when a client connects with -X. A simple grep can miss settings in included configuration files or conditional Match blocks; if the output seems to conflict with behavior, have the SSH administrator inspect the effective configuration rather than adding duplicate lines.

If you change sshd_config, validate the file before reloading the daemon:

sudo sshd -t
sudo systemctl reload sshd

Run these only with administrator authorization. Keep your existing SSH session open while testing a new one, so a configuration mistake does not lock you out. Then disconnect and reconnect; forwarding settings are negotiated when the SSH session starts. Avoid opening TCP port 6000 on the server or using xhost + as a shortcut. SSH forwarding is designed to tunnel X traffic and manage its authentication; direct X access can expose the display to other machines.

3. Apply the YaST-specific Qt workaround

If DISPLAY is set and another forwarded X application opens, but YaST fails with the XIO error above, try the documented environment override for that one launch:

QT_XCB_GL_INTEGRATION=none yast.ssh

For a regular installed system, launch the required module rather than assuming the installation helper is present. For example, SUSE documents this module form:

QT_XCB_GL_INTEGRATION=none yast2 disk

The variable applies only to the command that follows it; it does not permanently change Qt settings or SSH policy. The exact yast.ssh command is used by SUSE for its installation system, while an installed SLES host commonly starts YaST modules with yast2. If a different module is failing, substitute its documented module name for disk. Do not treat this environment setting as a fix for a blank DISPLAY or for a client without an X server.

4. Use YaST's text interface when a window is not needed

If you only need to complete administration and do not need a graphical window, use YaST's ncurses interface in the SSH terminal. For the disk module, SUSE documents:

yast2 disk --ncurses

You can also explicitly request the ncurses backend for the module:

YUI_PREFERRED_BACKEND=ncurses yast2 disk

The text interface avoids X11 forwarding entirely and is often the simplest choice for a remote server. It is still YaST and still changes system configuration; review disk, partition, firewall, and network changes carefully before confirming them. For the SLES installation system, SUSE says YaST provides an ncurses interface when a local X server is unavailable.

Verify the fix

Open a new SSH session with ssh -X, confirm echo "$DISPLAY" is nonempty, then launch YaST using the appropriate command. Success means the YaST window appears on the local desktop, or the ncurses module opens in the terminal if you chose that backend. If forwarding is healthy but the exact XIO error remains after the Qt override, capture the complete terminal error and check the SLES release notes or SUSE Support Knowledgebase for a release-specific issue; this procedure cannot identify an unrelated Qt or YaST defect from the error fragment alone.

Official references

• SUSE Linux Enterprise Server 15 SP7 Deployment Guide — remote installation by SSH, X forwarding requirements, the documented YaST XIO workaround, and ncurses commands.
• SUSE SLES 15 SP7 Security and Hardening Guide: OpenSSH — server-side X11 forwarding and remote graphical applications.
• OpenBSD OpenSSH ssh(1) manual — client options for X11 forwarding, including the distinction between untrusted -X and trusted -Y.