Can't move / copy files in dolphin to redirected drives in KDE

[vscfreire]

xrdp version

0.10.3

Detailed xrdp version, build options

Operating system & version

Rocky Linux 9.6

Installation method

dnf / apt / zypper / pkg / etc

Which backend do you use?

xorgxrdp

What desktop environment do you use?

KDE

Environment xrdp running on

VM

What's your client?

mstsc.exe (Windows 11)

Area(s) with issue?

File transfer / drive redirection

Steps to reproduce

1 - Create an example .txt file (test.txt) on your home directory
2 - Open dolphin and copy the file
3 - Navigate to a redirected folder (such as ~/thinclient_drives/C:/Users//Desktop/)
4 - Attempt to paste the file

✔️ Expected Behavior

The file should be copied to the desktop

❌ Actual Behavior

The file isn't copied to the desktop and an error appears "There is not enough space on the disk to write"

Anything else?

Hi,

When copying files from a KDE (Plasma 5.27.12) xrdp session using Dolphin to the Windows desktop over xrdp drive redirection, Dolphin always reports:

There is not enough space on the disk to write

Using either "cp" or using the "Save as" file dialogs works as expected.

I'm aware of a similar issue #3300, which was closed by PR #3304. From what I've gathered this fix is included in the version I am using. Running df -h as mentioned in that PR shows that the fix is working as intended:

df -h ~/thinclient_drives/  ~/thinclient_drives/C\:/
Filesystem      Size  Used Avail Use% Mounted on
xrdp-chansrv    0.0K  0.0K  0.0K    - /home/<user>/thinclient_drives
xrdp-chansrv    953G  782G  171G  83% /home/<user>/thinclient_drives

In a comment in PR #3304 it suggests that the fix was tested in dolphin and that it was working as expected, which made me want to take a close look at KIO's source code. Inspecting the code I found out the function responsible for getting the directory's available space when a copy is performed (https://invent.kde.org/frameworks/kio/-/blob/v5.116.0/src/ioslaves/file/file.cpp#:~:text=void%20FileProtocol%3A%3AfileSystemFreeSpace(const%20QUrl%20%26url):

The problem here is in the use of QT's QStorageInfo, since it performs a statfs on the root path (~/thinclient_drives) of the directory instead of the actual directory (https://github.com/qt/qtbase/blob/v5.15.9-lts-lgpl/src/corelib/io/qstorageinfo_unix.cpp#L831):

Therefore it always returns 0 available space for my directories. Replacing QStorageInfo with statfs on KIO's function solves the problem.

I am undecided whether this is an xrdp issue or a KIO issue, since KIO's approach works for traditional file systems as the mountpoint should always have space.

I would like to know if you encounter similar problems and if you have a suggestion on how to approach this issue.

Thanks.

[matt335672]

@vscfreire - as ever, thank you for a detailed and interesting post.

At the time we merged #3304, Dolphin was simply checking the free space in the target directory, and all was well. I've found this PR which may well be responsible for the change in behaviour.

When I added #3304, I was aware there was a potential problem in that POSIX implicitly assumes that all the files sharing the same f_fsid value from statvfs share all the other values.

The current implementation of the redirector only has one device mounted, so all files in the redirected area share the same f_fsid value. However, the free space values can change depending where in the filesystem the user is resided. I do not think this is POSIX-compliant, although I can find no explicit statement in POSIX that this is not permitted.

There are a number of solutions to this problem. In order of increasing complexity:

1. Add a dummy large free space value to the root filesystem so that KIO simply sees a lot of space available.
2. For a root space query, issue queries for all the sub filesystems and add up the responses.
3. Re-implement the redirector so that each drive gets its own mountpoint (and hence f_fsid value).

Here are some thoughts:

1. is pretty simple. We can add a configuration value to sesman.ini
2. isn't a great solution, as the resulting value isn't useful for anything and I can't think it offers anything over 1)
3. we have all the code in place for 3), but it's more complex to get right.

What are your thoughts @vscfreire ?

[vscfreire]

Hi,

Thanks for the quick response and for outlining the possible solutions.

