Hi Dominik,
On Wed, Jul 20, 2016 at 02:28:35PM +0200, Dominik George wrote:
> Control: tag -1 + moreinfo
>
> Hi,
>
> >
> > In MidnightCommander it is displayer in red with a leading '?'
> > dated 01.01.1990 is owned by root and has all permissions unset
> > (like `chmod 000 .thinclient_drives`)
> >
> > As root I can remove this dir using
> >
> > rm -rf .thinclient_drives
> >
> > but that's the only option I've found to deal with this.
>
> This is correct and has nothing to do with xrdp (itself).
>
> The directory is managed by FUSE to hold the drives mapped from the RDP
> client. What you see is the expected behaviour for all FUSE-managed
> mount points (try sshfs, for example).
>
> Not even root can access FUSE mountpoints of other users - that is
> annoying, but has nothing to do with xrdp.
Fuse is not used on this machine and the directory did not exist in
users $HOME dirs until they start an xrdp session with the new xrdp
version. In other words: Under xrdp 0.6 from Jessie the problem did
not exist but occures with the backport of 0.9.
> > The problem that occures from this is that when starting
> > Thunar it claims that it can't open this dir (which is
> > correct) and seems to stop gvfs scanning from then on and
> > users can not see their network mounts.
>
> 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.
> 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.
> > $ 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?
> 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).
Kind regards
Andreas.
PS: As an unrelated note three users reported problems after xrdp 0.9
was installed. I'm just wondering how I can turn the problem described
here
https://lists.debian.org/debian-edu/2016/07/msg00064.html
into a sensible bug report. Another user also reported interruption
when leaving xrdp idle. I was not able to check the logs.
--
http://fam-tille.de
