Copy/paste is not working on XRDP

Abinayasandhiya commented 6 years ago

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

Abinayasandhiya commented 6 years ago

Can anyone help me on this.

rkantos commented 6 years ago

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.

Abinayasandhiya commented 6 years ago

Hi,

Can we get any help here.

GGGunrunner commented 6 years ago

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...

rkantos commented 6 years ago

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..

godmuzguit7 commented 6 years ago

@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,

Abinayasandhiya commented 6 years ago

Hello,

We could see latest version of XRDP in https://github.com/neutrinolabs/xrdp/releases page. On Bug fixes i could see the latest version fix COPY SLOW issue.

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.

godmuzguit7 commented 6 years ago

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,

rkantos commented 6 years ago

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?

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,

Why would you expect anything different? The isue still open, and thus unresolved...

godmuzguit7 commented 6 years ago

Can you confirm if we use this latest version of XRDP did it resolve COPY/PASTE issue.

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,

Abinayasandhiya commented 6 years ago

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.

Abinayasandhiya commented 6 years ago

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. with new client version the copy/paste issue did not more occur.

Abinayasandhiya commented 6 years ago

For more details:

This resolved our users issues.

Abinayasandhiya commented 5 years ago

Sad:) Issue is solved in Win7 but the same issue on Win10.

yxs commented 5 years ago

In my case, Windows10 to CentOS7.6, the clipboard is working only when connected in Xorg mode.

[root@localhost ~]# rpm -qa | grep xrdp
xrdp-0.9.9-1.el7.x86_64
xorgxrdp-0.2.9-1.el7.x86_64
xrdp-selinux-0.9.9-1.el7.x86_64

cmosguy commented 5 years ago

Same issue here with windows 10 and xrdp 0.9.9

nobias commented 4 years ago

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.

k1moradi commented 4 years ago

same issue here. server: ubuntu 18.04 fully updated, xrdp: 0.9.5-2 client: win 10 session: kde via xorgxrdp

alejandromunozes commented 4 years ago

I have the same issue on Linux:

My server: Raspbian

$ apt show xrdp
Package: xrdp
Version: 0.9.9-1

My 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)

Z0pyrus commented 3 years ago

Same issue here

JohnnySaibot commented 3 years ago

Same issue

HACKE-RC commented 3 years ago

so this issue is not fixed from two years lol

seltsa commented 3 years ago

Still hit this env = [Win 10 => XRDP 0.9.14]

AbinayaSandhiyaM commented 3 years ago

Hi,

After two year again same issue

Any help would be appreciate!!!

matt335672 commented 3 years ago

@AbinayaSandhiyaM

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:-

RDP client + OS
output of xrdp -v
server OS and desktop
method to reproduce the problem.

seltsa commented 3 years ago

@matt335672 1) Client: Windows 10 (mstsc.exe) 2)

xrdp 0.9.14
  A Remote Desktop Protocol Server.
  Copyright (C) 2004-2018 Jay Sorg, Neutrino Labs, and all contributors.
  See https://github.com/neutrinolabs/xrdp for more information.

  Configure options:
      --build=x86_64-redhat-linux-gnu
      --host=x86_64-redhat-linux-gnu
      --program-prefix=
      --disable-dependency-tracking
      --prefix=/usr
      --exec-prefix=/usr
      --bindir=/usr/bin
      --sbindir=/usr/sbin
      --sysconfdir=/etc
      --datadir=/usr/share
      --includedir=/usr/include
      --libdir=/usr/lib64
      --libexecdir=/usr/libexec
      --localstatedir=/var
      --sharedstatedir=/var/lib
      --mandir=/usr/share/man
      --infodir=/usr/share/info
      --enable-fuse
      --enable-pixman
      --enable-painter
      --enable-vsock
      --with-socketdir=/run/xrdp
      build_alias=x86_64-redhat-linux-gnu
      host_alias=x86_64-redhat-linux-gnu
      CFLAGS=-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
      LDFLAGS=-Wl,-z,relro  -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
      PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig

  Compiled with OpenSSL 1.1.1c FIPS  28 May 2019

3) OS: CentOS Linux release 8.1.1911 Desktop: xfce4

it is reported also on Gnome / KDE - so the desktop is not a player here
it is reported also on machines with old Centos7 machines...

4) Steps to reproduce the issue with blocked Copy/Paste

