How to set up network logins and home folders in Mac Server 5.7.1

It might still be possible to use WorkGroup Manager to connect to your Open Directory server and then have a friendly user interface for configuring Network Home Directories. However see my previous recent post here - https://discussions.apple.com/thread/250094788?answerId=250173039022#250173039022

Hello Bushwhacker007,

So the simple answer is, yes this can be done. The complex answer is that it is not as easy as it once was and you will really need to test your applications to ensure that they support network home folders. Even when Apple supported network homes, there were challenges. Many challenges...

Let's start with the basics. Grab a drink and a snack. This is going to take a while.

Foundation Requirements:

This is a A LOT easier if you have DNS working properly and your server has a fixed IP address. For the rest of this example, I will assume you have DNS setup and the fully qualified host name of your server is homes.classroom.edu.

If DNS is not setup properly, do that first. Ask your network admin (might be you) to create a DNS record for your server and assign it a fixed IP address. Once this is done, you should demote OD to standalone, reboot, and then create a fresh OD master. This ensures everything is setup correctly. DNS is the key. It stands for Do Not Skip.

Next, the place that you plan to store your home folders is REALLY important under 10.14. If you bought an iMac and it has a 256 GB internal drive, and that is all you have, then you really better keep an eye out for disk utilization. An empty home folder logged into one time and with nothing pulled from the user template is 46 MB. Assuming students will be storing files in the home folder, and estimating an average of 5 GB per student, then you can only support between 35 and 40 students on that boot volume. (5 GB x 40 students is 200 GB, which doesn't leave much room for OS and applications and breathing room) Seriously consider external storage that is fast and supports a high number of iops (net home folders create a ton of little files)

Additionally, regarding location of the network home folders. If you are using the internal drive, your only sharing option is SMB. You can not share folders from an APFS formatted volume using AFP. If you have external storage and it is formatted HFS+, then you can use AFP for the network home paths. In the examples below, I am sharing a folder from an external volume so I use afp as the protocol in the examples. In theory, SMB should work the same way. But I still hate SMB but that is a story for another time.

Setting up your Server:

As mentioned above, your server should have a fixed IP address and a properly resolved DNS name. From any client on the network you should be able to do an nslookup homes.classroom.edu and get the IP address. Reverse resolution should be working also so make sure that PTR record is in place.

Create an Open Directory Master.

Define a folder that will contain your network home folders. If on external storage, make sure that "ignore permissions" is NOT checked for the volume. Permissions are critical for Network Home folder operations. If you are storing the network home folders on the boot volume, then permissions are already in play and no additional action is needed.

When you create the parent folder, do NOT apply and ACLs to the folder. Leave only the default POSIX permissions. For example on my external drive, I created a folder called NetHomes and it is owned by the local admin (read/write), and read by the default group and other. That is fine. Don't get fancy with this folder.

Share this folder using System Preferences > Sharing.

If you are sharing from an external volume, press the Options... button and check the Share files and folders using AFP checkbox.

To make sure that the proper protocols are set on the share, right-click/control-click on the share and choose Advanced Options... from the contextual menu.

Turn File Sharing on

Creating your Users:

Now you need to create your user accounts so they will respect network home access. Follow these steps:

1: Open Server.app

2: Select Users

3: Set the popup menu to Local Network Users - THIS IS CRITICAL!!! USERS MUST BE IN OD

4: Add a new user

5: Right-click/Control-click the user from the list and select advanced options from the contextual menu.

6: You will need to override the Home Directory, Share Point URL, and Path to Home Folder in this box. Here are examples:

(a) Using AFP on an External Volume

Home Directory: /Network/Servers/homes.classroom.edu/Volumes/Data/NetHomes/bbunny

Share Point URL: afp://homes.classroom.edu/NetHomes

Path to Home Folder: bbunny

Note that the fully qualified host name is included in two of the paths. In Home Directory, it is defining the CLIENT path to access this user's home folder. The share is mounted in /Network (goes back to NetInfo days and NeXT). The SharePoint URL is the mount point. And the the path is just the users short name (following short name = home folder name convention).

If you are sharing content from an Internal drive and using SMB, the syntax would be:

(b) Using SMB on boot Drive

Home Directory: /Network/Servers/homes.classroom.edu/NetHomes/bbunny

Share Point URL: afp://homes.classroom.edu/NetHomes

Path to Home Folder: bbunny

In this example, I created a folder called NetHomes at the root of the Boot drive as I don't want it in Users or any other Apple folder.

Now, because the UI support for network home folder creation has been removed, the issue with the above steps are that when you created the user's account, a home folder was created in /Users on the server. But, you just changed the path to point it to a network server location. So if you try to log into the the account from a bound machine now, it will hang. Pulling network will eventually let it fail, but let's avoid that.

Instead, move the home folder to your network home folder share. This should be done using Terminal to avoid screwing up permissions.

sudo cp /Users/bbunny /Volumes/Data/NetHomes/

Remember, if you are using internal storage, and you are sharing the /Users folder (not recommended) this move is not needed.

Workstation Setup:

Go to your workstation. Bind it to your OD master using Directory Utility or via dsconfigldap. Once this is done, you will get Other... on the login window. Remember, user Fully Qualified Host Name when binding.

At the login window, choose Other...

Enter the user name and password.

Login. You are now accessing a network home folder.

More Thoughts But a Break Is Needed:

I have more to add to this. However, it is time to change locations so I must post this and then pick it up later. Some items to discuss:

Profile Manager and cache redirection

Deleting users and data

Backup

Network load/Disk load

Application stack and compatibility

And the fact that you are officially off the reservation. Yes this works. But I can not tell you for how long.

I should complete this tonight. But this will get you started.

Reid Bundonis,

Apple Consultants Network

Author of a bunch of books on OS X Server

Lover of the platform

Jilted by the deprecation of features

Ok, part three. Still with me?

Profile Manager:

On the basic level, Profile Manager is not required to make Network Home Folders work. As seen above, it can work just by defining the right attributes on the user's account. But, Profile Manager (or a more capable MDM) can provide additional functionality such as the delivery of configuration profiles. Ah, but there is overhead here. First, your network must allow Push. Download Push Diagnostics from the Apple App Store and test on your network. If you get all green then you are good. But next, you should get a valid SSL certificate (or one from your private CA that you explicitly trust), and you need a push certificate that you MUST renew every year or pay the penalty. Again, DNS is key as Profile Manager is/can be a public site. If you are supporting laptops that leave the environment, Profile Manager is a poor choice. Look to a cloud MDM instead. If everything is LAN based, then Profile Manager is generally ok. But...

Profile Manager is basically a reference implementation. You will have problems and Apple will not fix them. Or help you. Maybe ever. However, it is very cheap and generally capable for limited roles.

The one area that you should investigate is the use of a custom profile to redirect your cache files to the local drive. This is a common Net Home tactic. However, with today's SSD based drives and better networks, this redirection may not be needed as much. The issue will be the network load when those thousands of web cache files start flowing across the network from 30 systems at once. To solve this, you need a com.apple.MCXRedirector payload with a LoginRedirection and a LogoutRedirection. I believe there are examples available online to work from.

But Profile Manager is technically not required for this. You can simply create a profile and manually install it on each machine. If you are only dealing with one lab of 30 systems or so, this is not a bad deal. But if you are supporting 100s of devices, you really want an MDM to automate the process.

Deleting Users and Data:

This is going to be a manual process. When you delete a user from Server.app, it will not delete the user's home folder. So to maintain your disk storage, make sure you are also purging user data after deleting user attributes. For a couple of schools I created a custom app that reads the users in OD and then when selected it will delete the user using dscl and then delete the user data using rm. Generally easy to script allowing a cleaner process when students move on.

Odds and Ends:

Network homes is a demanding service. There is both network and disk load. You need to account for "the rush." Bell rings, kids walk in, and a whole class of kids log in nearly all at the same time. While this is possible over wireless, you need GOOD wireless. Ethernet is better. Expect performance issues when you have a full class all logging in within the same few seconds.

Next, know your application stack and compatibility. Even common applications like Word can trip you up over network homes. Some apps, like the heavy hitters (Photoshop (nearly anything from Adobe actually), FinalCut, iMovie, Photos, 3d modeling apps, etc) run very poorly over network homes. These apps tend to have very large data files and opening them direct from the server can cause performance issues. Test. Test. And then test some more. Don't assume the app(s) will work fine. Oh, and Keychain... Local Items Keychain, how you vex me.

If you need to customize the user experience and you are not using Profile Manager (or there are settings that you can not set using an MDM), you must edit the server's User Template, not the clients. Remember, the home folder is being created on the server, not on or by the client machine. Edit the server's User Template to modify the initial user experience.

Final Thoughts:

You are officially off the reservation. Yes this works. But I can not tell you for how long. Or how well. Apple is moving away from this, mostly because they are getting eaten alive by Google in this space. But that is sad because ChromeBooks are really limited use devices. Sure you can do some word processing, web browsing, and spreadsheets. But if you have a lab for STEAM or the arts, Macs still are the best choice. From power to ease of administration to a fuller application catalog, you can not find a better solution.

Best of luck. I had a free afternoon and felt compelled to get back into the forum. Been a while. Sorry for the overload.

Reid Bundonis

Happy New Year Pierre. Hope all is well.

I actually spent most of July pulling together a new book for Mojave. It is probably 90% complete. But my narrative kept getting halted by DNS. And here we are 6+ months later and I still don't have a good answer for DNS. I hate the "just compile it yourself and use the old zones files" approach that Apple is offering. It is terrible. Yes, the initial task is easy, but ouch! Editing?!? Let's say you are doing split horizon and, oh, I don't know, something as obscure as having public DNS hosted in Amazon's Route 53. When they roll a server address, you need to edit three files (forward zone, reverse zone, and conf) plus likely rename the reverse zone. Painful. Just painful. Not an Apple solution and a regression from what we had. That chapter alone cause me to go off the rails and never come back.

And while I understand everything behind the changes in Server.app, removing DNS is such a bad idea. If the three services left are Open Directory, Profile Manager, and Xsan, and they ALL require DNS to function properly, why remove it? There are still all Apple environments out there. We support too many to count. They don't have a Windows box running DNS. And as much as I can see a future where DNS on the LAN may no longer be needed, workflows are in place with the expectation of proper naming.

Sonicwall has the DNS proxy service in their firewalls. I've been begging them to just add a full blown DNS resolver. They are already listening on port 53 to do the DNS interception. Just add the ability to create some A and PTR records. I honestly think that is enough to get by at this time.

But I still see Apple devices as servers as being a viable solution for many small businesses. I will admit, my favorite deployments have been departmental Mac servers in AD environments. Such an easy deploy. I am not even installing Server.app in AD environments. Set the IP and hostname, bind to the domain, and setup file services and caching (if the network allows). Simple and fast.

And the saving grace for Apple as a server remains Spotlight. I was recently doing some work for a large retailer and they had a Mac Pro tower running 10.8.old and IT wanted it gone. But the creative folks have been using metadata like Finder comments and XMP data to tag all images for the last 10 years. Every image has UPC code embedded as metadata. So, on a Mac server, they do a Spotlight search of a UPC code and EVERY image of that product is returned in seconds. The IT department said no Mac servers and started piloted putting the content on Windows server. Immediate revolt. The creative department could not find anything and workflow ground to a halt. They tried Acronis. Nope, search is not granular enough. In the end... yep, you guessed it. I deployed a Mac server. No workflow interruptions and a happy group of Mac users able to do their work with little hassle.

Ok, you caught me ruminating again. I have a bit of a bye week this week as I get some rare office time. Another book is likely still in the future. Amazing how fast time goes as we will be starting another beta round in 4 months.

Thanks for reading. You know me. Got to keep those Macs in the data center.

Hey Reid,

sorry to hijack this tread. For what it is worth, you mentioned just my setup. We now run our Filemaker Server on AWS, so our Mac 2010 mini server with 5.3 server and Sierra (never went to High Sierra because e of Raid support gone AWOL) has to point to that. There is NO documentation of how to make this work.. Somehow it does.

Now started using Business Manager business.apple.com.. So many questions.. A good book would be welcomed.

Minor mistake above. Don't use the cp command. Use mv. For example:

sudo mv /Users/bbunny /Volumes/Data/NetHomes/

cp with copy. mv will move.

woow

followed this.

great read Reid!

when will your new book,now with business.apple and this little chapter here come out!.

welcome back

Pierre