Hi, > Fuse is not used on this machine […]
Yes, it is. xrdp uses FUSE to provide shared directories from RDP clients. You provided the link between the directory and FUSE in your original bug report. > and the directory did not exist in > users $HOME dirs until they start an xrdp session with the new xrdp > version. Yes. Before mounting a FUSE fielsystem, the directory needs to be created, obviously. > In other words: Under xrdp 0.6 from Jessie the problem did > not exist but occures with the backport of 0.9. Yes, but that's not because the directory is broken, but because old xrdp did not support shared directories. > > Normally, the user who mounted the FUSE directory should be able to > > acces it like normal. > > So something not normal is happening here. As I said the user can not > open or access it - no wonder if it has all permissions unset and > belongs to root. You actually didn't say that. You posted some commands and their results when run as root, and what you posted is normal behaviour with FUSE. Could you please repeat these commands as the user running the xrdp session, from within the xrdp session? > > I guess gvfsd in jessie is running as root and doing nasty magic through > > policykit or something? > > I checked the gxfsd processes on the machine and each user has a > separate one. There was no fidling around with gvfsd - just a plain > Debian stable installation. That does not mean that it does not try to access the directory as root. > > > $ grep -R thinclient_drives > > > debian/patches/fusepath.diff:- /* define FUSE mount point to > > > ~/xrdp_client, ~/thinclient_drives */ > > > debian/patches/fusepath.diff:+ /* define FUSE mount point to > > > ~/.xrdp_client, ~/.thinclient_drives */ > > > debian/patches/fusepath.diff:-FuseMountName=thinclient_drives > > > debian/patches/fusepath.diff:+FuseMountName=.thinclient_drives > > > sesman/sesman.ini:FuseMountName=thinclient_drives > > > sesman/chansrv/chansrv_fuse.c: /* define FUSE mount point to > > > ~/xrdp_client, ~/thinclient_drives */ > > > > > > so it is definitely xrdp that's causing this strange dir. > > > > xrdp creates it as a FUSE mountpoint. but the consequences you see > > definitely look like a combination of the bad behaviours oF FUSE and > > gvfs in jessie (or in general?). > > > > I expect this to also happen with an sshfs mount. Could you try that? > > The mounts are samba shares (cifs). > > What exactly do you want me to try? $ sudo apt-get install sshfs $ mkdir .foobar $ sshfs u...@ezample.com: .foobar Then see whether it impacts Thunar as well. sshfs uses FUSE, just like xrdp, and I expect that you see the same behaviour with .ffobar after mounting sshfs on it as you see with .thinclient_drives. > > > If you still think this is specific to xrdp, please explain why. If not, > > this should be discussed with the gvfs maintainers. > > I think xrdp is creating a directory that creates problems. IHMO the > fix would be to make sure xrdp does not create this directory (and > simply is using it if it exists). No, that is not a fix. It would mean that users would not be able to use shared directories over RDP unless they manually create some directory. As I cannot reproduce the problem (without Thunar/gvfs) and in fact find a working FUSE mountpoint in ~/.thinclient_drives, I think the real cause of the issues should be found instead of breaking user experience with xrdp. -nik -- PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17 FD26 B79A 3C16 A0C4 F296