Open laptop => run mstsc.exe => connect to remote Linux machine
Work for few minutes... copy/paste works OK Now the tricky part 🥇
Go drink some coffee while leaving the RDP session connected - i.e. do not close anything.
In few minutes laptop falls asleep
Come back from a coffee break, touche keypad => laptop awakes
You see that the RDP session is disconnected => you simply run reconnect ==> session reopen just fine
You may continue from the same point you have left before the coffee break BUT in about 25% of cases you lose the ability to run Copy/PASTE

Just speculation - this sudden session disconnect of RDP session maybe leave XRDP in a state that it virtually still in the previous connection regarding Copy/Paste

AbinayaSandhiyaM commented 3 years ago

Exactly

Refreshing same session block the copy/paste

matt335672 commented 3 years ago

Thanks both.

I'll build a CentOS 8 machine with xfce and give it a go.

The desktop may not be involved, but the login manager may be.

A couple more questions so I can get a target environment matching yours.

What login manager are you running on C8? Is it gdm3 or something else?
Can you give me the Windows 10 Power and Sleep settings you're using? I've got a rather old Acer laptop permanently plugged in which I can use for this.
Are there any unusual settings in xrdp.ini or sesman.ini?

I may need to come back to you if I can't get this reproduced easily.

matt335672 commented 3 years ago

One other thing - in addition to the info above (which I do need) are you running a screen saver too?

I'll have to use a later version of CentOS than the one you specify, as I suspect a lot of the EPEL stuff simply won't work with one that old and I'll need EPEL for xfce. I'll go for 8.4.2015

seltsa commented 3 years ago

@matt335672

Login Manager: standard CentoOS is gdm ( gdm-3.28.3-22.el8.x86_64 to be exact)
W10 power&sleep settings: Screen turn off after 10 minutes, Sleep = PC goes sleep after 10 minutes 3 xrdp_text.txt sesman_text.txt
Some of Centos8 machines runs with Screen saver off + Lock screen off (like the machine I connect most often) . Some with both enabled. The "Copy/Paste" issue happens in both cases...

matt335672 commented 3 years ago

Great - thanks.

One other question - are there any particular applications which may be running while the session is disconnected?

seltsa commented 3 years ago

@matt335672 nope - nothing special

Windows: outlook + chrome + xrdp client
Centos8: terminal with dozen tabs - mostly idle

seltsa commented 3 years ago

@matt335672 Hi Matt, have you been able to see the problem?

matt335672 commented 3 years ago

hi @seltsa

No - not yet. It's proving difficult to reproduce in my environment here.

matt335672 commented 3 years ago

@seltsa

If you get this again, can you paste the contents of the chansrv log file here?

You'll normally find the log file in ~/.local/share/xrdp/xrdp-chansrv.$DNUM.log where $DNUM is the display number.

I've been playing about with this for a bit. At the moment I've copied text in the Windows side and I can't paste it on the XRDP side. I'm getting this message in the log file:-

[20210810-11:23:54] [ERROR] clipboard_event_selection_request: unknown target text/plain;charset=utf-8

I'm not familiar with the code where this error is being generated, which for reference is

https://github.com/neutrinolabs/xrdp/blob/507305b8fb742a392c8dea46535524cd23a443cd/sesman/chansrv/clipboard.c#L2228-L2229

Exactly what I've done to get here isn't clear to me. I'll carry on looking and see if I can come up with a better way to reproduce this.

matt335672 commented 3 years ago

I think I've found this.

The message above is a red herring. However, what I've managed to do is reproduce the problem, or at least found one cause of it.

Sequences of event is:-

X11 Desktop screen blanks.
Other end goes to sleep at the OS level without sending a FIN packet on the TCP connection.

xrdp doesn't notice straight this away. Until the desktop sends data on the connection, it won't time it out at a TCP level, and it won't send anything with the screen being blank. Consequently the channel to xrdp-chansrv isn't closed, and so xrdp-chansrv doesn't wait for a new connection from xrdp.

When the session is reconnected, a new xrdp process is created. However, it can't connect to chansrv immediately as it's not listening. So it times out after 20 seconds (this is noticeable) and carries on without it. On CentOS you're probably using the Xvnc back-end, and so the connection can happen in parallel with the existing xrdp process. The existing xrdp process will then try to send some data, and will get a FIN and exit. At this point chansrv is ready for a new connection, but it's too late.

Symptoms are:-

20 second delay or thereabouts when the session is resumed.
Clipboard and remote drives are not working.

Log file for chansrv ends like this:-

