Session Persistence & Unattended Access
Enable zero-dialog unattended operation through intelligent runtime strategy selection
The Challenge
Wayland's Permission Dialog Problem
Wayland's security model requires explicit user permission for screen capture and input injection. By default, a permission dialog appears every time the server restarts -- unacceptable for production servers, VMs, or headless deployments.
Permission dialog reappears. Manual click required via monitor/KVM.
Updates or configuration changes trigger new permission prompts.
Dropped connections require re-authorization upon reconnecting.
The Solution
Lamco RDP Server implements a multi-strategy architecture that automatically selects the optimal session persistence approach for your specific compositor, deployment method, and portal capabilities. The result: zero-dialog unattended operation on supported configurations, with graceful fallback for all others.
Multi-Strategy Architecture
Five distinct session persistence strategies cover every major Wayland compositor and deployment method. The server automatically selects the best available strategy for your environment.
| Strategy | Compositors | Deployment | Dialogs | Status |
|---|---|---|---|---|
| Mutter Direct API | GNOME 42+ | Native | Zero dialogs | Per-connection (1.4.4) |
| wlr-direct protocols | Sway, Hyprland, River | Native | Zero dialogs | Production tested (Hyprland via AUR) |
| Portal + Session Tokens | KDE Plasma 6+, Non-GNOME | Any | One first time, then zero | Expected to work |
| Portal + libei/EIS | wlroots (in Flatpak) | Flatpak | One first time, then zero | Implementation complete (480 lines) |
| Portal-Generic | Compositors without a native portal backend | Any | Varies | Production (ScreenCast v6 capture) |
| ScreenCast-only (View-only) | All compositors | Any | Minimal | Production (--view-only) |
| Basic Portal (fallback) | All compositors | Any | Every restart | Fallback strategy |
How it works: At startup, Lamco RDP Server probes your system to determine the compositor type, deployment method (Flatpak vs native), and portal capabilities. It then selects the highest-tier strategy available, falling back through the list until it finds a compatible approach. No user configuration required.
1.4.4: Mutter Direct is now per-connection. On GNOME/Mutter the server creates a fresh, dialog-free RemoteDesktop/ScreenCast session on each connect and releases it on disconnect, so it serves many sequential RDP sessions without a restart. Previously the server kept one long-lived session that Mutter's idle timeout reaped about eight seconds after a client left, with no rebuild path, which looked like "it only works once." That limitation is closed.
Session Health Monitoring
1.4.4 monitors every subsystem in an active session through a dedicated sensor framework
Sensor Framework
A HealthSensor trait with concrete sensors per subsystem,
a per-session SensorRegistry, and a snapshot collector:
- ✓ PipeWire: stream state, pauses, errors, recovery
- ✓ Portal: session validity
- ✓ Mutter: compositor presence and crash detection
- ✓ EGFX: graphics channel health
- ✓ Encoder backend: active hardware/software encoder state
Closed-Loop Signaling and GUI Output
Damage detection feeds encoding decisions, and compositor-crash detection cascades through the session lifecycle. The GUI Status and Performance tabs surface health output alongside live damage-source, FPS, and activity telemetry.
- • External monitoring tools
- • System tray indicators
- • Automated recovery workflows
Strategy Selection is Automatic
You don't configure anything. At startup, Lamco RDP Server performs the following detection sequence:
Identify GNOME, KDE, Sway, Hyprland, River, or other via environment variables and D-Bus introspection.
Determine if running inside Flatpak sandbox or as a native system package.
Check XDG Portal version, RemoteDesktop interface version, and session restore support.
Choose the highest-tier strategy that achieves zero or minimal dialogs.
If no advanced strategy is available, use Basic Portal with per-restart dialog.
Zero Configuration Required
The entire detection and selection process happens automatically at startup. You install Lamco RDP Server, start it, and it figures out the best session persistence approach for your system. The selected strategy is logged at startup so you can verify what was chosen.
lamco-rdp-server --show-capabilities | grep -i session
Deployment Impact on Session Persistence
Your installation method directly affects which session persistence strategies are available.
Flatpak Deployment
- + Works on ALL distributions
- + Sandboxed security model
- + Flatpak bundle (GitHub release) or Snap Store, Community Edition
- ! GNOME: Portal strategy only (dialog every restart)
- + wlroots: libei/EIS strategy (one dialog, then zero)
- + KDE: Session tokens (one dialog, then zero)
Best for: Desktop testing, evaluation, user workstations
Native Package
- + Full system integration
- + Hardware encoding (VA-API, NVENC)
- + GNOME: Mutter Direct API (zero dialogs)
- + wlroots: Direct protocols (zero dialogs)
- + KDE: Session tokens (one dialog, then zero)
- ! Distribution-specific (not universal)
Best for: Production servers, VMs, unattended operation
GNOME Session Persistence
Important Note
GNOME's Portal backend deliberately rejects session persistence for RemoteDesktop sessions. This is a security policy decision by the GNOME project, not a missing feature. The Portal returns the error:
This means on GNOME with Flatpak deployment, a permission dialog will appear every time the server restarts. For production GNOME servers requiring unattended access, native package deployment is strongly recommended.
Workaround for GNOME servers:
Use native package deployment with the Mutter Direct API strategy. This bypasses the Portal entirely and achieves zero-dialog operation through GNOME Mutter's D-Bus APIs. The Mutter Direct strategy communicates directly with the compositor, avoiding the Portal's session persistence restriction.
Status: Mutter Direct strategy is fully implemented and ready for testing.
GNOME Session Persistence Summary
Flatpak on GNOME
Basic Portal only. Permission dialog on every restart. Acceptable for personal use, not for unattended servers.
Native Package on GNOME
Mutter Direct API. Zero dialogs. Recommended for production servers, VMs, and unattended deployments.
Use Case: Unattended Server
Scenario: Remote server running Ubuntu 24.04 with GNOME, accessed via RDP for administration
Without Session Persistence
- 1. Server reboots → Click "Allow" dialog via monitor/KVM
- 2. Service restarts for updates → Click "Allow" dialog
- 3. Network reconnection → Click "Allow" dialog
Result: Manual intervention required constantly
With Mutter Direct (Native Package)
- 1. Server reboots → Automatic session restoration
- 2. Service restarts → Automatic session restoration
- 3. Network reconnection → Automatic session restoration
Result: Zero manual intervention
Recommendation: For production servers requiring unattended access, always use native package deployment. This enables the highest-tier session persistence strategies (Mutter Direct for GNOME, wlr-direct for Sway/Hyprland/River) that achieve true zero-dialog operation. Community Edition (Flatpak/Snap) — free for all use including commercial.
Encrypted Credential Storage
Session tokens and credentials are encrypted using environment-adaptive storage that selects the most secure available backend for your system.
Secret Portal → Host keyring
Sandboxed access via portal API
GNOME Keyring (Secret Service API)
Direct D-Bus integration
KWallet (Secret Service API)
Direct D-Bus integration
TPM 2.0 hardware binding
Hardware-backed key storage
AES-256-GCM encrypted file
File-based with derived keys
Security guarantee: All methods use AES-256-GCM authenticated encryption. Master keys are never stored in plaintext. The storage backend is selected automatically based on the available system services.
Desktop Sharing vs Headless VDI
Lamco RDP Server is designed for desktop sharing -- remotely accessing an existing Linux desktop session. For enterprise multi-user VDI deployments, we're developing lamco-VDI, a separate product built on the same RDP core.
Lamco RDP Server
Desktop Sharing
What It Does
Remote access to your existing Linux desktop session. GNOME, KDE, or wlroots must be running.
Perfect For
- + Remote access to personal workstation
- + Work from home (access office desktop)
- + System administration with DE
- + Screen sharing / tech support
Architecture
- Single user per machine
- Requires desktop environment
- ~800MB+ resource usage
lamco-VDI
Headless Multi-User VDI
What It Does
Enterprise VDI with no desktop environment required. Isolated sessions for multiple concurrent users.
Perfect For
- + Enterprise VDI (100+ employees)
- + Cloud workspaces (AWS/Azure/GCP)
- + Thin client infrastructure
- + Kubernetes/Docker deployment
Architecture
- Multi-user (10-50+ per server)
- Embedded Smithay compositor
- ~256MB per user session
lamco-VDI: Headless virtual desktop mode. Development timeline to be announced.
Which Product Do You Need?
| Your Requirement | Recommended Product |
|---|---|
| Access my personal Linux workstation remotely | Lamco RDP Server |
| Remote server with GNOME/KDE installed | Lamco RDP Server |
| Multi-user concurrent sessions | lamco-VDI (dev) |
| Headless server (no DE) | lamco-VDI (dev) |
| Enterprise VDI (50+ users) | lamco-VDI (dev) |
Ready to Get Started?
Download Lamco RDP Server and experience zero-dialog unattended access on your Linux desktop.