how to deal with shared home directory on linux?

Question

situation is as follows:

• home directory is on nfs share A: /home/me
• workstations a, b, c, ... share that home directory: /home/me is a link to A:/home/me
• all workstations are used at the same time

example:

NFS share A has

• /home/john
• /home/anne

Workstation a has

• /home/john -> linked to NSF Share A /home/john
• /home/anne -> linked to NSF Share A /home/anne

Workstation b has

• /home/john -> linked to NSF Share A /home/john
• /home/anne -> linked to NSF Share A /home/anne

this tends to give all kind of weird problems, because all settings directories (.matlab, .kde, Desktop etc, possibly trash as well, didn't check that) are all shared and written to/read from at the same time. Furthermore the configuration of the machines can be quite different, so putting shortcuts on the desktop turns it into one big mess since half of them are not accessible on all machines.

Basically I'm looking for an easy to manage and effortless way to cope with this, something in the veins of how it's done on windows with the roaming/local profile thing. The requirements would be:

• the root of the home dir, and some other folders I can select, as well as some setting dirs like .svn and .ssh, must be the same on all machines
• pretty much all other setting setting directories can be local to each workstation, but should be on the nfs share as well
• ideally I would also have some application that allows me to do things like 'take all settings from kde's Konsole application, and make them the same on all my workstations'

Answer 1

I came up with one possible solution, it's pretty effortless but does not really fullfill my last requirment. Basic idea is: let each workstation have it's own home directory, and make softlinks to the files/directories that should be common. All homes are still on the NFS share, but in different folders.

NFS share:

/home/john/sharedhome/
                      .ssh
                      .svn
                      shareddocs

/home/anne/sharedhome/
                      .ssh
                      shareddocs

/home/john/home_A/
                  .kde
                  .vnc
                  .matlab
                  .ssh -> link to ../sharedhome/.ssh
                  .shareddocs -> link to ../sharedhome/.shareddocs

/home/john/home_B/
                  .kde
                  .vnc
                  .matlab
                  .ssh -> link to ../sharedhome/.ssh
                  .shareddocs -> link to ../sharedhome/.shareddocs
                  .bashrc -> link to ../sharedhome/.bashrc

etc, you get the point

Workstation a:

/home/john -> linked to NFS share /home/john/home_A
/home/john/.kde -> will be NFS share /home/john/home_A/.kde
/home/john/.ssh -> will be NFS share /home/john/sharedhome/.kde
/home/anne -> linked to NFS share /home/anne/home_A
etc

Workstation b:

/home/john -> linked to NFS share /home/john/home_B
etc

I still would like to hear some other opinions though.. Also, I did not yet test this out, but it seems valid. Will update after trying.

update

this turned out pretty well. Had to:

• adjust the /etc/exports on the server to export export all different homes and the one shared home
• on each workstation change the automounter config to mount the correct home for that workstation, and to mount the shared home as well
• create the necessary links for each workstation

result looks like this on the workstations

/home/john -> NFS share /home/john/home_A
/home/john_shared -> NFS share /home/john/sharedhome
/home/john/sharede -> symlink to /home/john_shared
/home/john/.ssh -> symlink to ./shared/.ssh

I'm going to accept this as the answer as well since nobody else came up with something..

Answer 2

I would give each use their own separate home directory. Use permissions to lock down settings for some applications and use hardlinks to make common settings.

I don't think you can get finer granularity than that. I imagine that applications that expect to be able to change (some of) their settings may fail in unexpected ways when users attempt to change something - so careful testing is needed.

It might be instructive to read what JWZ did. Though his use case is more extreme.