KRFB on Wayland, Have to confirm "Remote control requested"


I have to confirm the share screen on the devices running krfb on Wayland.
“Remote control requested” pop-up appear on the shared desktop screen, even if I select “Enable Unattended Access” with krfb on Wayland.


  1. In system settings → startup and shutdown → Login Screen (SDDM) → Behaviour → automatically login with session Plasma (Wayland)

  2. In system settings → startup and shutdown → Autostart → add krfb

  3. Launch krfb and Select “Enable Unattended Access” to allow the unattended Access.
    2022.08.15_KRFB_Wayland_Enable Unattended Access

  4. Reboot your device.

On boot device I have to allow the access to the remote computer even if I selected “Enable Unattended Access” running krfb on Wayland, this pop-up appears on screen :

Remote control requested pop-up :

Remote the computer sharing a desktop with krfb on Wayland without to click on the pop-up “Remote control requested”.

Linux/KDE Plasma:
(available in About System)
KDE Plasma Version: 5.27.5
KDE Frameworks Version: 5.106
Qt Version: 5.15.9
Krfb Version : 23.04.1



KDE KRFB Wayland :


I’m very pleased & thankful for your effort.

Krdc and krfb are 2 nice kde product, with a fully GUI setup !

A new feature appears with krfb on Wayland, "Remote control requested”, good idea to improve the remote computer security, but not practice for a home usage and remote the x86 or arm devices build for home server without screen, keyboard and mouse.

With “Remote control requested”, I have to confirm the share screen, but I can’t because no screen, mouse and keyboard are plugged on my devices running krfb on Wayland. Same issue on arm devices running Wayland.
X11 don’t provide this feature, I start krfb on X11 with the Autostart software on startup and then I remote with krdc the devices sharing their desktop with krfb on X11, really simple and practice.

How to avoid this new krfb Wayland feature ? I mean the pop-up showing “Remote control requested”.

Is it a krfb on Wayland bug ? which don’t take the function “Enable Unattended Access”, no issue like this with krfb on X11. I don’t know how to select this pop-up “Remote control requested” with ssh…

Is it a solution ? I suggest :
2023.07.01_KRFB_Wayland_Select what to share and New connection security suggestion

It will be great to use fully Wayland on the devices I manage with krfb.
As you know some Linux distro are now fully using Wayland.

Thanks for reading this post, no problem to provide more info, I stay tune.

edit : no problem with krdc on Wayland to remote windows 7 and 10 devices (windows vnc sharing server → ultra vnc 1.4.20)
no problem to remote a x86 Linux device sharing desktop with krfb on Wayland, the Linux device is remote with an android vnc viewer => bVNC Secure VNC Viewer

Kde user since ~ 2003 :slight_smile:

1 Like

I have noticed this over the last months as well. I would also recommend supporting krfb to be started before a user is logged in. While at home I don’t mind having my user auto login, on a machine shared by users this might not be suitable.

In reality, VNC has always been the poor performer, having sluggish feeling compared to RDP to windows boxes. Wish there was a much better and more modern approach to remote desktop in the Linux world. VNC is over 20 years old now, wasn’t great at the start and it’s less great today.

1 Like

Thanks for your feedback.

The dev are working hard, krfb and krdc are often up to date.

1 Like - I would possibly suggest NoMachine. I’ve now got this setup and running smoothly. Basically works out of the box but requires you to install it on your client which you connect from as well (be sure to turn off the server on your client desktop). I setup H.265 codec on my server as it seemed a bit sharper.


Hmm, the option to “Allow without confirmation” would be great.

I have this same issue with KDE Connect, where I am laying in bed and want to control my mouse to queue up a youtube video, but instead I have to get up and walk to my PC, click the button, then go back to my bed. The whole point of “remote control” is a bit lost when I do that!

I think I’ve traced it to xdg-desktop-portal-kde which handles the virtual input in my case, but I suspect it also provides the interfaces for krfb.

For a “catchall” solution which would handle both of our woes, it would be nice to have a “Remember this choice for this client” checkbox on the confirmation dialogue itself (also?)


Linux Kernel v6.1.50, Desktop Sharing v23.8.1

I had the same problem and it turned out that the “Change Unattended Password” attempts to the change (Or perhaps actually does create a separate, different password) the password in the “Connection Settings” pane.

Result? If you change the unattended password so that it is different from the “main” password (A reasonable thing, to my mind), KRFB asks for permission on the host machine to allow the connection. If the unattended password is the same as the “Connection Settings” password, smooth sailing.

1 Like