Freerdp: Share access error

[xsmile]

Describe the bug
Accessing a shared home folder or shared directories inside the home folder does not work.

To Reproduce

1. Run the command listed below to connect
2. Open the shared drive in Explorer
3. Open the home folder

Expected behavior
The home folder is accessible.

Screenshots
Trying to access the home folder:

Trying to access another folder with insufficient permissions:

Application details

• Version of FreeRDP: 2.0.0-rc3
• Command line used: xfreerdp /v:<IP> /u:<USER> /drive:shared,/home
• Output of /buildconfig:

This is FreeRDP version 2.0.0-rc3 (n/a)
Build configuration: BUILD_TESTING=OFF BUILTIN_CHANNELS=ON HAVE_AIO_H=1 HAVE_EXECINFO_H=1 HAVE_FCNTL_H=1 HAVE_INTTYPES_H=1 HAVE_JOURNALD_H=TRUE HAVE_MATH_C99_LONG_DOUBLE=1 HAVE_POLL_H=1 HAVE_PTHREAD_MUTEX_TIMEDLOCK=ON HAVE_PTHREAD_MUTEX_TIMEDLOCK_LIB=1 HAVE_PTHREAD_MUTEX_TIMEDLOCK_SYMBOL= HAVE_SYSLOG_H=1 HAVE_SYS_EVENTFD_H=1 HAVE_SYS_FILIO_H= HAVE_SYS_MODEM_H= HAVE_SYS_SELECT_H=1 HAVE_SYS_SOCKIO_H= HAVE_SYS_STRTIO_H= HAVE_SYS_TIMERFD_H=1 HAVE_TM_GMTOFF=1 HAVE_UNISTD_H=1 HAVE_XI_TOUCH_CLASS=1 WITH_ALSA=ON WITH_CCACHE=ON WITH_CHANNELS=ON WITH_CLIENT=ON WITH_CLIENT_AVAILABLE=1 WITH_CLIENT_CHANNELS=ON WITH_CLIENT_CHANNELS_AVAILABLE=1 WITH_CLIENT_COMMON=ON WITH_CLIENT_INTERFACE=OFF WITH_CUPS=ON WITH_DEBUG_ALL=OFF WITH_DEBUG_CAPABILITIES=OFF WITH_DEBUG_CERTIFICATE=OFF WITH_DEBUG_CHANNELS=OFF WITH_DEBUG_CLIPRDR=OFF WITH_DEBUG_DVC=OFF WITH_DEBUG_KBD=OFF WITH_DEBUG_LICENSE=OFF WITH_DEBUG_MUTEX=OFF WITH_DEBUG_NEGO=OFF WITH_DEBUG_NLA=OFF WITH_DEBUG_NTLM=OFF WITH_DEBUG_RAIL=OFF WITH_DEBUG_RDP=OFF WITH_DEBUG_RDPDR=OFF WITH_DEBUG_RDPEI=OFF WITH_DEBUG_REDIR=OFF WITH_DEBUG_RFX=OFF WITH_DEBUG_RINGBUFFER=OFF WITH_DEBUG_SCARD=OFF WITH_DEBUG_SND=OFF WITH_DEBUG_SVC=OFF WITH_DEBUG_SYMBOLS=OFF WITH_DEBUG_THREADS=OFF WITH_DEBUG_TIMEZONE=OFF WITH_DEBUG_TRANSPORT=OFF WITH_DEBUG_TSG=OFF WITH_DEBUG_TSMF=OFF WITH_DEBUG_WND=OFF WITH_DEBUG_X11=OFF WITH_DEBUG_X11_CLIPRDR=OFF WITH_DEBUG_X11_LOCAL_MOVESIZE=OFF WITH_DEBUG_XV=OFF WITH_DIRECTFB=OFF WITH_DSP_EXPERIMENTAL=OFF WITH_DSP_FFMPEG=OFF WITH_EVENTFD_READ_WRITE=1 WITH_FAAC=OFF WITH_FAAD2=OFF WITH_FFMPEG=TRUE WITH_FFMPEG=TRUE WITH_GFX_H264=ON WITH_GPROF=OFF WITH_GSM=OFF WITH_GSSAPI=OFF WITH_GSTREAMER_0_10=OFF WITH_GSTREAMER_1_0=ON WITH_ICU=OFF WITH_IPP=OFF WITH_JPEG=OFF WITH_LAME=OFF WITH_LIBRARY_VERSIONING=ON WITH_LIBSYSTEMD=ON WITH_MACAUDIO=OFF WITH_MACAUDIO=OFF WITH_MACAUDIO_AVAILABLE=0 WITH_MANPAGES=ON WITH_MBEDTLS=OFF WITH_OPENH264=OFF WITH_OPENSLES=OFF WITH_OPENSSL=ON WITH_OSS=ON WITH_PCSC=OFF WITH_PROFILER=OFF WITH_PULSE=ON WITH_SAMPLE=OFF WITH_SANITIZE_ADDRESS=OFF WITH_SANITIZE_ADDRESS_AVAILABLE=1 WITH_SANITIZE_MEMORY=OFF WITH_SANITIZE_MEMORY_AVAILABLE=1 WITH_SANITIZE_THREAD=OFF WITH_SANITIZE_THREAD_AVAILABLE=1 WITH_SERVER=OFF WITH_SERVER_CHANNELS=ON WITH_SERVER_INTERFACE=ON WITH_SMARTCARD_INSPECT=OFF WITH_SSE2=ON WITH_THIRD_PARTY=OFF WITH_VALGRIND_MEMCHECK=OFF WITH_VALGRIND_MEMCHECK_AVAILABLE=1 WITH_WAYLAND=ON WITH_X11=ON WITH_X264=OFF WITH_XCURSOR=ON WITH_XEXT=ON WITH_XFIXES=ON WITH_XI=ON WITH_XINERAMA=ON WITH_XKBFILE=ON WITH_XRANDR=ON WITH_XRENDER=ON WITH_XSHM=ON WITH_XV=ON WITH_ZLIB=ON
Build type:          Release
CFLAGS:              -march=native -O2 -pipe -fstack-protector-strong -fno-plt -fPIC -Wall -Wno-unused-result -Wno-unused-but-set-variable -Wno-deprecated-declarations -fvisibility=hidden -Wimplicit-function-declaration -Wredundant-decls
Compiler:            GNU, 8.2.0
Target architecture: x64

