Freerdp 2.11.4_1: Remote system no longer can access local folder (via Remmina)

[gc-user]

Is this a new report?

Yes

System Info

Void 6.6.17_1 x86_64 GenuineIntel uptodate hold rrmDDDDFFFFFFFF

Package(s) Affected

freerdp-2.11.4_1, libfreerdp-2.11.4_1

Does a report exist for this bug with the project's home (upstream) and/or another distro?

No response

Expected behaviour

When accessing the remote computer using Remmina that system should be able to "see" and access the local folder that is set to be shared.
This worked fine with freerdp 2.10.0_3 and stopped working after updating to v2.11.4_1. The issue goes away when downgrading to freerdp / libfreerdp v2.10.0_3.

This is probably an upstream issue as the template between those two versions wasn't changed in regards to any settings etc., only the version (and rev) number and the hash was changed.

Actual behaviour

After updating freerdp (and libfreerdp) to v2.11.4_1 the remote system no longer is able to "see" (or access) the shared local folder.

Steps to reproduce

1. Update freerdp to 2.11.4_1
2. Connect to the remote system - preferably using Remmina, just to be sure. (Also, the remote system has xrdp (server) running to accept the incoming remmina connection and has xfce as DE, i.e. uses thunar as file manager) - in case that makes a difference.)
3. Try accessing a shared (via Remmina) local folder - or generally see if there is any other folder displayed in ~thinclient_drives other than .clipboard. There should be a folder named _usr_home which is not shown if freerdp v2.11.4_1 is installed, but is shown if freerdp v2.10.0_3 is installed.

[chrysos349]

Can't reproduce.

I successfully connected to my windows box and accessed the local shared folder via remmina.
Connecting via cli, and accessing a shared folder by adding +home-drive argument to xfreerdp (or wlfreerdp) also works.

[gc-user]

I did some more testing. It started with v2.11.0. Some change in there lead to this problem. It doesn't help that debian is too conservative to be compatible with other systems, i.e. the xrdp package on the debian side was 0.9.21 (Bookworm).
After "force-updating" it to 0.9.24 (via trixie port) the issue is now resolved.