[20210811-11:18:49] [INFO ] [channel_thread_loop(chansrv.c:1439)] channel_thread_loop: trans_check_wait_objs error resetting
[20210811-11:18:49] [INFO ] [clipboard_deinit(clipboard.c:479)] clipboard_deinit:
[20210811-11:18:49] [INFO ] [scard_deinit(smartcard.c:323)] scard_deinit:

xrdp.log has these lines:-

[20210811-11:05:42] [INFO ] [add_string_to_logwindow(xrdp_wm.c:2057)] connected ok
[20210811-11:05:46] [WARN ] [xrdp_mm_connect_chansrv(xrdp_mm.c:1675)] xrdp_mm_connect_chansrv: connect failed trying again...
[20210811-11:05:51] [WARN ] [xrdp_mm_connect_chansrv(xrdp_mm.c:1675)] xrdp_mm_connect_chansrv: connect failed trying again...
[20210811-11:05:55] [WARN ] [xrdp_mm_connect_chansrv(xrdp_mm.c:1675)] xrdp_mm_connect_chansrv: connect failed trying again...
[20210811-11:05:59] [WARN ] [xrdp_mm_connect_chansrv(xrdp_mm.c:1675)] xrdp_mm_connect_chansrv: connect failed trying again...
[20210811-11:05:59] [ERROR] [xrdp_mm_connect_chansrv(xrdp_mm.c:1681)] xrdp_mm_connect_chansrv: error in trans_connect chan

Disconnecting and reconnecting fixes the clipboard. etc

A workaround you can try is to disable screen blanking. If there's any screen activity at all (e.g. a status bar clock), the first xrdp process will exit much sooner

@seltsa, @AbinayaSandhiyaM (or anyone else). Can you confirm this is what you are seeing?

ThoSap commented 3 years ago

@matt335672 I can confirm exactly the same behavior (same log entries) on Oracle Linux 8.4 (binary compatible to RHEL 8.4, same as CentOS, AlmaLinux, Rocky Linux, etc.)

$ rpm -qa | egrep -i -e "xorg" -e "xrdp" | sort
xorg-x11-drv-fbdev-0.5.0-2.el8.x86_64
xorg-x11-drv-libinput-0.29.0-1.el8.x86_64
xorg-x11-drv-vesa-2.4.0-3.el8.x86_64
xorg-x11-fonts-ISO8859-1-100dpi-7.5-19.el8.noarch
xorg-x11-fonts-Type1-7.5-19.el8.noarch
xorg-x11-font-utils-7.5-40.el8.x86_64
xorg-x11-server-common-1.20.10-1.el8.x86_64
xorg-x11-server-utils-7.7-27.el8.x86_64
xorg-x11-server-Xephyr-1.20.10-1.el8.x86_64
xorg-x11-server-Xorg-1.20.10-1.el8.x86_64
xorg-x11-server-Xwayland-1.20.10-1.el8.x86_64
xorg-x11-utils-7.5-28.el8.x86_64
xorg-x11-xauth-1.0.9-12.el8.x86_64
xorg-x11-xinit-1.3.4-18.el8.x86_64
xorg-x11-xkb-utils-7.7-28.el8.x86_64
xorgxrdp-0.2.16-2.el8.x86_64
xrdp-0.9.16-2.el8.x86_64
xrdp-selinux-0.9.16-2.el8.x86_64

seltsa commented 3 years ago

@matt335672 you are right! it is exactly what we see on connections with clip problem

[20210818-20:39:53] [ERROR] xrdp_mm_connect_chansrv: connect failed trying again...
[20210818-20:39:53] [DEBUG] Closed socket 20 (AF_UNIX)
[20210818-20:39:57] [ERROR] xrdp_mm_connect_chansrv: connect failed trying again...
[20210818-20:39:57] [DEBUG] Closed socket 20 (AF_UNIX)
[20210818-20:40:01] [ERROR] xrdp_mm_connect_chansrv: connect failed trying again...
[20210818-20:40:01] [DEBUG] Closed socket 20 (AF_UNIX)
[20210818-20:40:05] [ERROR] xrdp_mm_connect_chansrv: connect failed trying again...
[20210818-20:40:05] [ERROR] xrdp_mm_connect_chansrv: error in trans_connect chan
[20210818-20:40:05] [DEBUG] Skipping ENC_CURSOR encoding

matt335672 commented 3 years ago

OK - thanks.