• OS version connecting to: XP, 7, 10 (all updated)
• Log output from a run with /log-level:trace: trace.log

Desktop

• OS: Arch Linux
• Version: rolling, updated

Additional context
Using FreeRDP version 2.0.0-rc2 works fine and I believe this is exactly the same issue as #4785.

The issue seems to affect the home folder and its subfolders only. Accessing other paths works.
This is not a permission issue either as can be seen in the second screenshot - the error message is different in that case. The path does not contain any special characters.

[giox069]

Same problem detected by a Remmina user, see Remmina issue #1711

[akallabeth]

@xsmile @giox069 I can fully access every folder within my /home or any other redirected drives with the current nightly builds 2.0.0-dev4 (b18f9ee86)
Only way to get a dialog like posted is to access a folder which the local user has no permission to access.
Just for reference, tried with

• Folder with a common group readable
• Folder with a common group writeable
• Folder with world readable
• Folder with world writeable
• Folder owned by local user

Where I get the issue is

• Access home folder of different user

[akallabeth]

So, it would be interesting if you can access the folder locally.
Please add ls -lah /home (should only list the folders of your users, redact if necessary) and whoami output for reference.

[giox069]

rm -rf FreeRDP/ /opt/remmina_devel/             (clear source and binaries)
git clone https://github.com/FreeRDP/FreeRDP.git
cd FreeRDP
cmake -DCMAKE_BUILD_TYPE=Debug -DWITH_SSE2=ON -DWITH_CUPS=on -DWITH_WAYLAND=off -DWITH_PULSE=on -DCMAKE_INSTALL_PREFIX:PATH=/opt/remmina_devel/freerdp .
make
sudo make install

