Personal System Folders and NFS

[William Roberts]

In <HOSKING.90Dec1145333 at ibis.cs.umass.edu> hosking at cs.umass.edu (Tony 
Hosking) writes:

>I am having trouble with personal system folders (created using the
>systemfolder command) for users whose home directories are on an NFS-mounted
>volume. When the user logs in at the console things go really slowly, with
>some disk activity, then eventually the login just gives up and the Login
>dialogue box comes back. No error messages, nothing, just plain refusal to log
>in. If I remove the personal System Folder from the user's remote home
>directory then they can log in again with no problems. Does anyone have any
>idea what's going on and how to fix the situation? I have no problem with
>personal system folders for users having a local home directory. Perhaps this
>is a bug in A/UX 2.0? Has anyone else encountered this?

All our users have home directories on NFS fileservers, and we have for now 
rejected the whole idea of personal system folders because we couldn't make 
them work satisfactorily: we did sometimes manage to login, but it wasn't very 
reliable and horrendously slow. 

I doubt that this is a bug in A/UX 2.0, just that some things are done in ways 
which are very inefficient via NFS. The only NFS-related snag we have had is 
that /mac/bin/Login tries to write the user's .aux_prefs file (which records 
the session type) as root, which falls foul of the uid 0 -> uid 65534 
translation.

We tried having personal system folders, but local .fs_cache, .fs_dirIDs, 
DesktopDB and Desktop DF files, i.e. the personal System Folder had symbolic 
links to local versions of these files, but this didn't work because the .fs_* 
files were removed almost instantly and re-written (onto the NFS fileserver). 
We now think that this might be due to date problems making the .fs_cache look 
out of date, but we haven't tried repeating the experiments yet.

We've also given up on accumulating a Desktop database: we have a compressed 
cpio archive containing clean, sensible versions of the files mentioned above, 
and we recreate the files from that archive for EVERY login (as part of the 
/mac/bin/mac32 script). We also use a semaphore so that an INIT can let the 
outside world know when startmac has finally started, and we run the 
CommandShell after that. The current "CommandShell &" scheme relies on 
everything happening before CommandShell's patience runs out, and that wasn't 
reliable either if the previous Mac session had died or been terminated 
brutally.
--

William Roberts                 ARPA: liam at cs.qmw.ac.uk
Queen Mary & Westfield College  UUCP: liam at qmw-cs.UUCP
Mile End Road                   AppleLink: UK0087
LONDON, E1 4NS, UK              Tel:  071-975 5250 (Fax: 081-980 6533)