Cockpit on openSUSE: common problems and their fixes

Login refused

Administrative access asks for the wrong password

Your own password fails at the "Limited access" prompt? openSUSE's default sudo policy asks for the target user's password, which is root's. Type root's password, or switch to the wheel policy so your own password works (needs root):

sudo zypper install sudo-policy-wheel-auth-self
sudo usermod -aG wheel alice               # then log out of Cockpit and back in

More background is in the sudo and SSH guide.

cockpit.socket does not start

systemctl status cockpit.socket
journalctl -u cockpit.socket -b            # the reason is in here

openSUSE's package runs a check before the socket starts, and its messages say what to fix:

• A leftover user or group such as cockpit-wsinstance-socket exists from an older version. Current Cockpit creates these dynamically; remove the old one with the userdel or groupdel command the message names (needs root).
• "/etc/nsswitch.conf is out of date": your file predates the switch to systemd's user database. Compare it with the vendor version and add systemd to the passwd and group lines (needs root): diff /usr/etc/nsswitch.conf /etc/nsswitch.conf.
• You enabled cockpit.service instead of the socket. Disable the service and sudo systemctl enable --now cockpit.socket.

The journalctl command builder helps when the relevant lines drown in the rest of the log.

A real failure on a Tumbleweed laptop. The status says that the check failed:

$ systemctl status cockpit.socket --no-pager | head -8
× cockpit.socket - Cockpit Web Service Socket
     Loaded: loaded (/usr/lib/systemd/system/cockpit.socket; enabled; preset: enabled)
     Active: failed (Result: exit-code) since Fri 2026-09-25 12:52:18 CEST; 2 days ago
 Invocation: 8d74fa1efb254f8885151354c964dfcf
   Triggers: ● cockpit.service
       Docs: man:cockpit-ws(8)
     Listen: [::]:9090 (Stream)
    Process: 1273 ExecStartPre=/usr/libexec/check_cockpit_users (code=exited, status=1/FAILURE)

The check itself can run as a normal user, and it says what to do:

$ /usr/libexec/check_cockpit_users; echo "exit=$?"
user cockpit-wsinstance-socket exists, cockpit will fail to start up if this user exists, please run userdel cockpit-wsinstance-socket to resolve this
group cockpit-wsinstance-socket exists, cockpit will fail to start up if this group exists, please run groupdel cockpit-wsinstance-socket to resolve this
user cockpit-session-socket exists, cockpit will fail to start up if this user exists, please run userdel cockpit-session-socket to resolve this
group cockpit-session-socket exists, cockpit will fail to start up if this group exists, please run groupdel cockpit-session-socket to resolve this
user cockpit-systemd-service exists, cockpit will fail to start up if this group exists, please run userdel cockpit-systemd-service to resolve this
exit=1

Containers or services are missing

• Another user owns them. Cockpit shows root's containers and those of the user you logged in as, nothing else. Log in as the container user. Details are in the podman plugin guide.
• podman.socket is off for that user: the page offers a start button, or run systemctl --user enable --now podman.socket.
• Rootless services vanish after logout: lingering is off. sudo loginctl enable-linger apps.
• A quadlet is not in the service list: the generator rejected the file. Run the dry run from the quadlet basics guide.

The page does not load

1. systemctl is-active cockpit.socket on the server: must say active.
2. curl -k https://localhost:9090/ on the server: returns HTML if Cockpit works.
3. sudo firewall-cmd --get-active-zones: which zone is your client's traffic in, and does that zone list cockpit?
4. If you bound the socket to a tunnel address, you can only reach it through the tunnel.

Step 3 is the culprit nine times out of ten. The WireGuard guide shows a zone setup that works.

Updates from Cockpit

The Software updates page (package cockpit-packagekit) is convenient on Leap for patches. On Tumbleweed, run sudo zypper dup in the Terminal page instead: you see exactly what the solver proposes, including removals, and can say no. The reasons are in the zypper updates guide.

Frequently asked questions