How to make Manjaro (KDE 5) work as a xrdp server?

[eduardolucioac]

Simple question, but difficult to solve... So far... =|

How to make Manjaro (KDE 5) work as a xrdp server?

NOTE: We really like the xrdp protocol and have used it in the past with other Linux distros (Ubuntu) as a server, but we are having a hard time getting xrdp to work on Manjaro (KDE) as a server.

Thanks! =D

INTERESTING LINKS ABOUT THE SUBJECT: https://forum.manjaro.org/t/xrdp-cant-get-plasma-to-start-after-initial-logging-into-xrdp-xorg-session/110678 https://forum.manjaro.org/t/not-able-to-rdp-from-windows-to-manjaro-vm-via-xrdp-xorg/94357/2 https://wiki.archlinux.org/index.php/xrdphttps://www.hiroom2.com/2019/06/15/ubuntu-1904-xrdp-kde-en/ https://www.hiroom2.com/2019/06/15/ubuntu-1904-xrdp-kde-en/ https://superuser.com/questions/1509055/manjaro-kde-running-as-a-rdp-server https://forum.manjaro.org/t/manjaro-kde-running-as-a-rdp-server/114561

[koranza]

The following worked for me, using Manjaro KDE (manjaro-kde-20.2-201207-linux59.iso)

1. Install xrdp and xorgxrdp-git from AUR (Note: there is also a xrdp-git package available. That also worked for me, as an alternative to xrdp)

sudo pacman -S yay                        # install an AUR helper
yay -S aur/xrdp aur/xorgxrdp-git          # install xrdp from AUR

2. Add allowed_users=anybody to /etc/X11/Xwrapper.config to allow anybody to start X. (Note: This step was taken from https://wiki.archlinux.org/index.php/xrdp. I had to create that file since it did not previously exist.)

3. important: Do either Option A or Option B as a workaround

Option A) Modify /etc/xrdp/startwm.sh, the start script that xrdp uses when logging in, to avoid calling . ~/.xinitrc. (Note: This step was taken from https://github.com/neutrinolabs/xrdp/issues/1554#issuecomment-674868428 . I only had to modify the start script though, I did not modify sesman.ini at all)

file: /etc/xrdp/startwm.sh

  # arch user
  if [ -r ~/.xinitrc ]; then
    #. ~/.xinitrc                          # <-- Do not call this line; it will crash
    eval $(dbus-launch --sh-syntax)        # Add these 2 lines, in order to...
    startplasma-x11                        # ...start plasma directly instead of calling . ~/.xinitrc
    exit 0
  fi

Option B) Modify ~/.xinitrc to fix a bug + alter the dbus command. The bug* is that startkde is used instead of startplasma-x11 in 2 places (only showing 1 place below). Then alter dbus-args to remove --exit-with-session flag; if you don't, you will see the desktop environment start to load but it will hang.

file: ~/.xinitrc

#DEFAULT_SESSION=startkde                 # <-- bug, the startkde command no longer exists
DEFAULT_SESSION=startplasma-x11

and

