Hello World,
In our previous post (xRDP – xRDP shows only black screen after authentication windows – HowTo Fix !), we have explained that a same user cannot at the same time be connected locally on the Ubuntu machine and perform a remote session. If you try to connect in such scenario, you will end up either viewing a black screen or you will be disconnected after a few seconds.
In this post, we will provide some workarounds that can be used to prevent such situation and allow a user to login via xRDP even if the same user account is already logged on locally on the Ubuntu machine…
Let’s demonstrate this
Overview
xRDP is a software alternative that allow users to perform remote connections against a Linux machine. xRDP, while providing similar functionality as Remote Desktop Services, does not behave exactly the same way as Remote Desktop Server. For example, it’s not possible to connect via xRDP to the console session remotely (as far as we know). The other limitation that’s generating a lot of annoyance and frustration is that a same user account cannot be logged on concurrently locally and remotely on the system.
If a user (let’s call him Jim) is logged on locally on the Ubuntu machine where xRDP software is installed, the same user (Jim) will not be able to acquire a desktop session while performing the xRDP Session. Jim will see only a black screen or will be disconnected after a few seconds. This is the default behavior !
However, there are some workarounds that can be used to prevent the black screen when logged in locally and remotely concurrently using the same user account. We have found so far three workarounds that can be used to prevent the black screen situation. Please note that these are only workarounds which comes with other limitations !!!
Workaround Options
In this section, we will show you three different ways that would allow a user to perform a remote session while already logged locally on the Linux machine. Again, please treat this information as workarounds as some limitations would still apply within your remote session….
Workaround 1 – Start xRDP in Debug mode
The first option is probably the least practical ! You have to manually start the xrdp service manually in debugging mode and only a single user will be able to connect remotely. To run xrdp in debugging mode, you have to perform the following actions
If you have performed a standard xrdp installation (ubuntu xrdp package), use this information
step 1 – stop xrdp service (sudo systemctl stop xrdp)
step 2 – Open a terminal console and issue the following command
cd /usr/sbin
sudo ./xrdp -ns
step 3 – Open another terminal console and issue the following command
cd /usr/sbin
sudo ./xrdp-sesman -ns
If you have performed a custom xrdp installation (compiled from sources), use this information
step 1 – stop xrdp service (sudo systemctl stop xrdp)
step 2 – Open a terminal console and issue the following command
cd /usr/local/sbin
sudo ./xrdp -ns
step 3 – Open another terminal console and issue the following command
cd /usr/local/sbin
sudo ./xrdp-sesman -ns
Click on Picture for Better Resolution
Limitations
You have to start the service in a specific way and in debug mode, it seems that only a single user connection will be accepted. This is probably not the best option to use if you want to have local and remote access concurrently from the same user account. Check the other two options as they are easy to implement….
Workaround 2 – using dbus-launch approach
This trick is probably a better approach because it’s simpler to implement. You will simply need to modify your /etc/xrdp/startwm.sh file and appending a one liner that will allow you to basically acquire the desktop while performing your remote connection even if you are already logged on locally. To implement this trick, simply open the /etc/xrdp/startwm.sh with your favorite text editor..
sudo nano /etc/xrdp/startwm.sh
At the end of the file, locate the line test -x /etc/X11/Xsession && exec /etc/X11/Xsession and just above it add the following command
export $(dbus-launch)
Click on Picture for better Resolution
Save the file and restart the xRDP service (i.e. sudo systemctl restart xrdp)
Now, you can give it a try. Stay logged on locally on the machine and initiate your remote session
Click on Picture for better Resolution
As mentioned, you will be able to remote connect to your machine
Limitations
One limitation we have noticed is that some software or program will complain if they are already in use in one of the existing session. For example, if Firefox is open and running on the Ubuntu machine where are logged on locally and you try to start firefox in your remote session, it will not work. You will receive a message stating that firefox is already running
Click on Picture for better Resolution
Another limitation with this method will be present if you are using wayland display server instead of X11 Display server. This trick will not work if you are using Wayland solution.
A final limitation is related to login process. The trick here allows you to launch an additional remote desktop session. However, if you are login first through the remote connection and try to login locally, you should still encounter the infinite loop.
Workaround 3 – unsetting DBUS_SESSION_BUS_ADRESS approach
Credits : https://catch22cats.blogspot.com/2018/05/xrdp-blank-screen-with-ubuntu-1804.html
This trick is similar to the workaround #2. You will also need to edit and modify the /etc/xrdp/startwm.sh file and add some additional commands to be executed when the remote session will be initiated. To implement this trick, simply open the /etc/xrdp/startwm.sh with your favorite text editor..
sudo nano /etc/xrdp/startwm.sh
At the end of the file, locate the line test -x /etc/X11/Xsession && exec /etc/X11/Xsession and just above it add the f
unset DBUS_SESSION_BUS_ADDRESS unset XDG_RUNTIME_DIR
Click on Picture for better Resolution
Save your file and restart the xrdp service.
Now, you can give it a try. Stay logged on locally on the machine and initiate your remote session
Click on Picture for better Resolution
Limitations
One limitation we have noticed is that some software or program will complain if they are already in use in one of the existing session. For example, if Firefox is open and running on the Ubuntu machine where are logged on locally and you try to start firefox in your remote session, it will not work. You will receive a message stating that firefox is already running
Click on Picture for better Resolution
However, you can always kill the process through the remote session and try to start the firefox process again and this should be working….
A final limitation is related to login process. The trick here allows you to launch an additional remote desktop session. However, if you are login first through the remote connection and try to login locally, you should still encounter the infinite loop.
Final Notes
This is it for this short post !
By default, xRDP will only allow a single session per user account. By default, a same user account cannot be , at the same time, logged on locally on the Linux machine and remotely. If a user tries to remote connect to the machine, a black screen will be presented when remotely connected. To overcome this situation, the recommended way would be to logoff from the machine (local session) and then perform the remote desktop connection. This single connection session is really causing a lot of frustrations and annoyance.
We had to find a way to perform local and remote connections using the same account when using xRDP. After some research, trial and error, we have a finally found some ways and workarounds that can be used which will ensure that same user account will be able to get at the same time a local connection and a remote connection. Use this information at your own risk as we didn’t extensively tested and worked with them. We would strongly recommend you to logoff properly from the local session before trying to perform remote login connections
Till next time
See ya
Another workaround is to ssh into your machine and log your user out remotely:
sudo systemctl restart systemd-logind; sudo systemctl restart display-manager; loginctl terminate-user USERNAME
@Ben,
Thank you for visiting our blog and sharing your findings. This can indeed be a valid workaround as long as the ssh service has been installed and enabled
Thanks for your feedback
Till next time
See ya
Hi Griffon
I have used your blog to successfully set up xrdp on Ubuntu 20.04 and connect to it from a Windows 10 machine.
Everything is working (at last). I have used the workaround 2 for a single user multiple sessions.
Had an issue with user authentication for SMART on hard drives but disabled lm-sensors which seemed to fix that.
However I have one final issue I cannot seem to solve. I would like to be able to log on using a user via RDP to a single session.
I.e. I log on to my Ubuntu machine with user A via RDP open a few programs documents etc. Then log on to the physical machine with user A and have the same desktop come up with all the programs and documents that are open in the remote session.
Is this possible?
Thanks Dave
@Dave;
Thank you for visiting our blog and providing feedback. What you are trying to achieve is not possible with xRDP software and the xorgxrdp software. xRDP will not connect to the “console” session. If you want to take over your session, you would need to use a software like VNC. So, as far as we know, there is no way to connect to the console session via xRDP software
Hope this help
Till next time
See ya
Thanks for the reply. I thought that might be the case.
@DAve,
No worries 🙂
Till next time
See ya
After beating my head against the wall on this issue with Ubuntu-Server 20.04.3 LTS and Xubuntu, I accidentally stumbled across the solution. Despite all the installation steps, the X-session manager is not correctly configured to use a session-based solution. By executing:
sudo update-alternatives –config x-session-manager
then selecting the ‘xfce4-session’ option, I was able to successfully RDP into the server.
Hope this helps someone.
@Keen;
Thank you for visiting our blog and sharing your findings…
till next time
See ya
I propose you a workaround inspired of workaround 2
Create a file /etc/X11/xinit/xinitrc.d/multisession.sh:
export $(dbus-launch)
Tested on Cento8
@Cyril;
Thank you for visiting your blog and providing feedback and suggestions. Indeed, this would be one way to overcome the limitation and automate the process 🙂
We still investigating the workarounds in order to see if there is not other limitations that come with it
Till next time
See ya
Very useful script. I had been trying to get this to work on my own, homebrewed VM as a Virtual Desktop, and your script helped. I also have another VM running Garuda(ArchLinux) and that one seemed to work out of the box, using VNC with little configuration. You might want to check out what they have done.
Thanks!
@Gustavo,
Thank you for visiting our blog and providing feedback… Happy to see that the script is useful and can help you. We are trying to add more and more distributions but this take time and effort
till next time
See ya
Think that the command in Kevi Steele’s comment should be
sudo update-alternatives --config x-session-manager
rather than
sudo update-alternatives –config x-session-manager
at least on Linux Mint
H
Urg not sure if I fat fingered that comment, or your comment engine chews things.
That config command should be preceded by two dashes but seems to be rendered by the comment engine as a single dash. If you cut and paste the string in the original comment it returns an error as a command.
I thought I corrected it in the first line of my comment, but testing a cut and paste of my comment, shows a single dash in both command lines. So please either correct my comment if I fat fingered it, or if it is an issue with the rendering drop my comment and see if you can make it so copy and paste will work.
H
@boss & @urg,
indeed there is a formating issue when placing a command…. so the command should be
sudo update-alternatives –-config x-session-manager
Thank you for letting us know…we will fix the issue in your comments as well
Till next time
See ya