Xrdp file transfer problem

[alemrsrl]

Hi, i've a problem with xrdp and ubuntu 18.04
after installing and configuring xrdp on ubuntu i try to connect to my remote host with drive redirection enabled and on my remote desktop i see the thinclient_drive folder and i can navigate into folder structure.
But if i try to copy any file, my home dir entirely stuck and i'm not be able to navigate to i with nautilus and shell.
to resolve the problem i must reboot the remote linux system or use the command fusermount -z -u /home/user/thinclient_drives and try to reconnect.

this problem does not occur if i try to copy the file from my local pc (ctrl+c) and the go to remote host and past it to any folder (ctrl+v).

i've tried xrdp version 0.9.5 0.9.8 0.9.11 builded from source or via apt on ubuntu 18.04 and debian 9 (always taking care to use clean operating systems installations)

my local pc is windows 10 and i've used the default windows rdp client

i' ve made some test with freerdp client on windows and in this case i've this problem:
i see the thinclient_drives folder and i'm be able to navigate into and i can copy file from this folder to my home dir but if i close the thinclient_drives folder and i reopen it this is empy and i've to close and reopen rdp session to see it.

[matt335672]

Hi @alemrsrl

Can I ask you a few questions regarding this, to try to narrow down where the problem is?

1. When the copy locks up, are you trying to copy Windows -> Linux, Linux -> Windows or Windows -> Windows?
2. Does the same thing happen when copying using the cp command from the command line?
3. The file transfer code is part of the xrdp-chansrv program. When the copy locks up, what does the output of the command ps -ef | grep xrdp-chansrv show?

Thanks

[alemrsrl]

1 Windows -> Linux (from thinclient_drives to /home/user/folder)
2 the problem not happen if i copy from command line
3 ps -ef | grep xrdp-chansrv
mr 1496 1486 0 14:29 ? 00:00:00 /usr/local/sbin/xrdp-chansrv
mr 2314 2240 0 14:35 pts/0 00:00:00 grep --color=auto xrdp-chansrv

[matt335672]

Thanks - that's useful.

From that it looks like:-

1. the graphical environment is doing something differently from the command line in terms of the calls it's making.
2. xrdp-chansrv is not crashing.

By default, xrdp-chansrv writes a log file in ~/.local/share/xrdp/xrdp-chansrv.%d.log (where '%d' is replaced with the display number).

A couple more questions:-

1. What is the version of Ubuntu 18.04? Are you using the latest (i.e. 18.04.3)?
2. Which desktop environment are you installing in Ubuntu?
3. Can you have a look for the log file? If you can find it cause the problem to happen and then report the contents of the log file?

[misu68]

I've seen that the problem might be related to the disk free space. When looking at the properties of the mapped drive, you see it has "0 bytes available". Some tools work as they don't care about the remaining disk space, some check the capacity first and fail.

So the question here is why xrdp reports the mapped drive as "0 bytes available"?

[matt335672]

Hi @musu68 - thanks for the thought.

The free space may be the case here, but I don't think it's the whole story. If it was, I'd expect the desktop environment to report an error like 'no space available' and simply not do the copy. This is somewhat different in that it's a hang-up, and to me it sounds more like a bug in the xrdp implementation of the copy.

I'm still waiting for @alemrsrl to clarify his environment. When he does, I'm happy to try to reproduce the problem, but I'll bear the disk space info in mind.

Are you seeing this problem too? If so, are you using the latest version of Ubuntu 18.04, and are you using GNOME?

[metalefty]

@matt335672 BTW, thank you for your continuous contribution on drive redirection feature.

[alemrsrl]

Ubuntu 18.04.3 LTS
GNU/Linux 5.0.0-32-generic x86_64
i've made some test and seems that the problem happen with gnome 3 MATE and Kde plasma
this is the output of ~/.local/share/xrdp/xrdp-chansrv.%d.log

[20191022-12:23:40] [CORE ] main: app started pid 2629(0x00000a45)
[20191022-12:23:40] [INFO ] main: DISPLAY env var set to :11.0
[20191022-12:23:41] [INFO ] main: using DISPLAY 11
[20191022-12:23:41] [INFO ] channel_thread_loop: thread start
[20191022-12:23:41] [INFO ] Socket 12: AF_UNIX connection received
[20191022-12:23:41] [INFO ] term_signal_handler: got signal 15
[20191022-12:23:41] [INFO ] xserver_fatal_handler: entered.......

if i look at properties of thinclient_drives folder i correctly see the space used

[matt335672]

That's useful - thanks.

I'll try to reproduce this with GNOME when I get a bit of time later in the week.

If you can tell me a bit about the kinds of files you're trying to copy, and how often this happens it might be useful. Does it always happen on all files? Or does it only happen on certain files and directories? If it's certain files only, how big are they according to ls -l?

[alemrsrl]

