Copy/paste is not working on XRDP #1188
Comments
|
Can anyone help me on this. |
|
I think I also have experienced this lately on Ubuntu 18.04 (Xrdp version 0.9.5) I't seems it usually occurs when a session goes in to the "locked" screen or a screensaver. When I reconnect with the desktop session not yet timed out, clipboard works normally. Is this something that could be fixed in xrdp ? Maybe Windows rdp client limitation? Edit: The problem also occurs when connected to a xrdp session and the desktop timeouts to a screensaver... I'm beginning to think there is something that can be changed easily to fix this. |
|
Hi, Can we get any help here. |
metalefty
added
the
question or troubleshoot
|
Having the same issue.... I have xrdp on Raspberry Raspbian and connect to it from Windows (default mstsc client). Pasting works from Windows to Pi, but not backwards... |
Please attach at least your version information. I have had copy-paste working both ways with XRDP for at least since the last major issues was fixed. Now there just seems to be something happening with either the Windows client or XRDP that disables copy-paste one way or both ways when the connection has gone in to (sleep?) mode.. |
|
@rkantos I have the same issue as you described, but in Centos 7. As soon as the lock screen comes up, it is not possible to copy/paste between Windows 7 and my Centos desktop without first reconnecting via RDP. Have you already found something? Thanks, |
|
Hello, We could see latest version of XRDP in https://github.com/neutrinolabs/xrdp/releases page. we are having COPY/PASTE issue (XRDP version is 0.9.6) from windows to RDP server and still issue is persist. Can you confirm if we use this latest version of XRDP did it resolve COPY/PASTE issue. Please provide some details here also this ticket seems opened like last 15 days. |
|
Hello, the issue is not resolved for the moment, even with the new version. The issue is still there when the session is locked, the clipboard doesn't work. We have to reconnect in order to be able to paste data in the password field. Thanks for your help, |
|
Could we get a new title for this? Someone can probably come up with a more accurate one, but it seems the issue occurs after xrdp has gone idle. Thus I suggest “Copy paste not working after session has been idle or resumed”. Anyobody got an idea for debugging?
Why would you expect anything different? The isue still open, and thus unresolved... |
I expected the new version to possibly resolve the issue, but it's not the case. I would expect something different because nobody answered to @Abinayasandhiya about the new version. Thanks, |
|
Is there any possible way to fix this copy/paste issue between Linux RDP server and windows. This is absolutely important issue which is need to be fix earlier, otherwise xrdp almost not usable. |
|
Hello All, Finally copy/paste issue has been fixed when try to access our XRDP server using updated RDP client. Update RDP client will have option like "Detect connection quality automatically" which will detect automatic quality for our connection. Now my RDP client is updated to version 6.3.9600.16415. |
|
For more details:
This resolved our users issues. |
|
Sad:) Issue is solved in Win7 but the same issue on Win10. |
|
In my case, Windows10 to CentOS7.6, the clipboard is working only when connected in Xorg mode. |
|
Same issue here with windows 10 and xrdp 0.9.9 |
|
I still consistently have this issue when connecting from the Microsoft Remote Desktop app (10.3.8 (1747)) on MacOS 10.15.4 to xorg on Ubuntu 19.04 LTS (xrdp 0.9.9-1, xorgxrdp 1:0.2.9-1): Clipboards on client and server simply do not get synced at all. All my software versions are pretty up-to-date. If I could get some hints on how to debug this I would be happy to provide more specific info. |
|
same issue here. |
|
I have the same issue on Linux: My server: Raspbian $ apt show xrdp
Package: xrdp
Version: 0.9.9-1My client: Debian $ apt show krdc
Package: krdc
Version: 4:18.04.1-1+b1
Priority: optional
Section: net
Source: krdc (4:18.04.1-1) |
|
Same issue here |
|
Same issue |
|
so this issue is not fixed from two years lol |
|
Still hit this env = [Win 10 => XRDP 0.9.14] |
|
Hi, After two year again same issue Any help would be appreciate!!! |
|
I've just tried to reproduce this based on the information in the thread above, and I've failed to do so. I've used CentOS 8 with GNOME, xrdp 0.9.16 from RPM and the Windows 10 mstsc.exe client. Cut-and-paste for text works both ways. I can lock the screen and then unlock it and cut-and-paste still works. If I wait for the screen lock to start automatically, everything still seems OK. Are you able to reproduce this? If so, please post:-
|
|
OK - thanks. Are the workarounds I've suggested any good for you for now? |
|
Re-opening this, as a robust fix is still some way away. |
|
@matt335672 the screen blanking workarounds you've suggested (tried several different guides from the internet) did not fix the issue. |
|
Here's something else you could try. You can use the TCP keepalive function to prune TCP connections that have dropped out. First, enable This will probe for dead connections when the connections have been dead a couple of hours. That's probably too long to wait, so you can change some values like this. These are GLOBAL, so this will affect all TCP connections to the machine with keepalive enabled:- That way, after 5 minutes and 30 seconds the old connection will be killed and you should be able to reconnect. More info in tcp(7) and the Linux TCP keepalive HOWTO If that works for you, we can look at getting these values configurable in |
|
It may be useful: Check that In my cause, errors like this: ended when i fixed permissions for user |
|
Thanks for the contribution @aquablast. I don't think the certificate permission is relevant. On Debian/Ubuntu however, it's important that the |
|
my remote host is ubuntu 20.04, client is win10. I can't use the clipborad to copy & pasted on either side.
the process info :
Please help me out. It haunted me for months. |
|
@moerfutin - it looks very much like you've got the same problem as everyone else. Can you try the actions in this post and see if it helps? |
Thanks, but I don't think it's gonna help...
And on my another Debian host, I installed the xrdp in default way, and its clipborad is normal. Sames values as above. So I don't think it's TCP issue... |
|
The problem above is caused by a client going away without sending a TCP FIN. This can happen either because the client hibernates, or because a firewall either drops the connection with no traffic, or is simply restarted and loses state information. So it's not necessarily anything to do with how the host is configured, but rather how the individual elements of the whole system (i.e. client(s), network, server and user(s)) are interacting. Another way to see whether you're affected by this is to look in the socksdir for your system ( On a Ubuntu VM I've got here, I have the following for a session on DISPLAY=:10 where chansrv is connected and everything is working:- $ ls -l /var/run/xrdp/sockdir/ total 0 srw-rw---- 1 testuser xrdp 0 Sep 22 10:27 xrdpapi_10 srw-rw---- 1 testuser xrdp 0 Sep 22 10:27 xrdp_chansrv_audio_in_socket_10 srw-rw---- 1 testuser xrdp 0 Sep 22 10:27 xrdp_chansrv_audio_out_socket_10 srwxr-xr-x 1 testuser xrdp 0 Sep 22 10:27 xrdp_disconnect_display_10 srw-rw---- 1 testuser xrdp 0 Sep 22 10:27 xrdp_display_10 When chansrv is disconnected, I get the following:- $ ls -l /var/run/xrdp/sockdir/ total 0 srw-rw---- 1 testuser xrdp 0 Sep 22 10:27 xrdpapi_10 srw-rw---- 1 testuser xrdp 0 Sep 22 10:29 xrdp_chansrv_socket_10 srwxr-xr-x 1 testuser xrdp 0 Sep 22 10:27 xrdp_disconnect_display_10 srw-rw---- 1 testuser xrdp 0 Sep 22 10:27 xrdp_display_10 The important line above is You can use the presence of this file to tell you whether your problem is the same as the issue being discussed here, or not. |
|
Thanks, I think I found my own solution. It seemed there is not the necessary folder in my home directory. So I manually mkdir this folder thinclient_drives and its subfolder .clipboard , and restart xrdp service, then it works like a charm.
Now the output of sudo systemctl status xrdp is as follows.
|
|
Great - glad you got it working. |
|
still? using mremoteng client |
|
@lonbluster - if you're referring to the problem discussed above where a FIN has been lost for some reason and a reconnect is not successful, then it's still not fixed. You'll need to use the keepalive workarounds for it. |
Been struggling for a while with this (same symptoms. 20s delay when the session is resumed, clipboard not working, plus log file looks like that except it also has "[ERROR] clipboard_event_selection_request: unknown target text/plain;charset=utf-8" on it) and xrdp.log looks the same as well. Tried adding those settings from terminal. Also tried adding them to /etc/sysctl.conf Unfortunately, the issue keeps happening. The only thing I can do is setting KillDisconnected to true on sesman.ini, but that, of course, closes the session completely which is something I don't want at all. To test it, I'm killing the process of the RDP software I'm using on my main machine (MobaXterm), waiting 6min and then trying to reconnect again. But even when hitting "disconnect" it still happens. Any clues? Logs here Chansrv log
Xrdp.log
Xrdp-sesman.log
When hitting "disconnect" manually I also see stuff like this.
|
|
There are a couple of possible reasons for this:-
The correct solution is to get sesman to close existing the connection to a session when a new connection to the same session is made. I'm working on an architecture which will allow this to happen (#1961), but we're still a little way off I'm afraid. |
I can replicate the problem by putting my Ubuntu 22.04 machine in suspend while connected with Windows 11. After reconnecting clipboard stopped working. Only a Linux reboot brought back the clipboard |
|
Hi, PRETTY_NAME="Parrot OS 5.3 (Electro Ara)" xrdp 0.9.12 by default I have both the "thinclient_drives" folder and the ".clipboard" folder with the relative permissions do you know how i can fix it? |
This fixed my issue connecting from windows 10 to an Ubuntu 20.04. |
|
Found workaround on this when working on xrdp connection to docker container with Ubuntu desktop. This my one-liner:
(just kills xrdp-chansrv + start with logging to /var/log/chansrv.log) Configured as pre-command and looks like working (at least copy/paste) |
|
Proposed workarounds seems not working in my case. I have found this workaround which quickly cleans up fake TCP connections: In this way, if you reconnect to RDP server a few seconds after the connection drop, copy/paste is working. You can tune it based on you needs. |
|
For me the copy&paste is simply not working, ever. Even after I reboot ubuntu 20,.04 and make a new connection. Doesn't work. I indeed had a missing .clipboard folder but adding it only changed that instead of getting an error connecting to chanserver it now is successful but copy&paste both direction (win10 to ubuntu 20.04) still doesn't work |
|
Using: Ubuntu 24.04.1 LTS Could you tell me what I did wrong please ? /home/USERNAME/thinclient_drives/.clipboard /etc/xrdp/xrdp.ini Client is Windows 10 Log from a User that Login and try copy & paste cat .xorgxrdp.12.log |
|
For me upgrading from Ubuntu 20.04 to 22.04 fixed the issue without any other change. |
it works |
and others
Hi,
We are using XRDP to connect our RedHat6 and RedHat7 machine.
Sometimes we could face sudden issue in XRDP that copy/paste is not working form window to XRDP server.
Please find below server and XRDP details:
[root@GUI ~]$ cat /etc/redhat-release
Red Hat Enterprise Linux Server release 7.4 (Maipo)
[root@GUI ~]$ rpm -qa | grep xrdp
xorgxrdp-0.2.5-3.el7.x86_64
xrdp-debuginfo-0.9.5-1.el7.x86_64
xrdp-devel-0.9.5-1.el7.x86_64
xrdp-0.9.5-2.el7.x86_64
Anyone please help me to fix this issue.
Regards,
Abinaya
The text was updated successfully, but these errors were encountered: