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

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.
On Linux, Veyon was configured to run as root. On Windows it works with “All” users.
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

Tried changing key file owners (ученик11, root), no effect.
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

timoteomeireles

Okay, I have a mixed network with Windows and Linux, and the master is Windows. In order for the Linux computers to be visible on the master, there are some steps to follow during installation. Before installing Veyon and configuring the keys, you need to add the user who is logged into Linux within Sudoers so that the keys have root access permission. That's how I solved it here;

Ivadus

I completely deleted Veyon from the client PC, added the user to sudoers, reinstalled Veyon and imported the keys. It still says on the master PC that "The Veyon service is not running or is not available." Moreover, a notification successfully appears on the client PC that the Master PC is connected to it.

Here are the logs:

veyon-service[1715]: 2025-09-19T10:40:39.596: [INFO] LinuxServiceCore::startServer(): Starting server for new session "/org/freedesktop/login1/session/_32" with ID 0 at seat "/org/freedesktop/login1/seat/seat0"

2025-09-19T10:40:40.390: [INFO] ComputerControlServer::showAccessControlMessage(): Access control successful for "::ffff:192.168.1.***" "Школа22"

Ivadus

I connected to the client PC this morning. But there is nothing unusual or eye-catching in statusctl, journalctl, or the logs.

Besides, when I turned on the "Lock" function on it via the master PC, the client PC went into sleep mode, turned off the Veyon service, and the problem returned. I haven't changed any settings. How do I understand what is preventing the Master PC from connecting to the client PC?

UPD: Now he's connected himself again. I didn't change the settings, I didn't touch anything. How do I figure out what's preventing me from connecting and what's not? What kind of magical silent machine decides whether I succeed or not?

timoteomeireles

It really is a mystery, here with me it only works if I follow a script from the installation of Linux to the installation of Veyon, if I change the order of things it no longer works. I am currently using Ubuntu Focal, which is what has adapted best to my network structure.

Ivadus

@timoteomeireles
Tell me, please, which installation script are you talking about?

I can't use Ubuntu Focal, my school has OC regulations. This is Windows and the Linux distribution that I wrote about above.

timoteomeireles

Install Ubuntu 20.04.1

Name: "student" "01"-pc
Password: 789qwe@

Update and Upgrade

SSH
sudo apt install openssh-server
sudo service ssh status
sudo ufw allow ssh
sudo service ssh restart

Enter the user as sudoers - /etc/sudoers
Open the terminal
Use the sudo nano command
Modify the file using nano, on the last line add
"student01-pc ALL=(ALL) NOPASSWD: ALL
Save the nano with CTRL+O

Veyon
Download from GitHub
https: //github. com /veyon/ veyon/ releases/ tag/v4.8.0 (It is recognized as a link. Please join the parts, otherwise it won't let me post.)
(I use this version; it always works for me)
I always install it using the Ubuntu program installer. Configure and Test the keys

Extension
Install gnome-shell-extension-prefs
Disable desktop icons
Disable unused software

Install the package

sudo apt-get install gnome-tweaks

Open "Settings"
-- First tab "General"
--- Turn off "Animations"

It works like this here: if I don't follow this order, I can't get Veyon to work. It doesn't allow access to the keychain, which is basically what it needs to locate the machine.

In case of problems, I use ssh to stop the service with
sudo systemctl stop Veyon
and start it again with
sudo systemctl start Veyon

Veyon Community Forum

Windows Master connects to Windows clients, but Linux client fails