XRDP session immediately closes after loggin in. #1412
Comments
|
Sorry this is not a solution! The same problem is happening with Xubuntu 18.04 LTS, Xubuntu 19.04. I searched for half a day and tried many solutions but showed the same problem.. Below is the log when connecting.
I think it's an xorg problem, but I haven't found a solution yet. |
|
Hi @faya9551 Following may be the reason for your issue:
|
|
I am getting the same thing, but it only seems to happen if I log into the machine locally and then, without logging out, try to log in with xrdp. If I am not logged in on the machine and I try to log in with xrdp then it works. Also if I disconnect from an xrdp session and a reconnect to the logged in session it still works. That's happening on a Pop! OS 19.04 VM. |
|
No feedback from the reporter, closed. |
|
Hi people! When I am trying to run Kivy applications in xfce4 this is what I got: This is my system info: Best Regards |
|
Currently experiencing the same issue when attempting to xrdp into a Termux chroot running in Android 10 - Samsung Galaxy Note 10+ Ubuntu version is 20.04 VNC setup functions when using vnc server and vnc client: vnserver > vnc client : ok |
|
this worked for me on oracle linux 8 minimal install with xfce4 from epel: there are lots of failsafes but when the system is minimally installed there is really no failsafe on ol8 so failing to launch a desktop environment will result in normal action = ending the xorg xrdp session places to look to see how things are tried: inside you will see it is searching for if you want it system-wide, put this in EDIT (note for myself) Also there is no configuration file like on RHEL about system default session but |
This worked for me in Ubuntu Bionic. Thanks very much for posting it. |
worked for Ubuntu, thanks a lot. |
|
I'm having a similar issue. Ubuntu 20.04 I have 10 of these machines deployed across multiple client sites with different network/firewall configurations. These machines are deployed with a standard configuration which includes xrdp, desktop environment budgie desktop with lightdm, how we connect to the clients and these machines are under configuration management ensuring the configs are reverted back. One client has two machines that was recently deployed and I'm getting this issue on only these two machines. At this point, I'm only getting this problem when I connect to the console of the machine (shared with the physical user). Once I get disconnected which might be right after authentication or up to 15 seconds. I can see and interact with the desktop depending how long the session lasts. If I reconnect, I might get disconnected again or the connection might be stable. usually after 2-3 reconnects I will get a stable connection. If I connect to a virtual session, using a different user the session hasn't disconnected so far. I'm not able to login to a virtual desktop using the console user as it's always in use. I captured packets with wireshark from the connecting source and there is no reset packets or anything that indicates a network problem. There is no .xsession in the user home directory on any of the deployed machines. All machines are updated at the same time. |
|
@d2ai - this sounds like a completely different problem. You mention the console, so I imagine you're using x11vnc or similar, and connecting to that. Tagging a description on to a closed issue is never a good idea. May I trouble you to open a separate issue for this? Please include details of how you're connecting to the console on the machines, and whether you're using xrdp from the repositories or another source. |
|
Yes it's connecting to x11vnc. This issue may not be xrdp related at all but for completeness. I'm using apache guacamole to connect to these systems over RDP which connects to x11vnc and there are two clipboard options for each connection. When I have them enabled, I get the disconnection issue and since having these options unchecked (default), I haven't had the issue at least not yet. Comparing between the broken machine and a working machine, the difference in the logs is the broken machine is disabling clipboard redirect. Disable copying from remote desktop |
|
It's almost certainly #1885 which was fixed in v0.9.17. You don't see it on a full xrdp session as in this configuration the clipboard is handled by If you're not in a position to upgrade, I can't offer you any workarounds other than the ones you've found. |
It worked for Kali Linux. Thank you so much. |
|
For Rocky Linux 8 and Fedora 39, I got it working by using these steps:
My system was initially installed with the Environment Group: Server If you want to add more security by user access, see this page:: I did not need to install |
|
@jerryamiller |
|
i had the same problem, and found some amazing thing: |
|
Debian GNU/Linux 11 (bullseye) / Gnome |
|
thank you beso,
this seems to be the best way to go!
alex
…On Fri, Jan 27, 2023, 21:12 Beso Bantsadze ***@***.***> wrote:
Debian GNU/Linux 11 (bullseye) / Gnome
This worked for me: http://c-nergy.be/blog/?p=17113
—
Reply to this email directly, view it on GitHub
<#1412 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABER7ALK5H4QDSYOT2IIYQDWUQM3HANCNFSM4IXVDHWA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Nothing really works for me. Every solution ends in frustration. Install, uninstall, add a modification, remove it, restart service.... hour after a hour. Xrdp works fine on my RPI3A+ but only 512mb of RAM, can't do much. I am testing a tv box with armbian bullseye firstly installed, upgraded, upgraded to bookworm... still nothing. On my Windows machine, I launch the client, I type the address or the name of the target host, it opens the login dialog, I type the username and password, one second later, the session is closed. I didn't yet allow root to be allowed as possible user. I'm wasting hours now on this. When I was setting up xrdp on RPI3, I obviously solved the issues I encountered and ended up working, but not now. I still have some things to try and if nothing works... vnc will be... EDIT: I fixed it finally... Using SSH, I created another user using "adduser test", connected using Windows client, entered "test" as username and the password, and it worked. It loaded the MATE desktop, then logged out and entered the original username and no joy, the session gets killed. Then I troubleshooted the home directories, I removed the junk made on my home directory to match what I see on the /home/test directory including removing key.pem and logs from xorgxrdp while keeping connecting to the remote session. One file left on my original account: ".Xauthority". Then I simply deleted the file and connected again and that worked. It loaded the freaking desktop environment after over a day of "trial and error" methods. But still something was screwing local language settings because MATE was loading the English strings when I have the shell set to other language. That problem was tackled by reconfiguring locales on all accounts. I am not sure if the login session problem will come back... Yet to login locally to the desktop environment. |
updating this for my own use:
|
|
xrdp has not worked properly since about 2012-2013. There was some forsaken release around that time, and it screwed everything up. Since then, nothing but impossible-to-solve problems. Prior to that there were no problems whatsoever: install and forget. I tried everything that I found online: fixes to like 1/2 of the OS files, all in order to have xrdp. I suggest that 1) the developer does not care and 2) they are happy watching us bang our heads on our desktops. Why does xrdp-sesman wait for window manager to exit and then exits instead of serving the user's request? This was not a problem prior to 2012. The code base should be just rolled back to the previous state when it did work because there is absolutely zero, nada, zilch worth of value in any changes committed ever since: they do not work. If developers are reading this, then simply roll everything back to pre-2012 and see what was that accursed change that broke everything in this forsaken project. And, for crying out loud, test before you push a release to distros. Having such humongous problems for decades is pathetic. |
To be clear, we never PUSH a release to distros. Distros FETCH releases on their own decisions. |
I am content to notice that you picked on semantics only. It means that the rest of my observations is actual, accurate, to the point and spot-on. |
|
@dca00 - comments like yours above may make you feel a bit better, but they do absolutely nothing to solve your problems or those of others. Frankly I don't understand your comment above. Could you raise a more focussed issue, and we can take a look at it? That way everyone benefits. |
|
@dca00 IIRC, I saw you on GitHub for the first time today. Why didn't you raise any issue for if xrdp has not been working properly for a decade? How can we know xrdp is not working for you unless you let us know? Never. Definitely never! I hope you could report an issue with details as a member of the community. Everyone can report the issue on GitHub but you never reported your impossible-to-solve problems. |
|
This is not about me. This is about xrdp and its developers. I gave up 12 years ago, after a one-year-long back and forth with one of your devs. To my every attempt to troubleshoot xrdp he kept repeating that he only tests his code against Gnome, and that is not something I have or can put on my systems. Still, 12 years and like 12 different versions of various Linuxae later, nothing works, with the same symptoms. |
+1 to this I was planning on integrating it to my dextop project and simply gave up due to zero help or resources to enable a bugfix/solution to it actually just not working regardless of attempts and methods. |
|
To put things in a perspective for you, devs, here's one of MANY threads that shows that almost everything about xrdp is a royal screw-up: https://askubuntu.com/questions/773626/xrdp-login-failed If you are going to claim that all of that is a screw-up on distro maintainers' side, then another thing is wrong with xrdp: it is too difficult to correctly integrate into distros. For some reason everything else in Linuxae seems to work pretty well, at least there are no complete show-stoppers in anything else that I am aware of. Strangely, distro maintainers are able to keep up with everything else but Bottom line is, roll your code back to the point when it worked. No changes that you have made since bring any value for Linux community because you broke the core function of xrdp: its ability to serve remote desktop requests. We do not give a slightest damn about how more secure or sophisticated you might have made it since because you locked us out as a result. Once it is rolled back, carefully reapply each change you have made since, one at a time, and thoroughly test before you roll out another release. Remember that there is not only Gnome out there but several more mainstream window managers: KDE, XFCE, LXDE, and MATE. It has to work equally well with all of them before it may be considered stable. Not doing so means the highest degree of disrespect towards your users. We have suffered that for too long. It is about time someone told you directly that your product does not work though it used to. |
|
I had xrdp issues a while ago and I think one of the issues was a broken xrdp version provided by the distro but I was able to put together a working set of configuration files using xrdp 9.21.1. I haven't tried a newer version but it will probably work with the configs I have. With that said, I'm running xrdp on a fleet of machines, 100+, ubuntu 20.04/22.04 all using gnome and I haven't had a single crash, so does it work? Yes, does it require dark magic and sacrifices to the Gods? Yes, probably both.
I'm worried about the move to wayland to be honest as how this is working is perfect with my xorg setup.
I think part of the issue is documentation, it's really hard to find solutions so you burn hours, days trying to find that one buried post with something that may help, but that post is just a lead, you still have to tweak it and test over and over. This documentation should be on the xrdp website, how to set it up, advanced setups, what files need to be touched, what those changes before/after so users can copy paste the config and get past the innards of linux. I agree that xrdp should work out of the box with sane defaults but is this the responsibility of xrdp for various distros? Maybe not but xrdp team should do what they can to get it to work from a fresh install on common distros. I get a sense that xrdp is just an app the distro's install, doesn't configure and never touches it again till the next release. This is why the documentation section would probably give frustrated users a path forward at trying to get past common issues.
…________________________________
From: dca00 ***@***.***>
Sent: Monday, April 15, 2024 3:21 PM
To: neutrinolabs/xrdp ***@***.***>
Cc: d3al ***@***.***>; Comment ***@***.***>
Subject: Re: [neutrinolabs/xrdp] XRDP session immediately closes after loggin in. (#1412)
To put things in a perspective for you, devs, here's one of MANY threads that shows that almost everything about xrdp is a royal screw-up: https://askubuntu.com/questions/773626/xrdp-login-failed
Configuration files are messed up OOB.
Scripts are messed up OOB.
Permissions are messed up OOB.
Files missing OOB.
There are obscure, undocumented requirements for xrdp credentials that have no basis in UNIX security (login names only in lowercase, passwords only so long/short, no such characters allowed, etc).
And we have to discover all those things ourselves, by way of extensive trial and error.
The totality of these issues sums up in one sentence: xrdp does not work. It is not a working component of Linux. It is an excruciating torture to set it up and manage.
Bottom line is, roll your code back to the point when it worked. No changes that you have made since bring any value for Linux community because you broke the core function of xrdp: its ability to serve remote desktop requests. We do not give a slightest damn about how more secure or sophisticated you might have made it since because you locked us out as a result.
Once it is rolled back, carefully reapply each change you have made since, one at a time, and thoroughly test before you roll out another release. Remember that there is not only Gnome out there but several more mainstream window managers: KDE, XFCE, LXDE, and MATE. It has to work equally well with all of them before it may be considered stable.
Not doing so means the highest degree of disrespect towards your users. We have suffered that for too long. It is about time someone told you directly that your product does not work though it used to.
—
Reply to this email directly, view it on GitHub<#1412 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AORJFJ6TQKM3NLXWKOBMACTY5RHHXAVCNFSM4IXVDHWKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMBVG44TAOJTHE3A>.
You are receiving this because you commented.Message ID: ***@***.***>
|
|
@dca00 - your post is clearly written with some feeling, but it doesn't contain anything meaningful that I can engage with on a technical level. I can only re-iterate what I've said before. I'll say it a different way with more detail. Open source software development projects need meaningful feedback from users. This gives the developers an idea of what features are lacking, and where (often limited) development efforts can be focussed. This project primarily receives user communication from issues and PRs. Some of these are direct, and some are indirect (i.e. via distros). Issues require triage by developers. For us to do this, we need technical information from users, and this needs the users to engage with us. We can't do anything with a description like "it doesn't work", or even "I have this too". We can do something with "I'm running this version of xrdp on this distro with this client and I'm experiencing these symptoms. Here are some logs". If you've opened an issue in the last 6 months you may have seen that we're now trying to gather this information when an issue is opened. The point of this is to minimise the round-trips between the developers and the users. It might seem like a faff to have to enter this, but it's important. Dissimilar issues can often present in similar ways. It's not a perfect process by any means. All of our developers are part time. At any one time, some (or all) of us may be involved in sponsored work on xrdp and that gives us less available time for addressing user issues. We also appreciate that our users' time may be limited too and that makes it sometimes hard for them to engage with us. Some issues may be impossible for us to reproduce, particularly if they're running on non-mainstream hardware (e.g. Raspberry PI), or operating systems which can not obtain a free maintenance licence for (e.g. Solaris). Some issues can't be resolved in ways which our users are happy with. Some issues simply don't get addressed as they may be related to a part of the software that is poorly understood by the existing developers. I see this thread currently has 19 participants. If you're reading this feel free to discuss this post further, or, if you've still got an outstanding issue with xrdp you'd like to solve try raising an issue. I'm still hopeful we can rescue something positive from this thread. However, be warned that further rants will be ignored or deleted. |
|
I've opened this issue due to a problem with using XRDP. |
Hi
I have xrdp installed on both RH 7.6 and 7.7 both are showing the same behavior. Can you please suggest if I have to make any config changes for this to work?
I do not have file on Redhat : /etc/xrdp/startwm.sh
The text was updated successfully, but these errors were encountered: