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 | Implementation complete |
| 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 specific integration | Any | Varies | Production |
| 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.
Session Health Monitoring
v1.4.2 continuously monitors the health of every subsystem in an active session
Monitored Subsystems
- ✓ PipeWire stream state: Detects when video capture pauses, errors, or recovers
- ✓ Portal session validity: Catches invalidated Portal sessions before they cause failures
- ✓ EIS input streams: Monitors input injection channel health
- ✓ Compositor presence: Detects compositor crashes or restarts
D-Bus Integration
Health state changes are emitted as D-Bus signals on io.lamco.rdp_server.Health, enabling:
- • 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 --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
- + Automatic Flathub updates
- ! 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.