Are the workarounds I've suggested any good for you for now?

matt335672 commented 3 years ago

Re-opening this, as a robust fix is still some way away.

ThoSap commented 3 years ago

@matt335672 the screen blanking workarounds you've suggested (tried several different guides from the internet) did not fix the issue.

matt335672 commented 3 years ago

Here's something else you could try.

You can use the TCP keepalive function to prune TCP connections that have dropped out.

First, enable tcp_keepalive in /etc/xrdp/xrdp.ini

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:-

echo 300 | sudo tee /proc/sys/net/ipv4/tcp_keepalive_time  ;# Set keepalive timer to 5 minutes
echo 10 | sudo tee /proc/sys/net/ipv4/tcp_keepalive_intvl ;# 10 seconds between probes
echo 3 | sudo tee /proc/sys/net/ipv4/tcp_keepalive_probes   ;# 3 probes max

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 xrdp.ini. It's a bit of a band-aid, but I think there's a requirement for it at the moment.

aquablast commented 3 years ago

It may be useful: Check that /var/log/xrdp.log contains the row:

[ERROR] Cannot read private key file /etc/xrdp/key.pem: Permission denied

In my cause, errors like this:

[ERROR] xrdp_mm_connect_chansrv: connect failed trying again...
[DEBUG] Closed socket 18 (AF_UNIX)
[ERROR] xrdp_mm_connect_chansrv: connect failed trying again...
[DEBUG] Closed socket 18 (AF_UNIX)
[ERROR] xrdp_mm_connect_chansrv: connect failed trying again...
[DEBUG] Closed socket 18 (AF_UNIX)
[ERROR] xrdp_mm_connect_chansrv: connect failed trying again...
[ERROR] xrdp_mm_connect_chansrv: error in trans_connect chan
[DEBUG] Closed socket 16 (AF_INET6 ::1 port 43264)

ended when i fixed permissions for user xrdp by granting the private key file read rights as root (or with sudo grants):

adduser xrdp ssl-cert

matt335672 commented 3 years ago

Thanks for the contribution @aquablast.

I don't think the certificate permission is relevant. On Debian/Ubuntu however, it's important that the xrdp user can access the chansrv sockets directory. On an 18.04 system I get this:-

ls -ld /var/run/xrdp/sockdir/
drwxrwsrwt 2 xrdp xrdp 40 Sep 18 17:11 /var/run/xrdp/sockdir/

Suitear commented 3 years ago

my remote host is ubuntu 20.04, client is win10. I can't use the clipborad to copy & pasted on either side. I have enable the option in xrdp.ini cliprdr=true and some info in the log file in xrdp-chansrv.13.log

[20210514-14:42:10] [ERROR] X error BadWindow (invalid Window parameter) opcodes 25/0 resource 0x22095b3

[20210514-14:42:10] [ERROR] X error BadWindow (invalid Window parameter) opcodes 18/0 resource 0x22095b3 [20210514-14:42:10] [ERROR] X error BadWindow (invalid Window parameter) opcodes 25/0 resource 0x22095b3 [20210514-14:42:13] [ERROR] clipboard_event_selection_request: unknown target text/plain;charset=utf-8 [20210514-14:42:15] [ERROR] clipboard_event_selection_request: unknown target COMPOUND_TEXT [20210514-14:42:16] [ERROR] clipboard_event_selection_request: unknown target text/plain;charset=utf-8 [20210514-14:42:26] [ERROR] clipboard_event_selection_request: unknown target COMPOUND_TEXT [20210514-14:42:26] [ERROR] clipboard_event_selection_request: unknown target COMPOUND_TEXT [20210514-14:42:26] [ERROR] clipboard_event_selection_request: unknown target COMPOUND_TEXT [20210514-14:42:26] [ERROR] clipboard_event_selection_request: unknown target COMPOUND_TEXT [20210514-14:42:27] [ERROR] clipboard_event_selection_request: unknown target COMPOUND_TEXT [20210514-14:42:28] [ERROR] clipboard_event_selection_request: unknown target COMPOUND_TEXT [20210514-14:42:28] [ERROR] clipboard_event_selection_request: unknown target COMPOUND_TEXT [20210514-14:42:28] [ERROR] X error BadWindow (invalid Window parameter) opcodes 18/0 resource 0x2209e9f [20210514-14:42:28] [ERROR] X error BadWindow (invalid Window parameter) opcodes 25/0 resource 0x2209e9f

