Use X11 if you need unattended access.

Actually ...

Yes, this is the limitation of Wayland, there is no full unattended accesss in Wayland.

That statement is not true. Gnome 47 permits unattended access.

Scenario:

• new Fedora 41 install, with Gnome 47
• create user that has sudo and ssh access
• log that user in to a Gnome session using Wayland

Then, from another external host:

• ssh log in to remote "new Fedora" host with created user
• configure gnome-remote-desktop as user service (all command-line)
• enable port 3389 in "new Fedora" firewall
• start user service gnome-remote-desktop

Now, using an RDP client, you can connect to the just-configured Fedora 41 Gnome Wayland desktop via rdp. There is not a "select screen to share" popup; the gnome-remote-desktop service knows how to overcome that wayland request, and the user gets to view and interact with the remote desktop as expected.

I think Rust Desktop just needs to do some extra work with libei or wayland portals or whatever, and then rustdesk can skip this dialog for users, too, providing full unattended remote access.

Also, this:
https://www.reddit.com/r/wayland/comments/1bhpmur/comment/kvj8g8j/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

Also getting this dialog.
Is there any way to fix this?

RustDesk 1.3.9

Operating System: Fedora Linux 41
KDE Plasma Version: 6.3.3
KDE Frameworks Version: 6.12.0
Qt Version: 6.8.2
Kernel Version: 6.13.9-200.fc41.x86_64 (64-bit)
Graphics Platform: offscreen
Processors: 12 × AMD Ryzen 5 7600 6-Core Processor
Memory: 14.8 GiB of RAM

Hi everyone,

I’d like to raise awareness and open a discussion regarding an ongoing issue when sharing screens in Wayland sessions (e.g., on Ubuntu with Mutter): the monitor selection is not remembered between sessions or reboots.

Currently, when a remote desktop or screen sharing tool (such as a video conferencing app using xdg-desktop-portal) is used, the user is prompted to select a monitor every time. That selection is not persisted, even if the user regularly chooses the same display.

issue on xdg desktop https://gitlab.gnome.org/GNOME/mutter/-/issues?show=eyJpaWQiOiI0MTU1IiwiZnVsbF9wYXRoIjoiR05PTUUvbXV0dGVyIiwiaWQiOjIyMjEzMH0%3D

In this Mutter issue, the GNOME team clarified that this is not a bug in Mutter or Wayland itself. Instead, it is up to the application to implement support for restore tokens, as defined in the remote desktop portal documentation:

"Yes, the application must use 'restore tokens' as documented by the remote desktop portal. See the restore_token property of SelectDevices() in https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.RemoteDesktop.html."

Furthermore, to persist the monitor selection across reboots, the application must set:

persist_mode = 2 (indefinite)

However, the Mutter team also notes:

"If that is done, but isn't working, then open an issue on https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome, where this is handled."

This implies that even when an application correctly implements restore tokens and sets the persistence mode to indefinite, it may still fail due to a bug or limitation in the xdg-desktop-portal-gnome implementation.

Suggestions
Improve documentation and visibility of this behavior for application developers, particularly for those integrating screen sharing in Wayland environments.

Provide sample code or a working example that correctly implements restore_token with persist_mode: 2.

Consider fallback mechanisms at the system level, or user preferences that allow monitor selection to persist even if the application does not explicitly support restore tokens.

From a user’s perspective, this feels like a system bug — because apps on X11 generally remember the monitor without any extra logic. Clarifying the required responsibilities on both the app and system side would help developers and users alike.

Is there any ongoing work to improve this UX or make restore token handling more consistent across apps?

Thanks for all your hard work on Mutter, GNOME, and the Wayland ecosystem!

For KDE users:

1. install rustdesk from flatpak

flatpak install com.rustdesk.RustDesk

2. set this special permission:

flatpak permission-set kde-authorized remote-desktop com.rustdesk.RustDesk yes

Caveats:

1. fresh installation => fresh id
2. with multiple displays you will not be able to select only one of them, you will be working with the full desktop.

More info: https://develop.kde.org/docs/administration/portal-permissions/

This feature was introduced in Plasma 6.3.

In my case I just removed the deb package, followed the steps above, it worked and that's enough for me. Just checked using v1.4.0 to connect from Android to Kubuntu 25.04 and KDE 6.3.4.

Hi, my Gnome got update to its last version, and X11 was removed. I think now I can only use Wayland. If I set in custom.conf to force X11, then it doesn't work.

This means that currently RustDesk doesn't work with Gnome. Any workaround?

