I have a headless machine that I use as a server with (almost) nothing but ssh ports open (and password-less login configured).
I can connect from most machines on my LAN using ssh -X server.lan following which I can use e.g. Dolphin to manage files. But my laptop with Leap 16 connects without reporting any error, then rejects attempts to run windowed applications e.g.
me@laptop:~> ssh -X server.lan
Last login: Wed Dec 17 19:47:14 2025 from xxx.xxx.xxx.xxx
Have a lot of fun...
me@server:~> dolphin &
[1] 4096
connect /tmp/.X11-unix/X1: Permission denied
connect /tmp/.X11-unix/X1: Permission denied
connect /tmp/.X11-unix/X1: Permission denied
connect /tmp/.X11-unix/X1: Permission denied
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.
Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, wayland-egl, wayland, wayland-xcomposite-egl, wayland-xcomposite-glx, xcb.
Different search terms confirm knurpht’s statement, and I see suggestions such as
waypipe or xwayland. I’ll take a look at these and report back to this thread in case others have the same issue.
@Richard_MQ look at installing the flatpak Cockpit client (org.cockpit_project.CockpitClient) on your Leap 16.0 system (As Your User!), then should be able to connect to the remote as it uses ssh (no Cockpit packages are needed on the remote). Cockpit has a file browser, terminal app and more…
This isn’t a Wayland limitation. ssh -X is working, but Xwayland is denying access to the forwarded display (/tmp/.X11-unix/X1). This is usually caused by a local user mismatch (or untrusted X11 forwarding). Try ssh -Y, make sure you’re logged into the Wayland session as the same local user, and verify xauth is installed on the server. The Qt “xcb plugin” error is just a symptom of the X connection being refused.
As Malcolm mentioned though, Cockpit is likely the better the way to go for your use case?
I installed cockpit client on the laptop, and the full cockpit app on the server (both via flatpak). This seems like a really good maintenance tool - I’ll give it a proper spin in the coming months.
For the record, I had the same problem with the cockpit server failing to start as others have reported:
Dec 22 15:28:59 server systemd[1]: Starting Cockpit Web Service...
Dec 22 15:28:59 server (e-ensure)[5075]: cockpit.service: Failed to determine group credentials: No such process
Dec 22 15:28:59 server (e-ensure)[5075]: cockpit.service: Failed at step GROUP spawning /usr/lib/cockpit-certificate-ensure: No such process
Dec 22 15:28:59 server systemd[1]: cockpit.service: Control process exited, code=exited, status=216/GROUP
Dec 22 15:28:59 server systemd[1]: cockpit.service: Failed with result 'exit-code'.
Dec 22 15:28:59 server systemd[1]: Failed to start Cockpit Web Service.