I agree that option 1 is the simplest and would definitely fix the problem. My only concern is what happens if a user tries to copy a file larger than the actual available space in the target folder. I think this limitation also applies to option 2, which doesn’t seem to provide much benefit over option 1.

Option 3 seems to be the most technically correct approach, but I wonder if it could cause compatibility issues with existing clients (probably not, but I think it should be thought about). I would be happy to help you with coding this up.

Thanks.

[matt335672]

We'll forget option 2 then.

A possible change with option 3 is that some desktops will now display a separate desktop icon for each drive, rather than a global thinclient_drives option. I can't think of any other drawbacks at the moment.

As far as coding goes, it's should be a relatively straightforward task as it's more about reorganising what we have. I've got a bit of time away from the desktop coming up, so leave it with me for a week or two, and I'll see how it goes.

[matt335672]

I've had a good look at this, and option 3 requires the architecture being changed significantly.

The problem is, to change the st_dev field reported by the stat() system call requires another FUSE file system to be mounted on the existing one.

The biggest problem is that when working with the lower FUSE mount, the kernel will at times require information about the upper mount, and so will call back into chansrv when it is unable to process the request. Because chansrv is single-threaded, this results in a deadlock and an unkillable chansrv process.

Another smaller problem is that root permission is needed to get the FUSE-on-FUSE mount to work, and this needs user_allow_other to be set in /etc/fuse.conf.

I think there are two possible solutions:

1. Move the redirected drives to a completely separate directory, or (alternatively) move the .clipboard mount elsewhere.
2. Make chansrv multi-threaded.

I think 1) is probably the way to proceed, as it's simpler, and we could make this backward-compatible with the existing system.

Thoughts on this @vscfreire , @metalefty ?

[vscfreire]

Hi,

I agree that option 1) is the right way forward. However, I would add that thinclient_drives should remain as a directory that contains the redirected drives (to remain compatible with tools used with previous versions). For .clipboard, I suggest renaming the thinclient_drives mount point to something along the lines of thinclient_system_mounts (or even a hidden directory like ".thinclient_system").

FYI, I've implemented the temporary solution of adding dummy space and I am now able to copy and move files through dolphin to my redirected drives.

Thanks.

[matt335672]

I like that suggestion, as the .clipboard is not really useful for the user, but the drives are.

I'm considering implementing dummy space for v0.10.x, just to work around this problem. We have enough KDE users to make it worth doing I think. I can't see an easy way to automate this, so it will have to be a config value for now.

[matt335672]

I started looking at option 1 (implement dummy space at the root), but even that is complicated to do properly.

There seems to be no good way of providing a sensible default for the free space value, so a config value would be required.

In general we want system admins to specify chansrv config values, but this value would seem to be an exception as it's more user-specific. So I don't think it should go in /etc/xrdp/sesman.ini, but there's currently nowhere else to put it.

We could add a user-specific chansrv.ini in addition to the global /etc/xrdp/sesman.ini. At the moment we've only got this setting to go in it though. @vscfreire, @metalefty - can you think of any other advantages to having some user-specific chansrv config values available?

[vscfreire]

Hi,

I agree with you that there really is no sensible value. However, I do not think providing a configuration for this will make it have any more sense. Ideally what the user wants is a folder whose reported size and available size are the same as the folder on their personal computer. With this solution in mind, the user would only be able to solve that if they define those exact values in the config file, which would need constant updating. From this perspective, all configured values run into this same problem. Moreover, if a user has a redirected C: drive with 1TB free and a D: drive with only 1MB free, there’s simply no single sensible value that could represent both at the same time.

Taking a step back, the problem we are trying to solve is that the user can't move files in dolphin since the mount point's folder reports 0B size and 0B available size. We can't simply increase it to 10MB size and 10MB available size since then the user wouldn't be able to move files that exceed 10MB in size. Therefore, what I propose is just defining a big enough value so that we won't run into this problem, for example 1PiB. This way, the user should be able to move all desired files to the redirected folders through dolphin.

Thanks.

[matt335672]

Thanks for that @vscfreire. You're quite right - no config should be required apart from possibly enabling this option at a global level. I'll have a look at implementing that.