The Network Domain
March 23rd, 2006A much-overlooked perk of Mac OS X’s BSD underpinnings is the presence of full-fledged support for NFS (network file system) in every shipping version of the operating system. This support serves as the underlying technology for the “Network Domain,” the fourth member of a family of directory hierarchies that also includes the System, Local, and User domains. Within each of these domains, a predictable directory layout allows for the storage of applications, preferences, fonts, etc., in such a way that a properly-written application can transparently make such resources available to the user as a unified whole.
Most users are probably not familiar with the concept of file-system domains at all. Among those who are, it probably boils down to a vague understanding that stuff in /Library is shared, stuff in the home directory is private, and stuff in /System should not be modified. The mysterious /Network directory is occasionally used to sluggishly locate shared directories from other computers on the LAN (local area network), but is rarely configured to fulfill its complete potential as the Network domain.
A FastScripts user recently contacted me. He works in a newspaper office, and is curious about whether there is any facility in FastScripts for sharing a directory of scripts to his entire team. Frustratingly, I have to tell users like this one that there is support for just such a setup – the network domain – but that setting it up is about the most convoluted Mac OS X task imaginable. It’s so beyond the scope of what any average user should be asked to do, that I’m tempted to implement a custom inter-computer sharing system, just so I can offer my customers a “do it for me” switch. Apple’s advice? “Implementation of the network domain is the responsibility of the network administrator.”
But the network domain is an awesome idea! So it looks like you get to be the network administrator. By setting it up correctly you gain a centralized share for all users of a LAN that benefits not only FastScripts, but any other application that correctly iterates the four domains for supporting files! For this reason, it’s worth knowing how to set up, and worth pressuring Apple to make the setup easier for everyday users. The remainder of this article details the steps you may take to both publish a shared “Library” folder from one computer and subscribe to it from any number of other computers on your LAN.
Configuration: A High Level Overview
Before you tackle the task of setting up your network domain Library folder, you should be familiar with some terms used by the technologies on the Mac.
NetInfo is a unique Mac OS X technology inherited from NeXT. NetInfo is a database that manages many of the attributes of a computer and network that would, on more conventional UNIX systems, be managed entirely with text-based configuration files. Among NetInfo’s many responsibilities is the management NFS automount server and client information for particular machines on a network.
NFS is a UNIX technology for exposing shared directories from one system and mounting them to another. Unlike Apple’s legacy AppleShare system, where mounted servers appear functionally identical to mounted disks, NFS volumes can be attached virtually anywhere in the filesystem you desire (this is true for regular disks as well, but is rarely exploited). For instance, if you want to publish your music collection from one computer and have it show up on all other computers at the path “/MyStuff/ObscurePath/Whatever/Music/”, NetInfo can make that happen. The arbitrary location at which you decide to attach the shared directory is called a “mount point.”
A cool feature of NFS is a sort-of lazy loading technique whereby a mount point can remain unconnected until it is actually needed by some application. The technology responsible for this magic is called “automount.” What’s really cool about automounting an NFS shared volume is that it gracefully handles the absence of either the server or the client. So when you wander outside the realm of your LAN, the funky Music mount point described above simply fails to locate the network resource. Instead of starting a 4-alarm fire, you simply get an “empty” directory.
So bringing this all together, how do we employ the underlying technologies such that we achieve our primary goal? We want a shared network domain Library folder, and the way to do that is by publishing an NFS volume that gets subscribed to with an automount mount point at “/Network/Library”.
On the Server: Publish an NFS Volume
First things first, we need to pick a directory on our “server” box and publish that to the LAN via NFS. In NFS terminology this is called an “export,” and the way this is configured on Mac OS X is via a top-level NetInfo directory entry called “exports.” NetInfo can get really complicated and to make things simple I’m just going to show you how you can add a plain-vanilla NFS export for a folder located at “/Library/MyNetworkShares/Library”. The “nicl” command-line utility makes this relatively straightforward:
sudo nicl . -create /exports/\\/Library\\/MyNetworkShares\\/Library opts alldirs maproot=nobody
Note the crazy backslash overload. That’s because we want to get slashes into the actual name of the directory entry in NetInfo. The same task could be accomplished from the NetInfo Manager application, where you can also confirm visually that the configuration has been made as expected:
Once the NetInfo database has been updated, you can either attempt to ensure that all of the required daemons are reset and recognize the new exports settings, or you can just reboot, which should get the NFS startup item to reload and configure everything corectly. By default the NFS server is enabled, and starts at boot time if there are any exports defined.
To confirm the NFS export is set up and your daemon is operational, simply run the showmount command from the command line on the server:
showmount -e Exports list on localhost: /Library/MyNetworShares/Library Everyone
Now from another machine (or the same – doesn’t really matter), confirm the ability to actual mount the “volume”. My server machine is identifiable on the local network as “danielG5.local”, so I mount the exported directory on my laptop with:
mkdir /tmp/testmount mount_nfs danielG5.local:/Library/MyNetworkShares/Library /tmp/testmount
Et voila! /tmp/testmount now looks and acts exactly as the /Library/MyNetworkShares/Library folder on the server.
On the Client: Configure the Network Mount Point
Now that we’ve confirmed the ability to mount the server on a whim, we need to arrange for the client machine to automatically “wire up” to the server whenever the /Network/Library directory is accessed. We do that by configuring a similar NetInfo node to the “exports” item above.
This time, the node resides in “mounts” and serves to inform the automounter about where the network resource is and where it should appear on the local machine. Run the following commands in the terminal, substituting the appropriate computer name for “danielG5.local”:
sudo nicl . -create /mounts/danielG5.local:\\/Library\\/MyNetworkShares\\/Library sudo nicl . -append /mounts/danielG5.local:\\/Library\\/MyNetworkShares\\/Library type nfs sudo nicl . -append /mounts/danielG5.local:\\/Library\\/MyNetworkShares\\/Library dir /Network/Library sudo nicl . -append /mounts/danielG5.local:\\/Library\\/MyNetworkShares\\/Library opts ""
And another visual confirmation from NetInfo Manager puts me at ease:
Again, rebooting is probably the safest way to ensure that the changes are picked up by the automount daemon, but since automount is normally running by default, you should be able to simply restart the daemon:
sudo kill -1 `cat /var/run/automount.pid`
Go ahead and try it out – navigate in the Finder to /Network/Library. You should see the contents of “/Library/MyNetworkShares/Library” from the server computer. I have found the Finder’s concept of /Network to sometimes be a little flakey, so if it doesn’t seem to be working, try changing to the directory from the Terminal instead. I think this kind of thing irons itself out after a reboot. Once you’ve got it wired up, you can start putting junk in the folder that you want to have at your disposal on all machines on the LAN. Fonts, Scripts, etc. If an application doesn’t behave as you expect it to with the Network domain, let the application’s author know (in fact, FastScripts could benefit from a few tweaks to improve its functionality, though it basically works). This is a powerful and very cool infrastructure that more of us should be taking advantage of.
Simplifying the Process
If repeating this process on all the clients in your LAN sounds daunting, fear not. A real network administrator would probably have some kind of sophisticated NetInfo hierarchy through which she could easily manipulate the “mounts” values for all of the machines in the network, but I’m going to assume you’re like me and are just hacking together a solution for a few machines in your house. We can use the “nidump” and “niload” commands to essentially copy and paste the successful settings from one client to another. First, obtain a raw text format copy of the mounts data:
nidump -r /mounts . > MyEasyMounts.txt
Now take that text file to whatever client you like, and load it into that client’s NetInfo database:
sudo niload -m -r /mounts . < MyEasyMounts.txt
Don’t forget to either reboot or confidently reset the automount daemon again.
The process described above can be repeated for other top-level Network domain folders like “Applications.” Just make a different folder on the server and add appropriate exports and mounts entries to the server and clients. Have fun, and enjoy your Network domain!
March 23rd, 2006 at 5:26 pm
Thats a great howto. Have you worked with WebDAV yet? From what I can tell, it results in a similarly mounted folder that looks the same to the OS with less hassle on each user’s end (just give them a URL) and a bit more hassle on the one server system (install apache-2.2.0 using Darwin Ports, comment in the DAV conf file and modify to suit). The only thing I haven’t done much digging into is getting a WebDAV folder to automount without doing something simple like putting a folder alias in startup items.
A couple more advantages are that you can get at it easily from anywhere (assuming you can see the web site serving the DAV folder) and you can enable SSL on the web server to keep you password and files secure during transmission. It also saves you having to run all the NFS stuff which has always been a bit of a hacker magnet. That might be less of an issue for a little shop behind a firewall.
I would guess that performance might be a downside, although I haven’t run any tests. Just guessing based on the designed intent of the underlying protocols.
Anyway… I saw your post and thought that perhaps WebDAV might be the way forward for something like this. It has gotten much easier to set up.
March 24th, 2006 at 6:28 am
Best /Network feature EVAH is /Network/Library/ – so you can put “enterprise”-wide fonts, preference plists and so forth in one place and all your users on all your machines get to see them…
March 24th, 2006 at 6:31 am
erm, I curtailed myself there. What I was going to say *was*: now that the /Network/Library is set up, you can do this:
admin@nfsserver:~> touch /Library/MyNetworkShares/Library/Preferences/com.apple.TextEdit.plist
admin@nfsserver:~> defaults write /Library/MyNetworkShares/Library/Preferences/com.apple.TextEdit RichText 0
if all your users ought to get plain-text mode by default in textedit, for instance. Individual users can override in their own ~/Library/Preferences; but you’ve just set a network-wide default :-)
March 24th, 2006 at 8:55 am
[…] Daniel Jalkut: […]
March 24th, 2006 at 11:33 am
Great post, Daniel. I always wondered about that whole Network domain thing.
One thing is still unclear to me. Is there any kind of authentication needed? I suppose not, from the post, and I also suppose there are more Netinfo options to control who gets access. Then I also suppose any of the files that you put there are read-only? Or probably better: it all depends how you set the permissions on the files in your export folder.
Anyway, thanks again for this excellent tutorial!
March 24th, 2006 at 11:43 am
Thanks for your comments. Here are some responses in order:
Amos: WebDAV is an interesting possibility. I haven’t looked into it, but I think the autmount system on Mac OS X system may be capable of mounting arbitrary volumes as long as they have a corresponding “mount_*” command in /sbin. Definitely worth looking at in more depth since using an AFP server could also be interesting.
leeg: Yep – exactly that kind of stuff is what makes this so exciting, especially from a LAN administrator’s point of view. Granted, the true LANs probably have a Mac OS X Server machine running somewhere, which makes all of this a lot easier, but for us small-time LANsters, we can still accomplish a lot of fun stuff.
Charles: The authentication scheme for NFS is interesting, and there are major caveats that I probably should have alluded to in the main post. I don’t really understand it all that well, but the gist of it is that NFS assumes a consistent uid scheme across the entire LAN. So permissions are handled on a purely “uid” basis, and every client on the LAN has their uid respected. So if you and I are on the same LAN and we are both uid 501, then I believe our access to a file owned by uid on an NFS volume is identical. At Apple we used NFS-mounted volumes for our home directories. Our accounts were assigned uids from a central authority, and they were all well outside the range of common (allowed?) uids for local accounts. So if you attempted to use an NFS volume with a local account, you could get conflicts, but as long as you used your “one true account” as assigned by the NetInfo administrator, your files were (relatively) safely your own.
The “maproot=nobody” option set in the export configuration above is supposed to at least protect the root uid from being respected across the NFS exported network.
March 24th, 2006 at 12:24 pm
This is something I’ve wanted to do since OS X 10.1. Thanks very much…
However..I’ve moved a medium number of fonts over to the /Network/Library/Fonts directory and I don’t see them listed in the Network domain in Font Book and I can’t thus enable the Network domain in Font Book. Hmm.
Permissions seem OK…I can list the directory in the terminal with ls /Network/Library/Fonts on all machines…
Applescripts show up in the menubar menu on all machines. Dunno…?
March 24th, 2006 at 1:03 pm
Ah, a complete restart (not just a logout or a sudo kill -1 `cat /var/run/automount.pid` was needed.
Um..nevermind, sorry.
March 24th, 2006 at 1:10 pm
Hmm – yeah chalk that one up as a bug in Font Book, I’d say. I had the same experience as you, even though my network domain had been active since yesterday. I didn’t have a Fonts folder, so I added one and tested it out. Sure enough, I had to reboot before Font Book would allow me to enable it. Now it seems to work like a charm.
March 24th, 2006 at 3:03 pm
Um, this is a very, very old-style NeXT-y approach that requires modification of each individual client’s local NetInfo database and the use of NFS automounts. Mac OS X can get this information from a directory service (think LDAP or network-based NetInfo) and use AFP automounts which are nicer to resource forks and more secure. For most of this sort of thing, you would want the options mapall=nobody and readonly on the NFS export as well — remember that anyone who has administrative access on a client can spoof a UIDNumber.
Apple makes this easy using Mac OS X Server. There’s a how-to level treatment in the book Mac OS X Server Essentials: A Guide to Using and Supporting Mac OS X Server 10.4 (Apple Training Series) and there’s a great deal of detail on the internals in the book Mac OS X System Administration Reference, Volume 1 (Apple Training Series), which are based on the Apple tech training courses.
Please look into the details of a how this works before you try it for real on a full network of machines. The approach in this how-to is not scalable and will be a maintenance nightmare down the road.
March 24th, 2006 at 3:56 pm
Thanks, Paul. That sounds like good advice. I probably should have added caveats that I don’t really know what I’m doing. I just figured out the NFS solution and thought it was interesting enough to share.
I don’t think the Mac OS X Server solutions are useful to most of us who just want to take advantage of this on a small home network of machines. I have found the Server documentation to be enlightening in that it sometimes hints at how a similar service might be run on Mac OS X Client, but most of the documentation describes processes that require Server-specific applications and command-line tools.
Do you have any other pointers for where we can get up-to-speed on Directory Services?
March 24th, 2006 at 4:10 pm
Thanks for the how to. I managed to get my fonts running on my old G4 development server. Is NetInfo Manager scriptable? I mean with Applescript. There has to be an easier way to do this without buying OS X Server.
March 24th, 2006 at 4:16 pm
Michael: NetInfo Manager is not scriptable, and it sounds like NetInfo in general is being phased out at Apple. I can see why making it scriptable wouldn’t be a high priority even if it were sticking around for the long term, because everything you can do with the application can be done using corresponding command-line tools as demonstrated in this entry.
March 24th, 2006 at 7:31 pm
I agree with Paul. Tiger Server makes the process of setting of DNS, which in turn allows you to use Open Directory and then do Network mounts much easier. Plus, you’ll be using Kerberos and you get all the tasty authentication stuff. NFS doesn’t offer any sort of “real” authentication and AFAIK, it relies on trusting IP addresses. Open Directory allows you to use AFP and you get true authentication. Plus the lovely granularity of Access Control Lists. Yes, I’m enthralled
But, yes, on a small network, doing NFS/NetInfo stuff could be nice.
March 24th, 2006 at 9:37 pm
I highly recommend the shareware NFS Manager (fully-functional free demo, with only demo popups):
http://www.bresink.de/osx/NFSManager.html
Its from the same author of TinkerTool. Its a GUI frontend that allows point-and-click customization of NFS exports and mounts, and just updates the Netinfo database with the relevant info. Use it for a day, and learn all the Netinfo commands easily. Like allowing only certain IP addresses access, etc.
Now, why OS X can’t map uids, like linux can, is beyond me. For this reason, all users must have consistent uids across multiple computers. Arghh! Its much easier to specify an NFS opt of mapuid 501:505, which says user 501 from the client computer should be 505 on the server computer.
March 24th, 2006 at 9:54 pm
My favorite implementation of NFS on OS X in a family household is the following. On the NFS server, create a separate partition or disk and turn off the file ownership for this volume (via its Get Info window). Then export it as NFS (export /Volumes/Shared Disk), and mount it on all the other computers. Put your iPhoto library, iTunes library, iCal database, and Address Book database on this volume on the server. Now symlink to each of these databases in the mounted folder on every computer, from the location where OS X expects to find the databases (~/Pictures, ~/Music, etc.)
Viola! Seamless iPhoto, iTunes, iCal, and Address Book sharing far better than the Bonjour implementation. Why? Because all users on all computers can edit these databases (add/remove entries, etc.), assuming you turned off file ownership.
March 26th, 2006 at 7:09 am
Sheesh!
I run a small architectural office, and we all need to share files from our Projects ‘Server’, which is really a G3 iMac running Tiger!
Easiest way I have found to do this is by using an alias of the folder containing the projects, and drop this alias into local Finder sidebar. Then, when a user wants a project file, she clicks on the alias, and- whattayaknow- the remote volume mounts and all of the project folders appear. Hello, OS9!
There are 4 local users with this system [and 4 more, using the excellent Rumpus], and so far it’s been quite useful.
Can you use it for stuff like plist files? nope. Does sharing fonts and plist and whatever appear attractive? yep. [btw iTunes will resolve an alias to a remote volume so possibly other apps will as well]. Do I ever ever EVER want to screw around with this? nope.
For the small guys like us, it’s just easier to install all the fonts on all the machines, for example; and as to default settings, well, if people screw around with the defaults I beak thier fingers. The fingers on the hand not needed for the mouse, that is.
Michael
March 26th, 2006 at 7:30 pm
Daniel: Definitely look into the second book I recommended as a reference — it has a huge amount of detail on MOSX/MOSXS directory services internals.
Caveats – I have been an instructor for Apple’s Directory Services tech training class many times; the content in the book is taken from the class. Also, I am one of the contributing authors for the security section of the book, but no I’m not getting any money for it — I wrote those sections while I was working at Apple, but I just left to form my own consulting company.
–Paul
March 27th, 2006 at 4:45 am
The main problem with NFS is the ‘uid clash’ issue, especially as every user is likely to be UID 501 before you set this up :-). However, you *can* use kerberized NFS (never tried it, certainly wouldn’t be straightforward under client OS X), or you could just specify that the mount be read-only, so that it can only be modified on the server box. Add the value “ro” to the options property, IIRC.
April 16th, 2006 at 4:06 am
Well, speaking about my experience, this nfs thing is really-really bad idea. It does not fail gracefully at all. I did setup one nfs and one afp automount and both work as expected (btw, static mounts), until network disappears. As I have some laptops here too, I tested the setup by pulling network cord out. The result is that those nfs mounts froze my Finder for a 5 minute and gave me a dialog box to choose: try reconnect or disconnect. Try reconnect means another 5 minutes of frozen Finder, so i pressed disconnect. Afp mount meanwhile just informed that server is gone, press ok. Allright, time to reconnect network cord. Afp mount connects momentarily, after I click network/sharename, but not nfs – “The alias Library could not be opened, because the original item cannot be found”. And this is permanent, until I kill that automount in terminal. In the end it is just stupid to advise your stuff, that they must restart to use nfs shares again if for example, server disappears and you did press disconnect to get Finder back….
So my advice – stay away from nfs, use afp instead, works like a dream.
April 16th, 2006 at 7:52 am
Thanks, Priit. I just have to learn the magic combination of automount flags to get AFP to work correctly. Any advice?
April 16th, 2006 at 10:10 am
Yes,
first, I did set all our network computer names in SDSL router’s DNS section, so i’m not using bonjour’s .local names and i have set my DNS domain from deafult “lan” to “domain.ee” (well not actually “domain” :-) )
name server.domain.ee:/Share
vfstype url
dir /Network/Share
opts url==afp://username:[email protected]/Share
and then that kill and you have link Share under Network. Before writing this, I did set up things on my laptop to and as I’m not at work, so all I have is just dummy link under Network. Click does nothing. Splendid :-)
PS! Do set some username/password on afp share, although I have free guest access, I never got those afp:// links to work without creditentials. Maybe I did miss something….
April 17th, 2006 at 1:23 am
There’s is a chance I scremed too early :-) Some preliminary and strange problems accured today :-( More specific later…
April 29th, 2006 at 1:41 am
What about SharePoints AutoMounter?
From the page below: “SharePoints AutoMounter is an application that makes it easy to add and delete auto mounts in the /Network directory.”
http://www.hornware.com/sharepointsautomounter/
October 21st, 2006 at 11:42 pm
[…] Originally Posted by samsontan currently, i’m runnin on router ethernet modem with 3 other windows OS.. still normal right? not to worry? Here’s a nice description of what that library folder means. Check it out! __________________ Ryan Price http://www.ryansdesigns.com […]
February 19th, 2007 at 1:28 am
Thanks, for detailed explaination.
March 15th, 2007 at 4:17 am
your blog is very nice,
this is my blog : http://gdieboss.blogspot.com/
Can you teach me how to make a better blog
thanks
May 19th, 2007 at 8:08 pm
NFS requires unique user ids as is what that damn name UID
means. So the first system admin task is to ensure uniqueness
whatever that entails possibly netinfo shared domain?