First connection fails, second succeeds

This is normal behavior with self-signed TLS certificates. On the first connection, the RDP client encounters an untrusted certificate and may fail or prompt the user to accept it. The second connection succeeds because the client has cached the certificate.

Fix: Accept the certificate warning on your RDP client, or deploy a trusted TLS certificate. See the Security page for custom certificate configuration.

Clipboard: Linux to Windows not working (Flatpak/Snap)

In Flatpak and Snap installations, clipboard transfer from Linux to Windows is not supported. This is a limitation of the XDG Desktop Portal API, which only provides clipboard access in the Windows-to-Linux direction.

Workaround: Use a native installation (.deb, .rpm, AUR, or from source) for full bidirectional clipboard support.

Clipboard not working at all (Flatpak)

Flatpak clipboard support requires the RemoteDesktop portal v2, which is only available on:

GNOME 45 or later
KDE Plasma 6.3 or later

Fix: Update your desktop environment to a version that supports RemoteDesktop v2, or switch to a native installation.

Permission dialog on every start (GNOME)

GNOME does not persist RemoteDesktop portal sessions by design. Each time the server starts, GNOME will prompt the user to authorize screen sharing again.

Note: This is a GNOME design decision and cannot be changed by lamco-rdp-server. KDE Plasma and other compositors may persist the authorization.

"Unknown (not in Wayland session?)" message

This message is cosmetic and appears in Flatpak sandboxes where certain Wayland environment variables are not exposed. It does not affect functionality.

Action: This can be safely ignored. The server operates correctly through XDG Desktop Portals regardless of this message.

No video / black screen

A black screen usually indicates that PipeWire is not running or xdg-desktop-portal is not responding. The server captures video through PipeWire via the ScreenCast portal.

# Check PipeWire status
systemctl --user status pipewire

# Check xdg-desktop-portal status
systemctl --user status xdg-desktop-portal

Fix: Ensure both PipeWire and xdg-desktop-portal are running. Restart them if needed:

systemctl --user restart pipewire xdg-desktop-portal

High CPU usage

Software video encoding can consume significant CPU resources, especially at high resolutions and frame rates.

Fix: Enable hardware encoding to offload video compression to the GPU:

[video]
encoder = "vaapi" # or "nvenc" for NVIDIA GPUs

Check available hardware encoders with: vainfo (VA-API) or nvidia-smi (NVENC).

Troubleshooting