[Samba] Workaround found, .Xauthority and SMB, Mounting home directory

[Schlomo Schapiro]

Hi,

AFAIK SMBFS etc. don't support locking, sockets, fifo, ... (oftenly also
symlinks).

My guess regsarding the xhost thing is still, that the .Xauthority file
has trouble. To find out you could attach an strace -ff to the running
display manager and look which files it and the subproceccesses try to
use. Look especially for the usage of xauth.

Regards,
Schlomo

PS: I don't have so many users, but managing even many shouldn't be so
much of a problem. If need to, put it on a separate fileserver and use
automount to mount it.



On Tue, 27 Apr 2004, Ben Ford - Bio-Logic Aqua Technologies wrote:

> On Tuesday 27 April 2004 04:09 am, Schlomo wrote:
> > the display manager (GDM, ...) usually stores the XAUTHORITY cookie in the
> > .Xauthority file in the users' home dir. If you mount that on-the-fly,
> > maybe you mount it too late ? So that .Xauthority in the user home dir is
> > not accessible at this stage ?
>
> This could be true, good point.
>
> But, note this FACT: with the home directory mounted as SMBFS ( ?which doesn't
> support locking?) you cannot run X with the .Xauthority being written in your
> home directory.  You get the following error:
> xauth:  error in locking authority file /home/ben_ford/.Xauthority
>
>
> I've tested this thoroughly in runlevel 3:
> **NOTE: In this test, I have eliminated pam_mount and a graphical login.**
>
> a) Before the user has logged in,  I mounted /home/ben_ford manually.
> b) After logging in, I can successfully browse my "remote" home directory.
> c) issuing a `startx` command results in the locking error:
> xauth:  error in locking authority file /home/ben_ford/.Xauthority
>
> Now, if I set the following environment variables my .bash_profile:
>
> export XAUTHORITY=/tmp/.Xauthority
> export ICEAUTHORITY=/tmp/.ICEauthority
>
> Logout, and log back in, and re-do the exact test, I can start X fine!!!
>
> Similar setup but using NFS does NOT require this workaround.  SMBFS doesn't
> allow locking perhaps?
>
> > With the xhost +localhost you effectively
> > circumvent X security.
>
> Still with the previous workaround in effect, Graphical login does NOT work.
> When I use the `xhost +localhost` command as noted in my previous email, I
> can successfully login with GDM.
>
> I'm sure that issue the `xhost` command could be done in any place, but
> the /etc/X11/gdm/PreSession/Default seemed very effective.
>
> >
> > I had a similar case here (though with Novell servers) and solved it and
> > the KDE / GNOME problem you describe by keeping the homedir local and
> > mounting the server homedir in a subdirectory of the homedir. This way the
> > Linux stuff stays on the Linux side and the personal files and data stays
> > on the server side.
> I considered this solution at first, but disregarded for some reason. Your fix
> is a lot cleaner then moving files ( via my changes to /usr/bin/startkde )
> outside the home directory.
>
> How many clients do you use?  Does having the home directory completely local
> make administering those machines difficult?  This was one of our concerns.
>

-- 
Regards,
Schlomo