It has been a while. I am still using Gnome/Wayland. Every time I connect remotely, it asks to confirm in the host computer, which defeats the point of using a remote access application. Just wondering if there's any workaround, or still stuck with this.

I've been working on a solution for the Wayland login screen issue. It's working on my Arch Linux + GDM
setup.

Approach: When the host is at a Wayland login screen, instead of rejecting the connection, the remote user
gets a username/password dialog. Credentials are validated via PAM, then the display manager is
temporarily configured for autologin and restarted. The DM launches a full desktop session with all
systemd/D-Bus infrastructure, and the original config is restored after 10 seconds.

Supports: GDM, SDDM, LightDM

Branch: https://github.com/julianjc84/rustdesk/tree/julian/wayland-login-pam

Writeup:
https://github.com/julianjc84/rustdesk/blob/julian/wayland-login-pam/docs/wayland-login-support.md

Tested on Arch Linux with GDM (Wayland greeter) + KDE Plasma Wayland session.

With Ubuntu 26.04 on the horizon (Wayland only), I am wondering whether there is a plan to incorporate fixes that would allow unattended access for Rustdesk on Wayland-based systems.

Turning Wayland off will no longer be a viable workaround for headless Ubuntu users. I am curious whether others in the community are facing this issue as well.

I have also noticed that Ubuntu-flavored Rustdesk receives special mention in the downloads page table. Is it reasonable to interpret this as the developers giving special attention to Ubuntu over other Linux distributions?

For context, I am a Pop!_OS (Cosmic) user, so I expect I will have some additional configuration to manage regardless. However, it seems worth flagging that the upcoming Ubuntu LTS release will introduce this significant change, potentially rendering the standard Ubuntu .deb unable to provide headless access without additional configuration or workarounds.

Same problem, I don't even know if it's possible to switch back to X11 with 26.04 installed

A working recipe for unattended Wayland access: GNOME Remote Desktop (Remote Login) + Tailscale + an RDP client

If you landed here because RustDesk keeps throwing the "select the screen to be shared" picker and can't reach a locked GNOME/Wayland box, this is the setup that finally gave me genuine unattended access. It sidesteps the screencast portal entirely.

Why the portal path is a dead end (briefly, since most of this thread already knows): while the session is locked, mutter refuses to create or restore any portal screencast (Session creation inhibited), and each locked attempt tends to consume the saved restore token, dropping you back to the picker. That is a Wayland portal limitation, not a RustDesk bug, so no token-stashing scheme survives it.

The fix is GNOME Remote Desktop's system "Remote Login" over RDP (GNOME 46 or newer). It uses mutter's privileged remote-desktop API rather than the portal, so it works at the GDM login screen and is never inhibited by the lock shield. You then reach it from anywhere over a Tailscale mesh, using any ordinary RDP client.

Below is the whole thing in order: set up the host, put it on Tailscale, set up each client, then the routine you run each time you connect.

Part 1: Host (the Linux machine you want to reach)

1a. Enable Remote Login.

On GNOME 48+ there is a toggle: Settings > System > Remote Desktop > Remote Login (distinct from "Desktop Sharing", which is the portal path you want to avoid). On GNOME 46/47, or if you prefer the command line, use grdctl:

# generate a self-signed cert if you don't have one
openssl req -x509 -newkey rsa:4096 -nodes -keyout ~/tls.key -out ~/tls.crt -days 3650 -subj "/CN=remote-login"

# configure the SYSTEM daemon (this is the login-screen one)
sudo grdctl --system rdp set-tls-cert /path/to/tls.crt
sudo grdctl --system rdp set-tls-key  /path/to/tls.key
sudo grdctl --system rdp set-credentials <RDP_USER> <RDP_PASS>
sudo grdctl --system rdp enable
sudo systemctl enable --now gnome-remote-desktop.service

Two things worth understanding about what you just started:

• The system daemon listens on port 3389 and shows a GDM login screen when you connect. Once you authenticate it starts (or reconnects to) your session and hands the connection over to a per-session daemon on a negotiated port (3390 in my case). Both need to be reachable, which the firewall step below handles.
• The <RDP_USER>/<RDP_PASS> you set here gate the RDP connection only. They are separate from your normal login password, which you still type at the GNOME screen afterwards to unlock the desktop.

1b. Remove conflicts. If xrdp is installed it may already be sitting on port 3389; disable it (sudo systemctl disable --now xrdp xrdp-sesman) so GNOME Remote Desktop can take the port.