giovanni@uno:~/remmina_devel/FreeRDP$ ls -la /home/giovanni/Documenti
totale 376
drwxr-xr-x  4 giovanni giovanni   4096 ago  9 00:25  .
drwxr-xr-x 63 giovanni giovanni   4096 ago 13 09:21  ..
-rw-r--r--  1 giovanni giovanni  17425 ago  1 22:57  afile1.pdf
-rw-r--r--  1 giovanni giovanni     26 ago  1 22:57 'afile1.pdf:Zone.Identifier:$DATA'
[...]



md5-c961ad166ff2c7529ecbc537675e41d3



xfreerdp /v:192.168.56.2 /u:giovanni /drive:xxx,/home/giovanni/Documenti

I can see \tsclient\xxx on network resources with window explorer, but when I click on it, the above error appears:

So: am I using some kind of wrong commandline parameter (/drive:xxx,/home/giovanni/Documenti)?
Later I will do some bisecting or debugging if you need.

[giox069]

Uhm... it does not happen with xfreerdp my laptop. Both my PC and laptop and my desktop PC have ubuntu 18.04, same cmake parameters, both 64bit intel cpu. I will try to apt-update both and see.

[xsmile]

@akallabeth I set up several users with different permissions for their folders, shared /home, tried to access them and these are the results:

# whoami
user
# ls -lah /home
total 56K
drwxr-xr-x 11 root  root  4,0K 13. Aug 10:50 .
drwxr-xr-x 18 root  root  4,0K 11. Aug 20:08 ..
drwx------ 69 user  user  4,0K 13. Aug 10:49 user
drwx------  2 root  root   16K  8. Feb 2018  lost+found
drwx--x---  2 user1 user  4,0K 13. Aug 10:25 user1
drwxr-x---  2 user2 user  4,0K 13. Aug 10:25 user2
drwxrwx---  2 user3 user  4,0K 13. Aug 10:25 user3
drwx-----x  2 user4 user4 4,0K 13. Aug 10:25 user4
drwx---r-x  2 user5 user5 4,0K 13. Aug 10:25 user5
drwx---rwx  2 user6 user6 4,0K 13. Aug 10:25 user6
drwx------  2 user7 user7 4,0K 13. Aug 10:25 user7

• user: dialog 1 (see screenshots in the first post)
• user1: dialog 2
• user2: dialog 1
• user3: dialog 1
• user4: dialog 2
• user5: dialog 1
• user6: dialog 1
• user7: dialog 2

I created another folder /home2 and it can be shared without issues. Ownership and permissions are the same, the only difference I can think of is that /home is located on a separate partition.

# ls -lah /home2
total 12K
drwxr-xr-x  3 root root 4,0K 11. Aug 20:08 .
drwxr-xr-x 18 root root 4,0K 13. Aug 10:56 ..
drwx------  4 user user 4,0K 11. Aug 20:09 user

[Lonniebiz]

After reading @xsmile 's post, I tried renaming my current share folder, and then created a brand new folder with the exact same name as the previous share folder's name.

After this, I disconnected and then reconnected to the remote desktop (via Remmina). At first I could access the local share folder from the remote desktop; I even wrote a new file to the share via the remote desktop.

However, after that, I clicked on another folder in Windows 10 Pro (1803) File Explorer, and then tried to go back to the shared local folder again.

Ultimately, I'm again getting the same error-dialogs as before.

BTW, I've tested this on Windows 10, Windows Server 2003, and Windows Server 2012R2. All produce the same failure dialogs; the local-share-folder seems to be mounted, but when you click on it (via the remote desktop), same issue as before.

@akallabeth I have no issue accessing this share folder locally.

[akallabeth]

