Windows Master connects to Windows clients, but Linux client fails

[Ivadus]

I am deploying Veyon in a school network: the Master PC is running Windows, and we have both Windows and Linux client PCs.

Problem:

• The Windows Master connects fine to Windows clients.
• Linux clients in the same subnet, with the same configuration and the same keys, do not connect.
• Initially, Linux clients were visible in Veyon before login (at the greeter screen), but failed after login with an authentication error.
• Now they don’t connect at all — not even before login.

Meanwhile, Windows clients in the same network with the same exported keys connect without issues.

Environment

• Master: Windows (version: ___), Veyon Master/Configurator: ___
• Client (problematic): Linux (distro/version: ___), Veyon: ___
• School has a server, but I haven’t configured it for Veyon/LDAP.
• Firewalls disabled everywhere, all machines are in the same subnet.

What works

Windows Master → Windows Clients = works.

What doesn’t work

Windows Master → Linux Clients = fails (used to partially work before login, now fails always).

Observations & what I tried

1. Keys exported from Master and imported into Linux. On Windows clients the key pair ID matches (27f86847c5b50478).
   On Linux, the key pair ID is different (starts with ca...). On Linux I don’t see the same key pair folder — only veyon/keys/public/305 etc.
2. On Linux, Veyon was configured to run as root. On Windows it works with “All” users.
3. Managing the service with systemctl shows errors:

QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
Failed to enable unit: Unit file Veyon-service does not exist
Failed to enable unit: Unit file veyon.service does not exist

4. Tried changing key file owners (ученик11, root), no effect.
5. On Windows everything works out-of-the-box via Veyon Configurator. On Linux it seems broken once user sessions / environment variables come into play.

Key errors in logs
The following lines appear repeatedly and seem most relevant to the failure:

QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'

→ Missing environment variable, likely breaking socket/auth handling after login.

Failed to enable unit: Unit file veyon.service does not exist
Failed to enable unit: Unit file Veyon-service does not exist

Key mismatch:

• Windows Master and Windows Clients: key pair ID = 27f86847c5b50478
• Linux Client: different key pair ID (starts with ca...)
  → Strong indication Linux is using the wrong or invalid key pair.

Suspicions

• Not a network/firewall problem (Windows clients connect fine).
• Most likely Linux-specific issue: service ownership, missing environment vars (XDG_RUNTIME_DIR, XAUTHORITY, DISPLAY), or wrong key pair.
• Systemd unit not properly installed/enabled.

Questions

• What are the correct file ownership and permissions for /etc/veyon/keys/* on Linux?
• Should the Veyon service run as root or under another account (equivalent to Windows “All”)?
• Could the missing XDG_RUNTIME_DIR explain why Veyon fails to connect? How to fix it?
• How can I force the Linux client to use the same imported key pair as the Windows clients (so IDs match)?
• What is the correct systemd unit for Veyon, and how should it be enabled?
• Which logs are most useful for debugging authentication errors?

TL;DR

• Windows Master → Windows Clients: works.
• Windows Master → Linux Clients: fails (used to work before login, now fails always).
• Logs point to: missing environment vars, wrong key pair, broken/missing systemd unit, and permission issues.
• Looking for guidance on proper Linux client setup (service, keys, permissions).

[Ivadus]

Forgot to mention the exact environment in my first post:

• Master PC: Windows 10, running Veyon Master/Configurator 4.9.x
• Linux Client PCs: ALT Linux–based school distribution (MOS/ROSA, used in Russian schools), also running Veyon 4.9.x
• User accounts on Linux: user (regular), also system accounts like mos-admin, mos-teacher, mos-student
• Service manager: systemd
• Network: same subnet for all PCs, firewalls disabled