Home Forums OS X Server and Client Discussion Questions and Answers Networked home directories and share points

Viewing 3 posts - 1 through 3 (of 3 total)
  • Author
    Posts
  • #366910
    deemery
    Participant

    On my server machine, I have two partitions. The OS runs on one, and I want home directories to be on the other. I created a directory on the other partition, /Volumes/Wyvern-300/u, which is where I wanted to put all the home directories.

    First I set /Volumes/Wyvern-300/u as a share point for home directories.

    Next I created my first user, Test1, and set his home directory in /Volumes/Wyvern-300/u/Test1.

    Then I went to another machine, configured LDAP, etc, and logged on as Test1. So far so good.

    Back on X Server, I created a second user, Test2, and indicated that user should also use /Volumes/Wyvern-300/u as the parent for his home directory. When I saved the user, /Volumes/Wyvern-300/u/Test2 was created, and I was able to log onto Test2 from the X Server machine.

    But when I went over to the client machine and tried to log onto Test2, it accepted/validated the password (good…) and then gave me an error message that it couldn’t log in, the home directory was on an AFB or SMB mounted drive, and to contact my sysadmin. (That set a pretty piss-poor standard for an error message, telling me something I knew without telling me where to look!).

    After much experimenting and cursing, I discovered that things would work correctly if I created a second parent directory, /Volumes/Wyvern-300/u2, and then reset Test2’s account to point to /Volumes/Wyvern-300/u2. The Test2 file was created in the new parent u2.

    Then I was able to log onto Test2 from my client machine, just like I expected.

    So is this how it’s supposed to work??? From my very old SunOS experience, that’s certainly not what I expected. It seems to be an unacceptable burden to define a new mount point/parent for each and every user account’s home directory.

    Or might this be a configuration problem or even protection problem with the parent directory?

    Thanks in advance!

    dave

    #366915
    Ross
    Participant

    You need to set your mount point up.

    Select your home dir share look under Sharing in WGM. You will see a tab for “Network Mount”, auth as the directory admin and check the box for “Enable network mounting of this share point”. Select “User Home Directories” for use.

    Then go into your user account and you will see under the “Home” tab you now have a choice “afp://server.domain.com/share” select this and you should be good assuming DNS is correct (reverse and forward).

    #369083
    reppep
    Participant

    Our users want their home directories on their primary (non-Server) machines. That works — I just specify the workstation’s hostname in Workgroup Manager.

    Unfortunately, they also want their data on a secondary drive (say /Volumes/home). When I specify this in Workgroup Manager, it creates /home rather than using /Volumes/home. I tried sharing /Volumes/home via SharePoints, but it didn’t help. I tried making /home a symlink to /Volumes/home, and the system silently unmounted the /Volumes/home!

    Is there a way to use volumes other than the boot disk on non-Server systems for network homes?

    I think I got bitten by part of https://www.afp548.com/article.php?story=20060303070213402&query=symlink

    2. You can’t do any of this with afp. If you want to see an afp server/client combo freak out just try having it follow a symlink. The good news is that you can use SMB or NFS or FTP just fine for this setup, with SMB providing the closest experience to afp. The big problem with this would come from trying to create snapshots of existing legacy data. You would need to re-stream all of it from afp to SMB or otherwise split the forks and meta off with SplitForks so that the clients would be able to see them when they connect. If you want to make a design group unhappy, lose the resource forks off all of their Quark files.

Viewing 3 posts - 1 through 3 (of 3 total)
  • You must be logged in to reply to this topic.

Comments are closed