Ok, got the problem, looks like FindFirstFileA uses the pattern * for getting the handle for a directory, but it should be . so that the correct information is returned.
Since readdir has no defined order my test machines returned the correct path (the one with /. and others did not (/something) leading to this heisenbug.
Will test a bit more before creating a pull.

[akallabeth]

@xsmile @giox069 @Lonniebiz Thanks for debugging, this was a tough one.

[Lonniebiz]

That makes sense, because, when my share folder was empty, I could put something into it. But, as soon as it had one file in there, and I click away and came back, the error returned.

[giox069]

It seems that the fix works, thank you.

[Lonniebiz]

By the way, the workaround I'm currently using (in case someone else comes across this in the meantime) is this:

Inside my share-folder I've added another sub-folder, and I've placed all existing files (that were directly in the share-folder) into that sub-folder instead. As long as there are only folders inside the share-folder (and absolutely no files), you can transfer files back and forth (between local-computer and remote desktop) using this sub-folder that's inside the share-folder.

[pgarrouste]

Since 2.0.0-rc3 some directories in \tsclient\ was not accessible, so I've downgrading to 2.0.0-rc2 and that works.
My OS : Archlinux.

[bberndt]

Same on Fedora 28.
Remmina 1.2.31.3 (git n/a)
Freerdp isn't installed as such, but I do have:
freerdp-libs x86_64 2:2.0.0-44.rc3.fc28 @updates

All installed from Fedora repo. So, just wait for an update to repo?
thanks.

[joeklo]

I am also affected by this annoying bug. :(

Is there a schedule for a freerdp-rc4 to get this fix into the distro's repos?

[rainerklier]

By the way, the workaround I'm currently using (in case someone else comes across this in the meantime) is this:

Inside my share-folder I've added another sub-folder, and I've placed all existing files (that were directly in the share-folder) into that sub-folder instead. As long as there are only folders inside the share-folder (and absolutely no files), you can transfer files back and forth (between local-computer and remote desktop) using this sub-folder that's inside the share-folder.

as i am affected by this, i tried your workaround, and it works.
so currently i have 2 choices:

1. downgrade do 2.0.0-rc2
2. rearange directories and files so that everything is in a subfolder

i hope, this will be fixed in rc4

[ghost]

Still no solution to this bug? I am also affected :/

[rainerklier]

Still no solution to this bug? I am also affected :/

which distribution do you use?
for opensuse i know a working package.

[ghost]

I am on Solus using FreeRDP 2.0.0_rc3-9

[Lonniebiz]

This bug was solved about 1 or 2 days after it was first reported. I wonder if you guys can install Remina-Next on opensuse or solus?

I can't advise on that, but I stay current with the latest Reminna on Ubuntu installing like this:

sudo apt-add-repository ppa:remmina-ppa-team/remmina-next ; sudo apt-get update ; sudo apt-get install remmina remmina-plugin-rdp

I hope your distro has something similar. If so, this bug is over!

Update: I just realized that you guys aren't necessarily using Remmina, but are instead using FreeRDP (a package that Remmina depends on -- that has been updated in Remmina due to this bug).

[hartois]

fix https://github.com/FreeRDP/FreeRDP/commit/8b8e85271c4824e11b6d82ff9fc9b3fb664a8942 works for me, thanks

[rainerklier]

I can't advise on that, but I stay current with the latest Reminna on Ubuntu installing like this:

sudo apt-add-repository ppa:remmina-ppa-team/remmina-next ; sudo apt-get update ; sudo apt-get install remmina remmina-plugin-rdp

I hope your distro has something similar. If so, this bug is over!

Update: I just realized that you guys aren't necessarily using Remmina, but are instead using FreeRDP (a package that Remmina depends on -- that has been updated in Remmina due to this bug).

yes, i use Remmina and freerdp.
on opensuse i install latest freerdp packages from http://download.opensuse.org/repositories/home:/hendwolt/openSUSE_Tumbleweed
and Remmina from http://download.opensuse.org/repositories/X11:/RemoteDesktop/openSUSE_Tumbleweed/

this is like a "next" packge.
current freerdp version from this repo is 2.0.0~git20181019-1.1
current Remmina version is 1.2.32-78.1
works as expected.

[bberndt]

Problem fixed!

installed freerdp-libs freerdp-libs-2.0.0-46.20181008git00af869.fc28.x86_64.rpm from the updaes-testing repo for Fedora 28. Left the Remmina version the same, form the standard repo.

[zechzhao]

@giox069 's post is actually the correct way to access the shared folder.

It's just the shared fold is not under Network, but under This PC > xxx on uno.

At least this works for me, hope will be of help for someone else as well.