Setting up a server
Setting Up NFS on 10.6 server OS
WARNING: The apple documentation for setting up an NFS server is wrong. The Server admin tool on 10.6 server is broken and will never produce a work NFS 2 or NFS 3 server. Also the /etc/netgroups is crippled and the documentation specifies an incorrect format. Additionally, the Xgrid configuration wizard creates an NFS security hole.
Steps to produce a working NFS Server
NFS2 and NFS3 protocols require 6 ports. (NFS4 can work over a single port?--need to document)
using the Server admin tool
- Use the GUI server admin tool to create an NFS share following the documentation
- Open the NFS port and Portmapper ports in the IPFW firewall (111, and 2049)
- add the following text to end of the existing /etc/nfs.config
# The purpose is to allow firewall ports to be open nfs.lockd.port = 1020 nfs.statd.port = 1021 nfs.server.mount.port = 1022 nfs.server.rquota.port = 1019
- create a custom entry in the IPFW for those 4 ports (1020,1021,1022,1019) an open them. select UDP and TCP.
- Hupping or otherwise restarting the NFS service is needed to get it to read the new config file. or Reboot if this malfunctions.
These steps correct a bug in the Apple GUI server admin tool: it fails to do the key steps of opening firewall ports and pinning the RPC service ports for you. By default these (inbound) port number fluctuate and thus the NFS it configures will never work on a 10.6 server unless the firewall is off or you are only trying to serve to the localhost.
If those four ports conflict with other services on your computer, then a recipe for finding unused ports is here. The chosen ports may be any unused ports under 1024.
Doing it by hand
The apple GUI tool is not needed. It's very easy to create a simple NFS export by hand.
After you pin the RPC ports as described above then edit /etc/exports to add this line:
/Volumes/MacHD/somefolderpath -mapall=nobody -sec=sys host.name.one host.name.two host.name.three
where host.name.one and so on are the names of the computers you want to export to. Finally type:
/sbin/nfsd start /sbin/nfsd enable
start starts the server. enable makes the change persist past reboot. This should put nfs into the launchD at boot time. There are many options for nfs export. Two are shown above. First, the security type is set to the default one (it was not necessary to specify that), and second I have mapped all users to the Nobody user. That may not be an option you want to use but read the pitfalls below to understand why you want to at least start off this way.
Using a third party GUI tool
Instead of doing it by hand, Breslink.de offers NFSMananger a complete tool for configuring an NFS server. Like this fabulous website, the amount of time NFSManager will save you is likely very much worth its cost. Even if you end up using the Apple tools or doing it by hand, this tool can help you make sure you are not overlooking something.
Any computer can interrogate a server for the mounts it exports with:
showmount -e remote.nfs.server
If you don't get a response, then your NFS client is having trouble reaching the server. It tells you if your client is on the list, and the name/path of the exported directories to check against the corresponding auto_master descriptor. Also note that this handy NFS feature inadvertently leaks some information that, while not a vulnerability in itself, could be weakly valuable to an attacker profiling a network for its weaknesses: a list of network host names and the fact that they probably mount this file system.
- In the process of setting up an NFS share it's convenient to temporarily drop the firewall to avoid any complications. However a trap here is that when the firewall is put back up it is possible that the NFS share will continue to work for some time (> ten minutes) even if the firewall is misconfigured. For example, the RPC connections that exist at the time the firewall is raised may be statefully preserved as open ports. Eventually, a quiescent NFS releases those ports and firewall closes the ports. Client then cannot connect.
- Xgrid configuration wizard in the Server Admin gui, silently opens an NFS share on the local hard drive that is open for read/write to the universe. Fortunately the broken NFS configuration prevents this security hole from getting past the firewall! This security hole was reported to apple who subsequently closed the report as "operates normally", so it is likely to persist in future OS releases. The hole is easily fixed by deleting the line for the share from /etc/exports. Apparently this stealth shared file system is required for apple's xgrid using tool PodCastProducer.
- One reason to use mapall=nobody is because when you let clients use their true user ID one bugaboo is that unlike AFP, the numerical UID of the users attached to the file is the one for the remote user not the local user who might happen to have the same username. That is, one client computer you might have bob(501),sally(502) and Dave(503), and on another client computer you have Sally(501) and Dave(502). Files written by Dave(502) from the second computer are marked with UID 502 and thus accessible to Sally(502) on the first computer but not to Dave(503) on the first computer! NFS allows per-user UID mapping but it's a bit of headache, so a global map to nobody may be more satisfactory. NFS has many tricky security issues to ponder and unless you have thoughtfully planned the UID assignments on your clients you need to map them in the export command on the server to avoid chaos.
- Apple's NFS implements global flie locking. In some applications this is not needed. If so specify "locallocks" in all the client NFS mounts. This should actually speed up the transfers as well, but has the negative side effect that two clients can no-longer synchronize their reads and writes to the same file via the NFS locking mechanism.
- In 10.6 OSX, extended attributes on files are heavily used and get applied to them by background precesses like Spotlight and Finder even if you are not intending to use them. HFS extended attributes are emulated when transferring files from an HFS disk to an NFS disk. The way these are implemented requires a lot of slow locking overhead. To avoid that you can use the localocks mount option or you can use methods of copying that ignore the extended attributes such as "cp -X", and cpio. You can strip files of their extended attributes using "xattr -d -r" but this will only remove one specifically named attribute at a time; moreover that fix is temporrary since things like spotlight, finder, or editors may add the attributes back at a later time. To view extended attributes and acls use "ls -lOe@" (yes, that's not a typo: the "@" symbol is used as a flag). You can hunt these recursively in a sub directory using "xattr -r directoryname".
Netgroups are a convenient shortcut for naming sets of servers that nfs can refer to in the /etc/exports file by this name. The Man page for /etc/netgroups specifies a tuple format which would allow server specfication to also be conditioned on export to specific users on each host. Unfortunately this does not seem to be implemented in OSX 10.6 server.
Instead the empircially determined undocumented format is simply to have single lines starting with the alias name then a list of hostnames or IP addresses separated by spaces. A new line separates each group alias. and comments begin with #.
Setting up SMB or AFP
Nothing here yet but this is relevant http://www.macosxhints.com/article.php?story=20100203124656707 One thing to be aware of is that one needs chmod 600 the /etc/auto_smb file to avoid exposing a password. Or follow this hint to encrypt the password http://www.macosxhints.com/comment.php?mode=view&cid=3658&query=mount+smb