get_session(){
    #local dbus_args=(--sh-syntax --exit-with-session)    # <-- the '--exit-with-session' flag causes hang
    local dbus_args=(--sh-syntax)

4. Enable and Start the xrdp + xrdp-sesman services. If you had them already running, restart them.

sudo systemctl enable xrdp
sudo systemctl enable xrdp-sesman
sudo systemctl start xrdp
sudo systemctl start xrdp-sesman

5. Get the ip address of your machine, which is now running xrdp. (look for inet [ipaddress] in the output)

ip address

6. From another machine, run a Remote Desktop client with the ip address from the machine that's running xrdp.

rdesktop -u [username] [ipaddress]

Notes

• I'm not sure which workaround is better; both worked for me and didn't break things after a reboot.
• It seems like the main issue may be with Manjaro's ~/.xinitrx file. Ideally, Manjaro would fix this issue on its end rather than end users making changes. Where are bugs tracked for manjaro kde? Is this it https://gitlab.manjaro.org/profiles-and-settings/manjaro-kde-settings/-/issues/9?
• If you get the username / password wrong, the login will fail. If you run sudo systemctl status xrdp-sesman from the machine running xrdp, the log will be obvious about it, with entries mentioning pam_faillock(xrdp-sesman:auth): User unknown and pam_unix(xrdp-sesman:auth): authentication failure;
• Is there anyway to improve error reporting/logging from xrdp's side of things for errors in startwm.sh though? What if another line in startwm.sh crashes in the future?
• There is a similar issue about xrdp not working (https://github.com/neutrinolabs/xrdp/issues/1684), which suggest modifying a line in /etc/pam.d/system-auth. I tried this suggestion, but it seemed worse because there are then popups asking for permission when I log in (for Network/wifi I think). Also, the sound devices were different -- with the modification, I see the same sound devices that I see when logged into the machine locally/normally; without the modification, I do not see any sound devices. I'm not sure what is more correct, haven't even explored how to get sound to work yet.

[matt335672]

Thanks for that @koranza - that may well be useful to some other users.

Regarding your last point on (#1684), it's possible your polkit isn't working properly when you DONT see the popups. That may be OK for you and your use case, but other KDE users have problems without polkit - see #1773 and #1709.

[agowa]

Note: Because of #1684 one also wants to edit /etc/pam.d/system-auth and add a leading "#" to all lines containing "pam_systemd_home.so" or otherwise the systemd user daemon won't start and stuff like ssh-agent, dbus and audio may not work. (This obviously disables systemd-home, so this only works if you don't use it)

Note2: Instead of option A and B, there is a simple other way, for me the file ~/.xinitrc didn't exist at all, in that case just putting this in there will also work:

#!/bin/sh
exec startplasma-x11

And because we worked around #1684 systemd will take care of starting dbus for us. Therefore we don't need to execute eval $(dbus-launch --sh-syntax) manually

Note3: And for kwallet and gnome keyring to work (yes I need both because of applications that support either or and I need both applications) one also needs to edit /etc/pam.d/xrdp-sesman to initialize them upon login:

#%PAM-1.0

auth            include         system-remote-login
-auth           optional        pam_gnome_keyring.so
-auth           optional        pam_kwallet5.so

account         include         system-remote-login

password        include         system-remote-login
-password       optional        pam_gnome_keyring.so use_authtok

session         optional        pam_keyinit.so force revoke
session         include         system-remote-login
-session        optional        pam_gnome_keyring.so auto_start
-session        optional        pam_kwallet5.so auto_start

this is equivalent to how it would be configured with sddm, so either add it to both files, or directly within the include chain within /etc/pam.d/system-login.

[avalon60]

I tried installing xrdp on Manjaro 21.1.6 using a similar process to one outlined earlier, and to be precise, I used the instructions outlined here: https://rajasekaranp.medium.com/how-to-setup-xrdp-in-manjaro-linux-e176b22bd347

As a result it broke the Add / Remove Software UI and also stopped the Timeshift UI from launching. When going to install via Add/Remove Software, it allowed me to select packages and confirm the install, but then balked, saying it had failed authentication, despite not having prompted for a password.

Disabling the xrdp service seemed to fix these issues, but that requires a reboot and further reboots to enable - which then breaks the software installer.

[matt335672]

@avalon60 - there's a lot in your post I don't understand. Can you provide a bit more info please.

As a result it broke the Add / Remove Software UI and also stopped the Timeshift UI from launching.

Are you saying these don't work on an xrdp session, or they don't work on the console?

If it's the former, you may well have problems with your PATH and timeshift being started from /bin rather than /usr/bin (or the other way round). This is covered in #1773, but you'll need to read some way down to find it. I know you're not running Debian, but the same principles apply. Check which timeshift is giving you the same output both when timeshift is working and when it's not working.

If it's the latter, the only way I can see there's an affect here is via a change to .xinitrc or .xsession. Set up a clean user on the system for xrdp and see what happens there.

Bear in mind than on a modern Linux with systemd --user you cannot have the same user logged in to the console and an xrdp session at the same time. That's part of the systemd --user design, and there's nothing we can do about it here.

Disabling the xrdp service seemed to fix these issues, but that requires a reboot and further reboots to enable

I don't understand why do you need reboots to disable or enable the service(s). Normally systemctl disable/enable xrdp xrdp-sesman should work. What am I not understanding?

Thanks

[avalon60]

Hi Matt.

I just tested and they do work on the console, just not over remote desktop.

When I try to launch Timeshift over xrdp, nothing happens, no errors, no display. It silently fails,

If I do a "which timeshift", I get:

over xrdp: /sbin/timeshift console: /usr/bin/timeshift

I found the entry you referred to and tried adding the following to the /etc/xrdp/startwm.sh file:

# Emulate the PATH set by login if test -f /etc/login.defs ; then set -- grep "^[[:space:]]*ENV_PATH[[:space:]]" /etc/login.defs if [ $# -eq 2 ]; then eval $2 else echo "**WARNING - can't read ENV_PATH from /etc/login.defs" >&2 fi fi

This did modify the search path, such that the which timeshift, showed as /usr/bin/timeshift. However, it didn't fix the launching of timeshift from the menu. In addition I found that the authentication kept failing, when launched from the command line:

which timeshift                                                                                                                                127 ✘ 
/usr/bin/timeshift
$ timeshift-launcher                                                                                                                                 ✔ 
==== AUTHENTICATING FOR in.teejeetech.pkexec.timeshift-gtk ====
Authentication is required to run Timeshift as Administrator
Authenticating as: Clive Bostock (clive)
Password: 
polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie
==== AUTHENTICATION FAILED ====
Error executing command as another user: Not authorized

This incident has been reported.

If I run timeshift-launcher from konsole on the console, it provides a GUI pop-up to enter the password, and once entered, it takes me into the UI for Timeshift. However, over xrdp, I get a character based password prompt, and despite repeated tries, with the same password as per that used on the console, I get the above output.

Thanks,

Clive

[matt335672]

Getting the PATH right is the first piece of the puzzle, and a pretty important one.

The second bit is convicing polkit to authenticate your program (timeshift or whatever). On my Manjaro VM, the policykit action you're trying to run looks like this:-

$ pkaction --action-id in.teejeetech.pkexec.timeshift-gtk --verbose
in.teejeetech.pkexec.timeshift-gtk:
  description:       Run Timeshift as Administrator
  message:           Authentication is required to run Timeshift as Administrator
  vendor:            Tony George
  vendor_url:        https://github.com/teejee2008
  icon:              timeshift
  implicit any:      auth_admin
  implicit inactive: auth_admin
  implicit active:   auth_admin
  annotation:        org.freedesktop.policykit.exec.path -> /usr/bin/timeshift-gtk
  annotation:        org.freedesktop.policykit.exec.allow_gui -> true

That all looks OK, assuming clive is an administrator.

I'm wondering if you've bumped in to #1684, as this can sink polkit, and it was originally reported against Manjaro. If you have, you'll have the following symptoms:-

• Your graphical session will not appear in the output of loginctl
• In the system log, you'll find mesages like pam_systemd(xrdp-sesman:session): Failed to create session: No child processes

If this is the case, have a look at this post and the one under it.

[avalon60]

My output looks similar.

pkaction --action-id in.teejeetech.pkexec.timeshift-gtk --verbose                              127 ✘ 
in.teejeetech.pkexec.timeshift-gtk:
  description:       Run Timeshift as Administrator
  message:           Authentication is required to run Timeshift as Administrator
  vendor:            Tony George
  vendor_url:        https://github.com/teejee2008
  icon:              timeshift
  implicit any:      auth_admin
  implicit inactive: auth_admin
  implicit active:   auth_admin
  annotation:        org.freedesktop.policykit.exec.path -> /usr/bin/timeshift-gtk
  annotation:        org.freedesktop.policykit.exec.allow_gui -> true

My account "clive" is not an admin, but on the console of course, it allows me to elevate my privilege to root, by prompting for the root password.

I ran loginctl (remote) and got this:

loginctl                                                                                            ✔ 
SESSION  UID USER  SEAT  TTY
      2 1000 clive seat0 

1 sessions listed.

It then occurred to me that I may also have a session on the console (actually a tv), so I switched it on, and it turned out that there was. So I logged it out and to my surprise, when I ran loginctl again, and again over xrdp, and I got two entries?

loginctl                                                                                            ✔ 
SESSION  UID USER  SEAT  TTY
      2 1000 clive seat0 
     c2  963 sddm  seat0 

I can't say that I am sure where to look for the system log entries that you mentioned.

Thanks,

Clive

[matt335672]

Now you've got rid of the console login, try logging out and back in again over xrdp. The console login really won't help for the reasons outlined above.

Once you've done that, you can get a log of the system activity for the last 3 minutes with journalctl -S -3m. You may need privilege for that operation.

[avalon60]

Hi Matt.

I ran the journal command 3 times:

1. After remote logon;
2. After attempting to run timeshift;
3. After attempting to install gvim.

The second file shows some failures to load several sonnet_* libraries. I don't know what the significance is of this or whether it's relevant, but the shared object files exist. So possibly that's an elevation issue.

Thanks,

Clive

systemlog1.txt systemlog2.txt systemlog3.txt

[matt335672]

That all looks OK to me.

Re-reading the above, are you saying that if you run /usr/bin/timeshift in a console session you get a graphical prompt for a password, but if you run it in an xrdp session you're getting a text-based prompt?

What exactly are the prompts you're getting in each case? You seem to be being asked for your own password for the text prompt rather than the root pasword. This is the Ubuntu default, but doesn't seem to be what you want. See https://askubuntu.com/questions/1199006/how-to-let-polkit-request-root-password-instead-users-password which also covers this area.

[avalon60]

I run the command timeshift-launcher, which prompts for the root password, but complains that I can't execute as another user. I can run /usr/bin/timeshift CLI ok, it's the GUI I can't run.

[matt335672]

It seems odd that you're being prompted by the command-line authentication agent for a GUI application.

Is polkit-kde-authentication-agent-1 running? If not, what happens when you try to start it?

[FlexMcMurphy]

Thank you to @eduardolucioac for really useful set up steps in the initial post. And to @matt335672 for helpful discussion on this topic.

I followed the above instructions and can connect to a remote Manjaro desktop running xrdp from another Manjaro desktop using Remmina. However when I do so I cannot see the existing opened files and applications on the remote desktop, instead I get a fresh, blank desktop. Is that normal behavior? How do I connect to the xrdp server from another client and see the files and applications already opened and running on the remote desktop?

Cheers,

Flex

[matt335672]

Yes, that's normal.

The use-case you want isn't supported directly by xrdp, but can be achieved using other software. I'm assuming you're running KDE Plasma, since you're taking part in this discussion.

• The simplest solution might to be investigate kfrb. I've not used this, so I can't comment on it.
• Another way is to use x11vnc to make your desktop accessible over VNC. You can then connect to the desktop directly from Remmina using VNC, or you can use xrdp as a protocol converter and connect from Remmina using RDP.

[agowa]

@matt335672 shouldn't it also be possible to first login via rdp into a new session and then change it via loginctl activate, loginctl attach or something?

[matt335672]

That's not the way it works.

The user session runs an X (or Wayland) server talking to real hardware.

xrdp sessions use an X server which is designed to be communicated with over the internet. That's either Xvnc, or the standard Xorg server with an add-on providing virtual hardware. There's some limited scope for using hardware acceleration on some platforms.

At present the architecture doesn't allow for both - to use xrdp to talk to the real hardware you'll need to export it over VNC. x11vnc is recommended as it's well documented and supported, but there are other options.

[madmalkav]

Option A in Koranza's post worked for me OK.