[20210916-09:14:28] [CORE ] main: app started pid 17268(0x00004374) [20210916-09:14:28] [INFO ] main: DISPLAY env var set to :10.0 [20210916-09:14:28] [INFO ] main: using DISPLAY 10 [20210916-09:14:28] [INFO ] channel_thread_loop: thread start [20210916-09:14:28] [INFO ] Socket 12: AF_UNIX connection received [20210916-09:48:24] [INFO ] channel_thread_loop: trans_check_wait_objs error resetting

the process info :

root 1131 1 0 9月16 ? 00:00:00 /usr/sbin/xrdp-sesman xrdp 1158 1 0 9月16 ? 00:00:00 /usr/sbin/xrdp root 17249 1131 0 9月16 ? 00:00:00 /usr/sbin/xrdp-sesman azureuser 17254 17249 0 9月16 ? 00:00:00 /bin/bash /etc/xrdp/startwm.sh azuresuer 17255 17249 10 9月16 ? 13:07:47 /usr/lib/xorg/Xorg :10 -auth .Xauthority -config xrdp/xorg.conf -noreset -nolisten tcp -logfile .xorgxrdp.%s.log azureuser 17268 17249 0 9月16 ? 00:00:00 [xrdp-chansrv] xrdp 876299 1158 1 13:00 ? 00:00:14 /usr/sbin/xrdp

Please help me out. It haunted me for months.

matt335672 commented 3 years ago

@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?

Suitear commented 3 years ago

@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... the current values on my host are as follows:

cat /proc/sys/net/ipv4/tcp_keepalive_time 7200 cat /proc/sys/net/ipv4/tcp_keepalive_intvl 75 cat /proc/sys/net/ipv4/tcp_keepalive_probes 9

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...

matt335672 commented 3 years ago

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 (/var/run/xrdp/sockdir for Debian/Ubuntu) and see if the chansrv process for your display is listening for new connections.

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 /var/run/xrdp/sockdir/xrdp_chansrv_socket_10. This only appears when chansrv is started on a display (:10 in this instance), but isn't connected to xrdp. When a session is fully connected this file disappears.

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.

Suitear commented 3 years ago

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. their permission details as follows.

azureuser@Host-Ubuntu:~/thinclient_drives/.clipboard$ ls -alsh 4.0K drwxr-xr-x 2 azureuser azureuser 4.0K Sep 24 11:07 . 4.0K drwxr-xr-x 3 root root 4.0K Sep 24 11:07 ..

Now the output of sudo systemctl status xrdp is as follows.

Sep 24 14:13:55 Host-Ubuntu xrdp[1578]: (1578)(1346981)[DEBUG] xrdp_wm_log_msg: connecting to sesman ip 127.0.0.1 port 6741 Sep 24 14:13:55 Host-Ubuntu xrdp[1578]: (1578)(1346981)[INFO ] xrdp_wm_log_msg: sesman connect ok Sep 24 14:13:55 Host-Ubuntu xrdp[1578]: (1578)(1346981)[DEBUG] xrdp_wm_log_msg: sending login info to session manager, please wait... Sep 24 14:13:55 Host-Ubuntu xrdp[1578]: (1578)(1346981)[DEBUG] return value from xrdp_mm_connect 0 Sep 24 14:13:55 Host-Ubuntu xrdp[1578]: (1578)(1346981)[INFO ] xrdp_wm_log_msg: login successful for display 10 Sep 24 14:13:55 Host-Ubuntu xrdp[1578]: (1578)(1346981)[DEBUG] xrdp_wm_log_msg: started connecting Sep 24 14:13:55 Host-Ubuntu xrdp[1578]: (1578)(1346981)[INFO ] lib_mod_log_peer: xrdp_pid=1578 connected to X11rdp_pid=1346981 X11rdp_ui> Sep 24 14:13:55 Host-Ubuntu xrdp[1578]: (1578)(1346981)[DEBUG] xrdp_wm_log_msg: connected ok Sep 24 14:13:56 Host-Ubuntu xrdp[1578]: (1578)(1346981)[DEBUG] xrdp_mm_connect_chansrv: chansrv connect successful Sep 24 14:13:56 Host-Ubuntu xrdp[1578]: (1578)(1346981)[DEBUG] Closed socket 18 (AF_INET6 ::1 port 41186)

matt335672 commented 3 years ago

Great - glad you got it working.

neutrinolabs / xrdp

Copy/paste is not working on XRDP #1188