Part 2: Put the host on Tailscale

Tailscale gives every device a stable private address on a mesh VPN, so you never expose RDP to the public internet and you don't need port forwarding or a static IP.

On the host:

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up          # prints a login URL; open it and sign in to create your tailnet
tailscale ip -4            # note this 100.x.y.z address; it's what clients connect to

Firewall. If you run ufw, the simplest reliable rule is to trust the Tailscale interface, which covers both 3389 and the negotiated handover port without you tracking port numbers:

sudo ufw allow in on tailscale0

If you prefer to be specific, allow 3389 and the handover port (3390) on tailscale0 instead.

The host is now ready and both services auto-start on boot, so nothing needs doing at the machine before you leave.

Part 3: Set up each client device (one-time)

You install two things on every client: the Tailscale app (signed into the same account, so the host appears in its device list) and an RDP client. Then you save the connection so future use is two taps.

Windows

1. Install Tailscale for Windows, sign in with the same account.
2. RDP client: either the built-in mstsc (Start > type mstsc) or Microsoft's Windows App from the Store.
3. Add a PC using the host's Tailscale address (the 100.x.y.z from Part 2), username exactly <RDP_USER>.
4. Save the credential so it stops prompting: open Credential Manager (Start > "Credential Manager") > Windows Credentials > Add a Windows credential, then Address TERMSRV/<host-tailscale-ip>, User <RDP_USER>, Password <RDP_PASS>. This sticks for both mstsc and Windows App, which some Windows App builds otherwise fail to remember.

Android

1. Install the Tailscale app, sign in. Then keep it from being killed in the background: enable its battery-optimisation exemption, and turn on Always-on VPN (Android Settings > Network & internet > VPN > Tailscale gear icon). If you skip this the tunnel silently drops.
2. RDP client: Microsoft's Windows App (Android) works well; any RDP app will do.
3. Add a PC with the host's Tailscale address, username <RDP_USER>, password <RDP_PASS>.

iPhone / iPad (equivalent)

1. Install Tailscale from the App Store, sign in. iOS is less aggressive at killing VPNs than Android; enable Tailscale's on-demand option if you want it always up.
2. RDP client: Microsoft Windows App for iOS. Add the PC exactly as above.

Linux laptop (equivalent)

1. Install Tailscale (curl -fsSL https://tailscale.com/install.sh | sh, then sudo tailscale up).
2. RDP client: GNOME Connections, Remmina, or FreeRDP from the terminal, for example:
   xfreerdp3 /v:<host-tailscale-ip> /u:<RDP_USER> (it will prompt for the password and the certificate).

On the first connection from any client you will get a certificate warning because the cert is self-signed; accept it once.

Part 4: Connecting remotely (the routine each time)

1. Turn Tailscale on on your client and confirm it shows connected. This is the step most likely to have quietly dropped, especially on Android.
2. Open your RDP client and connect to the host's Tailscale address.
3. Authenticate the RDP layer with <RDP_USER> / <RDP_PASS>.
4. A GNOME/GDM login screen appears inside the RDP window. Type your normal login password to reach the desktop.

That is it. From a phone it is: flip Tailscale on, tap the saved PC, type your unlock password.

Gotchas that cost me time

• Send the username bare. It must be user, not DOMAIN\user and not an email address. If RDP fails at the auth stage with 0xea and the host journal shows Could not find user in SAM database, the password was never checked: the username format is wrong. Windows clients love to substitute your Microsoft-account name, so set it explicitly.
• Error 0x204 is a network failure, not a credentials failure. It means the client can't reach the host at all, which almost always means Tailscale is off or disconnected on that device.
• A disconnect or timeout does not kill anything. The remote session keeps running, and reconnecting drops you straight back into it with every window intact. Only an explicit log-out, or a login into a different session (for instance someone sitting down at the physical machine), tears it down.
• This is remote login, not screen mirroring. Connecting from away starts a fresh session and logs out whatever was on the physical seat at home. Save your local work before you leave. Long-running jobs should be detached (systemd-run --user --scope ...) so they survive.
• One client at a time. A second device connecting is refused or steals the session, so disconnect one before testing another.
• No monitor-layout binding. Unlike the portal restore token, RDP does not care about your display configuration, so you no longer need to pre-set a single-monitor layout before disconnecting.

It is less turnkey than RustDesk's built-in NAT traversal, since you supply the VPN yourself, but it is the only approach I have found that gives real unattended access to a locked GNOME/Wayland machine, and it is an officially supported mechanism rather than a workaround.