simple txt files from 5Kb to 1000kb for example (every files every dimension) folder copy always crash

[misu68]

@matt335672 I can reproduce this on latest MINT running Mate.
However, what makes me put this in relation to the "no disk free" problem is, that I re-export the FUSE-mounted fs to a virtualbox running windows. The properties bring up "0 bytes free" and windows explorer stops the copy procedure for that reason while other programs work (e.g. old DOS copy command). I have seen that the FUSE statfs is not implemented, so df doesn't work either. It is just a stomach feeling, though...
I know it is probably not possible to have values here as all drives are mounted as one FUSE, but it might help to have a dummy statfs giving back just a "high value". I know it is a quirk, though. :)

Output from df:
Filesystem 1K-blocks Used Available Use% Mounted on
xrdp-chansrv 0 0 0 - /home/remote/thinclient_drives

[matt335672]

Hi @alemrsrl - I've just spent a couple of hours on this, and I'm not able to reproduce your problem, so I'm obviously not doing something you are, or something is different in your environment.

I've set up a VM with 2GB of RAM and installed Ubuntu 18.04 LTS with all the updates. The command lsb_release -d on my system returns Description: Ubuntu 18.04.3 LTS. My locale is set to en_GB.UTF-8.

I've installed xrdp 0.9.5 from the repositories, as that's easy to do (although this version has significant limitations when it come to drive redirection).

I started with an empty user account on both the Linux and Windows sides, and logged in to the VM from a Windows 10 Home PC. I selected the Xvnc backend.

I then copied two lots of text files as follows:-

1. Set up a file browser window with /usr/share/doc and a file browser window with ~/thinclient_drives/c:/Users/<user>/Documents. Dragged and dropped the git folder from the first window to the other. I had to skip some symlinks to do this, when prompted.
2. Changed the first browser window from /usr/share/doc to ~/Documents and copied the git folder back to the Linux side, again using drag and drop.

Both copies were fine, and that's a lot of files.

My nautilus file windows are set up to show file details.

Can you tell from my description what you might be doing differently from me?

Thanks.

[alemrsrl]

my scenario is:
physical host: Dell r320
HyperVisor: VMWARE Esxi 6.7

Virtual machine properties:
Disk Thin provisioned 100 Gb
4 vCPU
16GB Ram

Guest OS:
Ubuntu 18.04.3 LTS. My locale is set to it_IT.UTF-8

Xrdp
v 0.9.5
auto installed form apt

Rdp client:
MTSC

Access method; xorg (because i must use 2 monitors)

i've made a lot of test with every distro and e desktop env. and
the only scenario that work is:
physical host: Dell r320
HyperVisor: VMWARE Esxi 6.7

Virtual machine properties:
Disk Thin provisioned 100 Gb
4 vCPU
16GB Ram

Guest OS:
Linux Mint 19.2 Tina with cinnamon and nemo file manager

Xrdp
v 0.9.5
auto installed form apt

Rdp client:
MTSC

Access method; xorg (because i must use 2 monitors)

i'm very confused about it

[matt335672]

Thanks for the info. I'll have a play around with the xorg backend and your locale and see if I can get a hang.

Can I ask you to try temporarily renaming your .bashrc to see if there's anything in there which makes a difference?

Can you also specify what sort of drive you are copying from on the Windows side. I'm assuming the C: drive at the moment, but you might be using something else. If you are using something else, can you make the hang happen when using the C: drive?

If you can find a standard Windows file on the C: drive which causes the hang when you copy it to the Linux side I can concentrate on that file.

[matt335672]

I'm still not able to reproduce this.

I'm not entirely clear whether xrdp-chansrv is crashing or not. The initial evidence is that it isn't, but your log file would tend to suggest that it is.

I suggest we enable coredumps on the machine, to see whether we can get a useful dump.

To enable coredumps, edit /etc/security/limits.conf and replace this line:-

#*               soft    core            0

with:-

*               -    core            unlimited

Then reboot to be on the safe side. When you log in, check that the output of ulimit -c is unlimited.

When the problem happens, we may then get a file called core.<pid> in the home directory of the UNIX user. If that belongs to xrdp-chansrv we can examine it to get more of an idea as to exactly what is happening here.

[matt335672]

Hi @alemrsrl
If you're still interested in a resolution to this problem, can I suggest you try the recently-released XRDP 0.9.12? I've made some improvements to the redirect code, and in the process I fixed at least one memory management problem which could potentially be implicated in this.
Thanks

[fefux]

Hi everybody,
I reproduce that issue with xrdp 0.9.13 (built from source) and VirtualBox 6.1.6 when you install Guest Additions on the VM (Ubuntu 16.04.6) and enable drag and drop support. After deleted them, the issue disappears (at least for me) and clipboard works again.
I think there is some incompatibility with fuse and drag and drop support in VirtualBox