Using Microsoft’s Services For UNIX to serve NFS home directories

Get Windows to play nice with your OS X clients using NFS

AD integration works reasonably well for Mac OS X clients, but what if you’re running, say, an XServe G5, and you need to provide access to Windows-based home directories for multiple command-line users (via ssh, telnet, etc.) on your server simultaneously?

updated 3/29/05: fixed missing whacks in Windows paths.Ed. Note: While it’s perfectly possible to host user homes over SMB from a Windows server, you may want to explore using NFS. Especially if your users are more Unix-focused NFS will be more familiar, plus it will allow fast user switching with network homes. Some admins also favor NFS for its ability to allow scripts and other automated functions to have an easier go of it when accessing network storage.

Enter Microsoft’s Services For UNIX (ignore sounds of mass hysteria, shrieking and general running away). SFU (purportedly) makes a Windows server act like a UNIX host. See http://www.microsoft.com/sfu/ for the details. It actually works reasonably well, and I must say it’s refreshing to be able to use UNIX commands (even vi) on an otherwise-annoying Windows server. SFU makes schema additions to Active Directory, so it has to be installed on an AD controller at some point, as well as on the desired fileserver. Configuring SFU is non-trivial, and this article will detail only the general procedure for making it work. Be sure your Windows sysadmin is heavily involved in this process.

For purposes of this article, I am going to pretend that your user home directories are in a folder called

<code>d:users</code>

which is shared out as

<code>&#92;servernameusers</code>

(or, in legitimate URLese, smb://servername/users).

Install SFU on the AD controller, choosing to use remote user name mapping services and setting the remote user name mapping server as the AD controller itself (you’ll configure username mapping later). Open the Services for UNIX Administration application. Configure User Name Mapping as desired; the easiest option is to use simple maps to map the Windows domain to an NIS-style UNIX domain (you can use the same domain name). Next, open the Active Directory Users and Computers application, and create UNIX attributes (you’ll notice the UNIX Attributes tab that was added to the properties window by SFU) for any users who need NFS access. The only necessary values for our uses are the UID and the NIS domain. Open Services and be sure that the User Name Mapping service is set to start automatically. Finally, edit

<code>c:sfumapper.maphosts</code>

and add the name of the Windows host that will serve as your NFS fileserver–or just add a + (plus sign) on a line by itself at the end of the file to allow any clients to access the name mapping service.

Install SFU on the to-be-NFS server, choosing remote user name mapping and setting the remote user name mapping server to the AD controller you’ve just configured. Open Services and be sure that the Server for NFS service is set to start automatically. Open the properties window of a folder you want to share via NFS, click the NFS Sharing tab, click Share this folder and check the Allow anonymous access box. Name the share the same as the Windows share name (in this case, users), so that NFS home directory paths will match the SMB home directory paths in AD. Click the Permissions button, set ALL MACHINES to No Access and add (by hostname or IP address) any UNIX hosts that should be able to access this share. Permissions should be set to Read-Write with the Allow root access box unchecked.

Now, a word about permissions. As part of the POSIX subsystem, SFU installs the standard UNIX chmod and chown utilities to the system. Do not use them! These utilities do not grok Windows ACLs, and using them will wreak havoc with any existing file/folder permissions. This sad fact is mentioned in the bowels of the SFU documentation, but it ought to be in the README, in large red boldface type. This leads to a problem, though, because any files/folders that already had ACLs prior to the installation of SFU will not have any POSIX permissions at all–thus, no access via NFS. The correct way to fix this is to simply re-apply all existing ACLs to the files/folders using the standard Windows security tools. This will update the POSIX permissions of the files/folders.

For home directories, you will want to make each user the owner of his respective home directory and all its contents. Microsoft says that the administrator can’t make this change, but Microsoft is wrong (is it wrong to enjoy saying that?). Download chown.exe from http://wwwthep.physik.uni-mainz.de/~frink/nt.html and use a command something like the following (logged in as a domain admin)–and yes, it works on Windows 2003 Server:

<code>
chown.exe -r &lt;username&gt; d:users&lt;username&gt;*
</code>

Enough with Windows already. On Mac OS X Server, open Directory Access and enable the Active Directory plugin. When you bind to your AD domain, under Advanced Options check the Map UID to attribute: option, and enter msSFU30UidNumber in the blank. This will force MOSXS to use the UID value from SFU’s AD schema additions, which will cause NFS file permissions to work properly.

Next, create an automount entry in NetInfo to mount the NFS home directory. Mike Bombich, as usual, has a very nice instruction page for this at http://www.bombich.com/mactips/automount.html. You want to create a dynamic NFS entry, in this case servername:/users.

Reboot, and you should be good to go.

jgardner

More Posts - Website