You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
Update freerdp to 2.11.4_1
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.)
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.
The text was updated successfully, but these errors were encountered:
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.
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.
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
The text was updated successfully, but these errors were encountered: