Integrating Mac OS X in an NIS network

Revision as of 15:31, 28 July 2019 by Netfreak (talk | contribs)

Marcel Bresink

Managing Director
Marcel Bresink Software-Systeme

 

Abstract

This document provides information about how to integrate Mac OS X version 10.2.5 or later in an NIS network. Among other features, it becomes possible to login to Mac OS X based on NIS user account information and to use distributed NFS file systems including automounts.


Table of Contents

Introduction

Updated versions of this document
For which versions of Mac OS X is this information valid?
Disclaimer and Trademark Notice
Feedback and Corrections

General Information

What is NIS?
Does the use of NIS restrict my rights on the Mac OS X system?
Basic NIS terms

How to enable NIS

Prerequisites
Checking NIS access without modifying your system
If the check failed
Activating NIS access

Advanced configuration options

Which system components query which information sources?
Defining the search order for information categories
Detailed diagnostics with lookupd

Using automounters

What are automounters?
Special features of Mac OS X
Setting up the Mac OS X automounter
Creating a compatible mount map on the NIS server
Meaning of the "net" option

Frequently Asked Questions

The NIS server is running an up-to-date Unix version
Does Mac OS X support shadow passwords with NIS?
Are there known problems with NIS support in Mac OS X Jaguar?
Are there known problems with NIS support in Mac OS X Panther?
Are there known problems with NIS support in Mac OS X Tiger?
Does Panther need the NISDOMAIN setting in /etc/hostconfig?
I disconnected a pre-Panther computer from the network. Now Mac OS X freezes during startup waiting for the NIS server. How can I deactivate the binding?
I want to become member of the administrative "wheel" group
NIS works fine but some users with NIS accounts still can't login
Can I use NIS-based automount tables to define static NFS mounts?

 


Introduction

Mac OS X is based on Darwin, a special flavor of the 4.4BSD Unix operating system. As such, it can be integrated easily in a network of other Unix systems.

In a computer network, the different machines have to share administrative data, like user names and access permissions. Mac OS X can use NeXT's NetInfo technology, or directory servers based on LDAP to distribute this information throughout the network. Those features are based on Apple's Open Directory architecture. Classic Unix networks however, mostly run the Network Information Service (NIS) to distribute that data. This document tries to answer questions about setting up NIS on a Mac OS X machine. This enables the machine to easily access files on Unix systems which are not using NetInfo or LDAP.

 

Updated versions of this document

The latest version of this document will always be published on the world-wide web via the address http://www.bresink.de/osx/nis.html.

 

For which versions of Mac OS X is this information valid?

The information in this document is valid for the following operating systems:

  • Mac OS X 10.2.5 to 10.2.8
  • Mac OS X Server 10.2.5 to 10.2.8
  • Mac OS X 10.3 to 10.3.9
  • Mac OS X Server 10.3 to 10.3.9
  • Mac OS X 10.4.3, 10.4.4, 10.4.5, 10.4.6 (note comments below)
  • Mac OS X Server 10.4.3, 10.4.4, 10.4.5, 10.4.6 (note comments below)

The document cannot be used to configure older releases of Mac OS X 10.2 "Jaguar". If you use a "pre-Jaguar" system, you'll find detailed instructions at http://www.bresink.de/osx/nisOLD.html.

NIS should not be used with Mac OS X versions 10.4 to 10.4.2 or 10.4.7. to 10.4.8 because these releases have too many technical defects to be of use in a heterogeneous network.

Automounting techniques which make use of file service protocols different from AFP should not be used with Mac OS X versions 10.4.9 to 10.4.10 because these releases have too many technical defects to be of use in a heterogeneous network.

 

Disclaimer and Trademark Notice

While reasonable efforts have been made in the preparation of this document to assure its accuracy, the author assumes no liability resulting from errors or omissions in this document, or from use of the information contained herein.

Naming of particular products or brands should not be seen as endorsements. Trademarks or service marks are used for identification purposes only. Apple, Macintosh, NeXT, NEXTSTEP, OPENSTEP, and NetInfo are registered trademarks of Apple Computer, Inc. Unix is a registered trademark exclusively licensed through X/Open Company, Ltd. Sun, Sun Microsystems, Solaris, and NFS are registered trademarks of Sun Microsystems, Inc. Linux is a registered trademark of Linus Torvalds. SuSE is a registered trademark of Gesellschaft für Software- und System-Entwicklung GmbH. Other marks or trademarks are registered trademarks of the companies with which they are associated.

 

Feedback and Corrections

If you have questions or comments about this document or find a mistake, feel free to send e-mail to Marcel Bresink, [email protected].

 

General Information

What is NIS?

NIS is the Network Information Service, a technology developed by Sun Microsystems. NIS allows multiple computers in a local area network to share administrative data. This data is collected in a central database and then distributed around the network. Nearly all operating systems based on Unix use –or can use– NIS.

On Mac OS X however, NIS is disabled by default. The system instead uses NetInfo, a technology developed by NeXT, or LDAP, a network protocol that was internationally standardized to share administrative data. For an end user there isn't much difference between NetInfo, LDAP and NIS. They basically do the same job, only the implementation and some concepts are different. Services of that kind are called directory services.

The first versions of NIS were called Yellow Pages (YP). Because Yellow Pages is a registered trademark for a telephone directory in some countries (in the UK, Yellow Pages is a registered trademark of British Telecom plc), Sun Microsystems was forced to give up that name. Note that all utility programs and system functions which are part of NIS still have the prefix "yp".

Most system administrators use NIS to distribute user information to the machines on the network. This enables every computer to know each user's login name, his or her password, the location of the home directory and so on. NIS can also be used as an inventory, as a source for the resolution of IP addresses, or many other information that should be available to every machine of a local area network.

NIS has a successor system called NIS+ or NIS Version 3. One of the main differences between NIS and NIS+ is that the latter uses data encryption to be more secure. It also offers better support for very large installations (more than 10,000 users, for example). At the time of this writing, Mac OS X cannot be used with NIS+, so only NIS is described in this document.

For obvious reasons this document cannot give a complete introduction into the world of NIS. The standard text-book on NIS is Hal Stern: NFS and NIS, O'Reilly, Cambridge, 1995.

 

Does the use of NIS restrict my rights on the Mac OS X system?

No. If NIS is configured correctly, it is only another source of administrative data. It just provides additional information that coexists with your NetInfo database or other directory services. You can use NIS and NetInfo simultaneously without any problems. Of course you should avoid keeping contradictory or otherwise inconsistent information in the different databases.

If you enable NIS on the Mac OS X system, you won't lose any local permissions you already have. For example, if you are the local system administrator (root), you will still have administrative rights on that system after NIS has been switched on. The NIS information is only added to your system. Another consequence is that your NetInfo data does not take precedence over network NIS permissions. So if you are administrator (root) on your own Mac OS X system, you won't automatically become administrator of any other machine on the network.

As mentioned above, you never should have contradictory data in NetInfo and NIS. For example, if you have the user id 502 in your local NetInfo database, but a different user also has the UID 502 in NIS, this can be a source of trouble and security problems. Unix security and the organization of consistent permissions go far beyond the scope of this document, so this won't be discussed here.

Basic NIS terms

To better understand NIS, some specific terms have to be explained. The computer system on which the central NIS database is kept, is the NIS master server. The other computers on the network accessing the database are called NIS clients. A computer can be client and server at the same time, so it can ask itself about entries in the database.

There can also be computers providing backup copies of the database. These are called NIS slave servers. A slave server can take over the role of the master, if the master is shut down, crashes, or has network communication problems. Slave servers are also used for performance reasons: When a master server is too slow in responding to requests, an NIS client can connect to one of the slave servers to get better response times. NIS automatically makes sure that all slave servers are holding up-to-date information. The data is pushed from the master to the slave servers if changes are made in the central database, so information is always synchronized. On small networks, NIS slave servers aren't really needed.

A local area network can logically be divided into different "NIS zones", where each zone uses a different database. These zones are called NIS domains. Each domain needs its own NIS master server, but there are no restrictions which of the machines is made master for which domain. For example, you can have a machine that acts as two NIS master servers for two different domains. You only have to make sure that each NIS client knows to which NIS domain it belongs to. For that reason, each NIS domain needs to have an NIS domain name identifying it. This name is always needed, even if you have one single domain in your network only.

NIS domain names have absolutely nothing to do with internet domain (DNS) names. Nevertheless, many system administrators just use the same name for NIS and DNS to avoid confusion. Other administrators just try to avoid this, to make it more difficult for network intruders (crackers) to guess the NIS domain name and steal database information.

By using the NIS domain name, an NIS client searches an appropriate NIS master or slave server, usually at boot time, and establishes a connection with the server's database. This process is called binding to the NIS domain.

The NIS database can offer different "tables" of information, for example a list of all users that can access the network, or a list of all machines that are part of the network. The different tables are called NIS maps. Each map has a name identifying it. There are some predefined standard names that are used in every NIS implementation. For example, the NIS map holding the list of users sorted by user IDs is always identified as passwd.byuid. A list of predefined map names that will be recognized by Mac OS X is given later in this document. Like in a standard database, the NIS administrator is free to add additional tables (NIS maps) and to choose new names for them.

 

How to enable NIS

Prerequisites

You must be member of the administrator group to enable NIS on Mac OS X. You also need to know the name of the NIS domain the client should bind to (see "Basis NIS Terms"). We assume the following conditions to be true:

  • The system has been installed completely and is physically connected to the network.
  • TCP/IP networking, including host name resolution, is working fine and you didn't alter the default IP settings. (For example, you didn't disable important sysrtem services or change the portmapper configuration.)
  • At least one NIS server of the domain you want to join is currently running.

 

Checking NIS access without modifying your system

You can do a "pre-check" to see whether your system can actually connect to the NIS database. Because we do not change any file, this will be a temporary connection only. If you should see a problem with NIS, you can simply reboot and your system will still be working fine because nothing has been changed. This test is recommended if you want to play it safe, but you can also skip to the paragraph Activating NIS Access if you like.

  1. To begin, launch the Terminal application and enter the command

    rpcinfo -p

    to check if the RPC portmapper is running. This service is needed to "speak" to an NIS server. If the portmapper is not running, you'll get the message

    rpcinfo: can't contact portmapper: RPC: remote system error - Connection refused


    To solve this problem, enter the command

    sudo portmap

    if you are using Jaguar or Panther. If you are using Tiger, enter the command

    sudo launchctl start com.apple.portmap

    instead. Then repeat the "rpcinfo -p" check. If everything is OK, you should see output similar to this:
       program vers proto   port
    100000 2 tcp 111 portmapper
    100000 2 udp 111 portmapper
    In some cases, more lines will be displayed but this is irrelevant. You should only make sure that the portmapper really is running before continuing. This means at least the two portmapper lines must be displayed, similar to those in the example.
  2. Enter

    sudo domainname mydomain.nis

    "mydomain.nis" has to be replaced with the name of the NIS domain your system should bind to. Remember that the NIS domain name may be identical to the Internet domain name (DNS) but in most cases is not. Ask the administrator of the NIS server if you don't know the name. Note that the system will ask for your password for security reasons after you have entered the command.
  3. Type the command

    sudo ypbind

    The ypbind program searches for a NIS server on your sub-network and binds to the domain you have specified in step (2). This should take less than a few seconds. If you are not returned to the prompt after more than 10 seconds, something might have gone wrong. Depending on network configuration this does not necessarily indicate an error condition. In this case, press Ctrl-C to stop ypbind, and read the next paragraph "If the check failed".
  4. Now we like to know to which NIS server we are connected. We can get this information by entering

    ypwhich

    You should see the name of the NIS server your computer is currently connected to.
  5. Now we can try to access the NIS database. Most likely your NIS server offers an NIS map with the name group. This map holds the table of user groups known in the local network.Issue the command

    ypcat group

    It will give you the list of all known NIS user groups.

    NOTE: The map's name is actually "group.byname", "group" is just an abbreviation the NIS system is aware of.

If everything is working as expected, you can continue and make the changes to your system permanent.

 

If the check failed

You only need to read this section if the NIS check has failed. To continue NIS installation, skip to the next paragraph.

We try the ypbind operation again, but are going to use debug mode now to see what happens. Enter

sudo ypbind -d

You should receive status messages that show what ypbind is doing and why it might fail. Here is a list of common error messages and typical causes:

  • unknown domain mydomain.nis: a NIS server was found but it doesn't know the NIS domain name you have specified. Check the name and reenter the domainname command.
  • dead domain mydomain.nis: a NIS server was found and it knows the domain name you've specified. However, this domain is currently marked inactive and cannot be used. Check if you should specify another domain and repeat the domainname command with its name.
  • Domainname not set. Aborting: You forgot or mistyped the domainname command. Enter it correctly and repeat the test.
  • /var/yp/binding/mydomain.nis.ypservers does not exist, defaulting to broadcast: The system has sent out a broadcast message to search for a NIS server, but no server has responded. This can have different reasons:
    • The NIS server is not running: Make sure that the NIS server really is there. If you know its name, you can use the ping command to see if it's alive.
    • The NIS server and your machine are in two different IP subnets: In this case it's impossible that your machine can find the NIS server automatically. Create a file /var/yp/binding/mydomain.nis.ypservers that contains the IP address(es) of your NIS server(s). You have to replace "mydomain.nis" with the correct name of your NIS domain
    • The administrator of the NIS server disabled server recovery through broadcasts for security reasons: In this case, do the same as in the "different IP subnet" situation.
    • There is an error in the IP netmask of your ethernet interface: Enter ifconfig -a to get a list of all your network interfaces and check whether the netmasks are set correctly. Perhaps there was a simple typo during system installation. Many network features will work correctly even with this error, but services that rely on broadcasts certainly will not.

Activating NIS access

In the test above we only created a temporary connection to NIS. Access to the NIS server is not permanently setup yet, and Mac OS X still doesn't use NIS to get administrative information. To store the NIS configuration permanently, execute the following steps:

[[File:NISStep1.png]]

 

Note to Panther users: In Mac OS X 10.3 the NIS component is now part of the directory service plug-in "BSD Flat File and NIS". In step (3) of the following instructions, just select BSD Flat File and NIS instead of NIS.
  1. Launch the application Directory Access in the folder Utilities in Applications.
  2. If the key icon in the lower left corner is locked, click on the lock to authenticate with Directory Access in order to make changes.
  3. Make sure the checkmark at the item NIS is set and select the corresponding line. If the checkmark was not set, you must press the Apply button before you continue to the next step.
  4. Click the Configure... button.
  5. Enter the name of your NIS domain at Domain Name.
  6. If the NIS severs are located in a different subnet, or the NIS administrator has deactivated server recovery through broadcast messages, enter the IP address(es) of your server(s) into the NIS Servers table. It is recommended to use IP addresses instead of computer names because otherwise we would create dependencies between NIS and name resolution: NIS could only start if the name resolver is running yet what cannot be guaranteed under all circumstances.
  7. Press OK.
  8. In Directory Access go to the tab view item Authentication.
  9. In the Search menu, select the option Custom Path.
  10. Press the Add... button
  11. Select your NIS domain as valid source for the authentication of users. Among other directory services, the NIS domain should be displayed in the form /BSD/mydomain.nis in the overview. Add this entry. After that, it should appear at the end of the list Directory Node (also see the picture below).
  12. Now click on Apply at the lower right corner of the window. The configuration will be saved. It becomes active after a few seconds without restarting the computer.

 

 

NIS is now enabled: If you use NIS in connection with an NFS server, owner and group information for shared files should be displayed correctly when you access an NFS share.

If the users registered in the NIS database have a home directory on the Mac OS X machine, they also will be able to login. Note that if your network uses automounting to make home directories available to users, this will not work immediately, because the Mac OS X automounter is completely different from a usual NIS automounter. You should read the section about the automounter in this case.

 

Advanced configuration options

Which system components query which information sources?

Due to the historic roots of Mac OS X, the operating system uses two different strategies to access a directory service like NIS. The underlying Darwin system and all components of the operating system that have been adopted from NeXT access the lookupd system service, the central information broker in Mac OS X. So all functions of the standard Unix, or standard C libraries, respectively, that query system information, e.g. gethostname(), getgrent(), or getpwent() are internally redirected to the lookup service that is responsible for getting the requested data.

Applications that only access the upper layers of Mac OS X, for example Carbon programs that have been ported from the old Mac OS and don't know anything about the system's Unix core, have a second system component at their service: Those programs can explicitly call Apple Open Directory. In case of NIS, both Apple Open Directory and lookupd contact ypbind internally to finally get the NIS data. An overview on the architecture is given in the following picture:

 

As outlined in the picture, bidirectional communication between lookupd and Apple Open Directory is also possible.

Both components query the information categories listed in the following table. Note that for technical reasons, access to the various categories is distributed between lookupd and the Open Directory plug-in.

Category Internal Identifier processed by
E-mail alias names aliases lookupd
Entries for booting via network (BootP) bootp lookupd
Parameters for booting via network (BootP) bootparams lookupd
User groups groups plug-in
IP addresses of computers hosts lookupd
automatic NFS connections mounts plug-in
Network computer groups (netgroups) netgroups lookupd
IP addresses of subnets networks lookupd
Printers (Unix printcap entries) printers lookupd
TCP/IP protocols protocols lookupd
Remote procedure calls (SUN RPCs) rpcs lookupd
TCP/IP port numbers services lookupd
User accounts users plug-in

In recent releases of Mac OS X (Tiger and later), Apple is moving more and more functionality from lookupd to Directory Services (see below). The above table might no longer be up-to-date.

The categorires listed above correspond with the following NIS maps:

Category identifier NIS maps that are queried
aliases mail.aliases
bootp bootptab.byaddr
bootptab.byip
bootparams bootparams.byname
groups group.byname
hosts

hosts.byname
hosts.byaddr
ethers.byaddr

mounts mounts.byname
netgroups netgroup
networks networks.byname
networks.byaddr
printers printcap.byname
protocols

protocol.byname
protocol.bynumber

rpcs rpc.byname
rpc.bynumber
services services.byname
services.bynumber
users passwd.byname
passwd.byuid

Not all of these NIS maps are available by default on each and every NIS server. Some of them, e.g. mounts.byname, have been specifically defined by Apple and need to be created on the servers first if they should be used.

Defining the search order for information categories

The lookupd software uses loadable components called agents to request administrative data from the different information sources. The following agents are available in Mac OS X 10.2:

Search agent Function
CacheAgent

This agent queries internal cache memory used by lookupd. The lookup services uses a caching strategy for better performance. When it is asked for a database item, it first looks in the cache to see if the answer is known already. It then validates the cached entry to see if the information is still up-to-date (time stamps and database sequence numbers are used for validation). If the entry is invalid, a fresh copy is fetched and the stale one replaced.

DSAgent

The agent for communication with directory services (DS) of Apple Open Directory. This agent makes lookupd capable of requesting services from Open Directory.

NIAgent The agent for direct NetInfo queries.
NISAgent The agent for accessing NIS. It was used in Jaguar and Panther, but is no longer needed in Mac OS X 10.4 or later.
LDAPAgent An agent for accessing LDAP servers at the Darwin/BSD level. Note that Mac OS X under normal circumstances uses Apple Open Directory – independently of this agent – to communicate with LDAP servers. For this reason, this agent is needed for particular configurations only.
DNSAgent This agent accesses DNS (Domain Name Service). It is responsible for resolving computer names to IP addresses and vice versa.
FFAgent This agent can be activated to query classic Unix configuration files (FF = flat files). The system will read configuration files in the /etc directory, for example /etc/group, /etc/hosts, /etc/fstab and so forth.
NILAgent

The NILAgent always returns negative answers. On first look this doesn't seem to make sense, because when lookupd has queried all its agents for a particular information and no information was found, of course a "not found" message will be returned.

The additional effect of using the NILAgent however, is that it additionally places a "negative item" in the cache. The next time lookupd receives a request for that item, it will find the negative record quickly and avoids a long (useless) search by other agents.
The NILAgent can basically speed up the lookup process for particular search categories.

 

IMPORTANT: Apple is moving more and more functionality from lookupd agents to Directory Services plug-ins in the latest releases of Mac OS X (Tiger and later versions). This means some agents, like the NIAgent, the NISAgent, and the LDAPAgent have basically lost their meaning. Their tasks are now handled by Directory Services. Lookupd uses the DSAgent to access the required information, so the aforementioned agents are no longer needed.

You should disregard the following paragraphs when using 10.4.3 or a later version of Mac OS X.

In many networks it can be necessary to define a specific search order for the query of specific information categories. When using NIS it very often desired, for example, to let the NIS server resolve IP addresses instead of using a DNS server. Some other users may additionally want to enable manual definition of IP addresses in the /etc/hosts file, and so forth. In both cases, it is necessary to alter the search order for the information category "hosts".

NOTE TO EXPERIENCED UNIX ADMINISTRATORS: This step is equivalent to modifying /etc/nsswitch.conf on SUN-style Unix systems.

To define a search order for an information category in Mac OS X, you define a priority list of agents that should be queried when data for this category is requested. Those lists are stored as parameters of the lookupd program. Storage takes place in the NetInfo database.

To review or change lookupd's configuration, open the application NetInfo Manager in the folder Utilities in Applications. Select the NetInfo database path /locations/lookupd in the column view. The default configuration of a system on which NIS was activated consists of the following entries:

 

The value of the property LookupOrder defines two things:

  • the list shows the mandatory agents lookupd should load
  • the list defines the default search order in which agents for all search categories will be queried

In the example, the cache, NetInfo, directory service, and NIS agents are loaded:

  • CacheAgent
  • NIAgent
  • DSAgent
  • NISAgent

At the same time, this list defines the default search order: The agents are queried one by one in top-down order until the searched item is found. If no agent is able to answer the query, the result "not found" is returned.

The other value MaxThreads, shown in the window above, defines how many helper threads lookupd can create in parallel to distribute its search requests. The value of 64 suggested by Apple for a NIS configuration, is sufficient even in complex networks and doesn't need to be changed under normal circumstances.

The picture shows some NetInfo subdirectories as well, here with the names hosts, networks, protocols, rpcs und services. With these entries, the default search order for particular information categories can be overridden. For example, if you want to redefine the default search order for the search of user accounts, you should create a subdirectory at the NetInfo database path /locations/lookupd with the name users.

Inside such a subdirectory a property LookupOrder has to be setup that contains the desired priority list for this category. Apple's default configuration for the category hosts – the IP resolution of computer names – has the following value:

 

As you see, the system first queries the cache, then the /etc/hosts file, then DNS, NetInfo, Apple Directory Services, and finally NIS. To give NIS higher priority, you could place the NISAgent in front of the DNSAgent, for example.

NOTE: Be very careful when modifying the search order for the "hosts" category!

At boot time, there can be complex dependencies regarding search order: Your network setup may require that the system needs to resolve host names before or during startup of the NIS subsystem. This could result in a deadlock situation: The host name cannot be resolved because NIS has not been started yet, but NIS cannot be started because the system is waiting for a host name resolution. To solve this problem, you could for example add the necessary host entries to the NetInfo database or to the /etc/hosts file.

 

WARNING: A default configuration of Mac OS X is very dependent on NetInfo data. If you disable the NIAgent for a search category or place other agents in front of it, you should know exactly what you are doing! If the other agent provides unwanted information, the data in NetInfo won't be consulted any longer. In the worst case, your computer could freeze during startup, or you are locked out from your system because your user account is no longer found.

Apple adds the configuration entries depicted above to the NetInfo database as soon as you activate NIS with the Directory Access application. Because the NIS plug-in for Apple Open Directory cannot query all information categories at the moment, this makes sure that – no matter whether a program accesses lookupd or Apple Open Directory – matching results will be returned. By default, the DSAgent has higher priority than the NISAgent. At the same time those entries make a template that can be duplicated or modified easily if necessary.

After you have made changes in NetInfo Manager, you should restart the operating system to let the changes take effect. Alternatively, you could enter the command

sudo killall -HUP lookupd

to achieve the same. Note that under some particular circumstances this won't result in exactly the same effect because there could be complex dependencies between Apple Open Directory and lookupd.

 

Detailed diagnostics with lookupd

If NIS seems to work correctly but you experience problems with specific network lookups, you can run lookupd in debug mode to see what exactly happens on your system. Open a Terminal window and enter the command

lookupd -d

to start a second instance of lookupd running in debug mode.

At the lookupd prompt, issue the command

configuration

The first few lines of the ouput should look like this:

Array: "Configuration"
==> 8 objects
[
Dictionary: "Global Configuration"
ConfigSource: netinfo://127.0.0.1/local:/locations/lookupd
LookupOrder: CacheAgent NIAgent DSAgent NISAgent

The important thing is the line LookupOrder which shows which information sources are queried in which order. Here, at least the entries DSAgent and NISAgent must show up. If any of those entries is missing, NIS has not been setup correctly. In this case, repeat the setup as shown in the previous sections.

Let's assume you have a problem with a particular lookup item, for example, an NIS entry for the user "john" that doesn't work. To see which agent is providing which information about "john", enter

userWithName: john

NOTE: lookupd uses a command-completion feature that is activated by pressing the space-bar. You have to use it, otherwise you'll have problems entering the colon (:). It is sufficient to type userWithNa, then presing the space-bar to complete the command, and then entering john. Typical output looks liks this:

Dictionary: "DS: user john"
_lookup_agent: DSAgent
_lookup_validation: 1048305592
gid: 100
home: /home/john
name: john
passwd: uPXu65uc.akEh
realname: John Doe
shell: /bin/bash
uid: 521
+ Category: user
+ Time to live: 43200
+ Age: 0 (expires in 43200 seconds)
+ Negative: No
+ Cache hits: 0
+ Retain count: 4

You see that the DSAgent (the agent for Apple directory services) has responded and under which circumstances the data were received.(entries prefixed with "_"), the user record that was returned (lines without any markings), and the current cache status for this entry (lines prefixed with "+").

To see a list of all debug commands of lookupd, enter "help" and press the question mark "?". You leave help mode and debug mode with the command "quit".

 

Using automounters

What are automounters?

Networks which are running NIS often use a component that is called NFS automounter, a feature that automatically connects the computer to shared folders on NFS servers. The NIS administrator can prepare a specific map which lists all shared folders that can be mounted from NFS file servers on the network. This map does not only contain a list of the exported directories, it also contains path names (mount points), to which these folders should be mounted if a user tries to access such paths.

An example: Let's assume your network has an NFS file server with the name "marvin" that exports the directory "/disk5". The NIS administrator can create a special NIS map which lists "marvin:/disk5" as NFS export, and also provide a mount point, e.g. "/import/public".

Whenever a computer on the NIS network accesses the directory "/import/public", it will automatically mount "marvin:/disk5" to the mount point "/import/public". If this computer doesn't use files in /import/public for a specified time, e.g. 10 minutes, the directory will automatically be unmounted.

This is a very elegant solution: all computers on the local network can access the files on disk5 via the same path name. They all mount it automatically, and only if needed. Automounting reduces the number of actual mounts each computer has to handle. Because the shares are automatically unmounted, too, the computers will not freeze if any of the file servers is shut down.

 

Special features of Mac OS X

There are two different automounter standards that are used on Unix systems: amd and autofs. As Unix system of the BSD family, Mac OS X 10.2 and 10.3 supports the amd automounter. However, amd is not configured by default on Mac OS X. Instead, another automounter called automount which is propietary to Mac OS X is used. This automounter is not compliant with amd or autofs standards. For this reason, additional configuration entries for your NIS server are necessary if you want to use NFS automounts in connection with Mac OS X.

The use of amd has never been officially supported by Apple. As of Mac OS X release 10.4, it is no longer part of the operating system distribution.

If you don't want to create proprietary NIS maps on your server, you have the following options besides amd:

  • In a small network with only a few NIS automount entries, you could create the necessary setup manually in the NetInfo database. The application NFS Manager (http://www.bresink.com/osx/NFSManager.html) is a user friendly tool for doing this.
  • If you have some experience in writing Unix scripts, you could write a cron-job that downloads the NIS automounter maps in certain time intervals, converts the entries into Mac OS X format, and uploads them as mount entries into your NetInfo database. Anthony Lissot was so kind to supply detailed information about setting up a NetInfo domain and distributing NFS automount maps on his web site. Stefanus Du Toit has kindly donated an example script for the integration of autofs tables which are shared via LDAP.
    If you have more than approximately 3,000 mount points in your network, this technique might drastically degrade NetInfo performance. In this case, don't upload the tables to NetInfo, but push the mount lists into flat files. You then can use the "file maps" option of the Mac OS X automounter to directly read those files.

 

Setting up the Mac OS X automounter

To fit the automounter to specific needs, you can modify its parameters in the startup script. With root permission, edit the script

/System/Library/StartupItems/NFS/NFS

and change the options of the automount call. You'll find the automount call as last command of the function StartService(). If you follow the instructions given in the next paragraph, there is no general need to change anything. To learn more about the automounter, enter automount -help at the command line. You should not consult the man page of automount because it contains erroneous information.

Creating a compatible mount map on the NIS server

If you want to use NIS to distribute mount entries for Mac OS X, a special NIS map with the name

mounts.byname

has to be created on the NIS master server. The map must have the format of a BSD-Unix fstab file (file-system table). The table must have six columns separated by white-space, as in the following example which specifies four mount entries:

##
#
# Network Information System Source File: BSD-fstab
#
# export             mount_point vfs_type options         dumpFreq passno
##
marvin:/home         /home       nfs      rw,resvport     0        0
marvin:/export/disk0 /import/d0  nfs      net,rw          0        0
marvin:/export/disk1 /import/d1  nfs      net,rw          0        0
marvin:/export/disk2 /import/d2  nfs      net,ro          0        0

This table shows the options respected by the automounter. Put them in column four of the NIS map:

Option

Explanation

net

Providing or omitting this option has several consequences for the interpreation of mount points and how the Mac OS X Finder will present the mount to the user. This option is discussed in detail in the next section "Meaning of the 'net' option".

rw users have read / write access
ro users have read-only access, this includes the super-user
rdonly a synonym for "ro"
suid set-user-identifier and set-group-identifier bits will be respected
nosuid set-user-identifier and set-group-identifier bits will be ignored
exec binaries from the mounted file-system can be executed
noexec binaries from the mounted file-system cannot be executed. Useful when mounting from a file server with a different CPU architecture.
dev allows interpretation of character or block special devices
nodev forbids interpretation of character or block special devices
union causes the namespace at the mount point to appear as the union of the mounted filesystem root and the existing directory. Lookups will be done in the mounted file-system first. If those operations fail due to a non-existent file the underlying directory is then accessed. All creates are done in the mounted file-system.
sync all input / output to the mounted file-system will be done synchronously
soft does a "soft" mount which means that a file operation fails if it is not successful for a specific number of retry round trip time intervals
intr make the mount interruptible. This means a file operation that was delayed due to an unresponsive server will fail if the process is sent a termination signal
conn opposite of "noconn". See next line.
noconn do not use a connect call to mount from the server. This is necessary for NFS servers with multiple IP addresses or servers not listening to the standard NFS port 2049
nqnfs use protocol version 2 revision of "Not Quite NFS". This enables leasing extensions to maintain cache consistency.

 

IMPORTANT: All NQNFS features have been removed in Mac OS X 10.4. and later versions.

Kerberos support for NFS is available in the Darwin source code, but the official releases of Mac OS X have all Kerberos support features for NFS disabled.

In all newer releases of Mac OS X you also can use the following options:

Option Explanation
hard the opposite of soft. See "soft" in the preceding table.
nfsv2 mount using NFS version 2 protocol
nfsv3 mount using NFS version 3 protocol
kerb pass Kerberos authenticators to the server for client-to-server user-credential mapping
dumbtimer turn off the dynamic retransmit timeout estimator. This is useful for UDP mounts that show high retry rates
resvport always use reserved port numbers when talking to the NFS server. Many NFS servers require that this option is enabled.
rdirplus optimizes performance by using the ReaddirPlus function call for some operations, e.g. "ls-l". ReaddirPlus uses prefetch operations for the attribute and name caches and tries to reduce RPC traffic. This makes sense if the product of bandwidth times delay is large. In other cases, performance might even degrade.The parameter should only be used together with nqnfs and nfsv3.
udp force the mount protocol to use UDP transport. This might be necessary for old NFS servers.
tcp force the mount protocol to use TCP transport. This is recommended for servers that are not on the same LAN cable as the client. If the NFS server is not running BSD-Unix, this might not work.
-I=xxxx set the readdir read size to the value xxxx
-a=n set the read-ahead count to the value n which must be in the range 0 - 4.
-g=xxxx set the maximum size of the group list for the credentials to xxxx. This should be used for mounts on old servers that cannot handle a group list size of 16.
wsize=xxxx set the write data size to the value xxxx. If you mount a NEXTSTEP file server, it is recommended to use wsize=1024 here.
rsize=xxxx set the read data size to the value xxxx. If you mount a NEXTSTEP file server, it is recommended to use rsize=1024 here.
timeo=xxxx set the initial retransmit timeout to the value xxxx
retrans=xxxx set the retransmit timeout count for soft mounts to xxxx
mnttimeo=xxxx set the global mount timeout to xxxx
ttl=xxxx set the global time-to-live value to xxxx

 

NOTE: Some old versions of Mac OS X have a manual page stating that the "resvport" (aka -P) parameter is always ignored. This is an error in the man page which has been corrected in Mac OS X 10.1.

If you want to access an NFS file server from Mac OS X but get "permission denied" errors when reading a directory, it is most likely that a security feature is enabled on the NFS server that prevents the use of insecure ports. Some versions of Solaris and nearly all modern Linux distributions use this feature by default. To mount shares from these servers, you have to use the resvport parameter.

The fstab file must be placed somewhere on the NIS server, and the server's yp-Makefile has to be modified to create the new NIS map. Note that each database table must have an additional key column, so the final database table will in fact have seven columns. Mac OS X doesn't care about the values of the keys, they only should be unique. A simple solution is to duplicate the first column of the fstab file and use it as database key.

The following code fragment written for SuSE-Linux shows an example what has to be added to the NIS Makefile to create the new NIS map. It is shown for illustrative purposes only! Because NIS implementations on different Unix systems can differ greatly, the NIS administrator always should develop a script that is specifically tailored to your environment. See the documentation of your NIS server for more information.

WARNING: Don't just copy this code into your Makefile unless you know exactly what it's doing!
---------------------------------------------------------------------

mounts.byname: $(AUTO_FSTAB) $(YPDIR)/Makefile
   @echo "Updating $@..."
   @$(AWK) '{ if($$1 !~ "#" && $$1 != "") { print $$1"\t"$$0    }}' \
   $(AUTO_FSTAB) | $(DBLOAD) -i $(AUTO_FSTAB) \
   -o $(YPMAPDIR)/$@ - $@
   @$(NOPUSH) || $(YPPUSH) -d $(DOMAIN) $@

---------------------------------------------------------------------

Thanks to Michael Thompson (Industrial Light & Magic) for providing the following script fragment written for SUN Solaris 8:

---------------------------------------------------------------------
mounts.time: $(DIR)/mounts
   @(awk 'BEGIN { FS=" "; OFS="\t"; } /^[a-zA-Z0-9_]/ { print $$1, $$0 }'\
   $(DIR)/mounts $(CHKPIPE))| $(MAKEDBM) - $(YPDBDIR)/$(DOM)/mounts.byname;
   @touch mounts.time;
   @echo "updated mounts";
   @if [ ! $(NOPUSH) ]; then $(YPPUSH) -d $(DOM) mounts.byname; fi
   @if [ ! $(NOPUSH) ]; then echo "pushed mounts"; fi
---------------------------------------------------------------------

Thanks to Patrick M. Hausen (punkt.de GmbH) for providing the following script fragment written for FreeBSD:

---------------------------------------------------------------------
MOUNTS    = $(YPSRCDIR)/mounts

mounts.byname: $(MOUNTS)
@echo "Updating $@..."
$(CAT) $(MOUNTS) | \
$(AWK) '{ if($$1 !~ "#" && $$1 != "") { print $$1"\t"$$0 }}' | \
$(DBLOAD) ${B} -i $(MOUNTS) -o $(YPMAPDIR)/$@ - $(TMP); \
$(RMV) $(TMP) $@
@$(DBLOAD) -c
@if [ ! $(NOPUSH) ]; then $(YPPUSH) -d $(DOMAIN) $@; fi
@if [ ! $(NOPUSH) ]; then echo "Pushed $@ map." ; fi ---------------------------------------------------------------------
WARNING: If you copy / paste this code as a template for your Makefile, make sure that the line endings are correct (line feed characters), and the white space in front of the "@" in each line is replaced by a single tab character, not spaces!

Meaning of the "net" option

One of the special features of Mac OS X is the system's strategy to determine all information about disk devices on a completely dynamic basis, without the user having to do additional configuration steps. At boot time, all readable partitions on all disk devices are recognized automatically. They are automounted and don't need any /etc/fstab entries as classic Unix operating systems usually do. Apple follows the "volume" philosophy of the old Mac OS in which those steps weren't necessary either.

When processing NFS automounts, a similar strategy is adopted. A default configuration of Mac OS X does not use statics NFS mounts. Although the entries of the mounts.byname map mentioned before look like a static fstab file, all entries will be handled as automounts. The mount points defined in the table are not taken directly but are interpreted by the automounter first. The way of interpretation is defined by the "net" option.

a) the net option has not been specified:

If the "net" option has not been provided, for each mount entry a dynamic mount point will be created in the folder /private/automount. In a second step, the automounter creates a symbolic link that connects the static mount point specified by the user to the dynamic mount point.

Example: In the table above marvin:/home should be mounted to /home. The automounter does not execute this directly. Actually, marvin:/home is mounted to /private/automount/home and a symbolic link from /home to /private/automount/home is created.

This course of action can have serious disadvantages in some cases: There are restrictions to define mount points that share common parent paths. If you define a mount point /Some/Folder/A for example, the folder A won't be capable of holding another mount point, because A is actually a symbolic link which does not allow the creation of subdirectories. This restricts the use of union NFS mounts and can cause problems with techniques known as "loopback mounts".

b) the net option has been specified:

If an automount entry has been flagged with the net option, Mac OS X will visualize this mount in the user interface as explicit connection to a file server. The Finder will display all NFS connections flagged this way in the folder /Network/Servers ordered by the servers' names. The name of the actual mount point is computed dynamically using the name of the NFS share.

Example: In the table above the NFS share marvin:/export/disk0 has been specified with the mount point /import/d0. This will create an automount in the folder /private/Network/Servers/marvin/export/disk0. To visualize marvin in the Finder, an additional symbolic link from /Network/Servers/marvin/export/disk0 to /private/Network/Servers/marvin/export/disk0 is created.

Note that a syntactically correct mount point has to be specified in the mounts.byname table although it isn't used at all if the net option is specified!

/private is the default base directory used by the automounter. It can be changed using the "-a" option. The path /Network/Servers comes from the automounter's "-m" option specified for the "-fstab" map. In the same way, the path /automount is based on the parameter for the "static" map. All defaults can be modified in the startup script.

NOTE: The automounter mounts all exports from one server simultaneously. If you want the shares mounted "one at a time", use the "-1" option.

You should never try to specify "/" as the automounter base directory. In this case, your root file-system will disappear (!) until you reboot the machine. If you want to have the best of both worlds, i.e. labeling the mount as network mount to make the user see what is happening, and simulate classic mount points at the same time, you should use symbolic links. In our example, we would flag the home entry with "net", and create a symbolic link that points from /home to /Network/Servers/Marvin/home:

ln -s /Network/Servers/Marvin/home /home

This is the best solution in most cases. You create the symbolic links manually at places where needed, preventing a mutual blocking of path names.

 

Frequently Asked Questions

The NIS server is running an up-to-date Unix version. Mac OS X has no problems accessing the database but logging in with a NIS user account does not work

Most older versions of Mac OS X assume that passwords are encrypted using the classic DES scheme. Many up-to-date Unix releases use other encryption methods however, which might not be compatible with Mac OS X:

  • DES: compatible with all versions of Mac OS X
  • MD5: compatible with version 10.4.3 or later
  • Blowfish or other encryption schemes: not compatible with Mac OS X

To verify if the encryption method used by the NIS server is causing compatibility problems with Mac OS X, enter the command

ypcat passwd | tail

on any NIS client to display the last few lines of the user database. The lines are structured like in the following example:

guest:Cl/pdFPSstxJ2:596:100:Guest User:/home/guest:/bin/tcsh

The part between the first and second colons (:) is the encrypted user password. If it has no "$" marker and is not longer than 13 characters, it will indicate the classic "DES crypt" encoding method which is fully compatible with Mac OS X. If it begins with an "$1" marker, it will be MD5-encrypted and therefore only usable with 10.4.3 or a later version. Here is a typical example:

guest:$1$tJ2gSlhl$awGvwSsuXUP0jmkJmgDgK.:596:100:Guest User:/home/guest:/bin/tcsh

It it begins with "$2" or some other "$" marker, the user table cannot be used with Mac OS X. In this case you must switch your NIS server to DES or (using Tiger) to MD5 encryption which means you have to rebuild the whole user database with all passwords).

 

Does Mac OS X support shadow passwords with NIS?

No, this feature is currently not supported by Mac OS X. The system doesn't process user account passwords if the NIS server shares them in protected maps for security reasons (usually passwd.adjunct.byname or shadow.passwd.byname).

Daniel Browne, an independent software developer, is working on an alternative NIS plug-in for Mac OS X Jaguar that will support shadow passwords. Up-to-date information is available at the project's web site.

 

Are there known problems with NIS support in Mac OS X Jaguar?

Yes, the NIS plug-in for Open Directory is just a temporary workaround to make NIS usable in the "Jaguar" release of Mac OS X. Apple did not really fix the bugs that prevented NIS from working in the 10.2 versions (see the previous version of this document for more information.).

Note that those problems have been solved in Mac OS X Panther. If you are using Mac OS X 10.3 or later, it is not necessary to read this section.

There are essentially two problems with the implementation in Mac OS X 10.2.5:

  • Under some circumstances, Apple Open Directory is known not to work correctly after "wake from sleep". This means parts of the directory services will fail when the system is returning from an energy-saving standby state. The NIS plug-in can be affected by this problem. You may see the message ypbind[PID]: Can't find host: in the console log, and messages like lookupd[PID]: DirectoryService Framework::CMessaging::Mach msg send interrupt error = -14006 in the system logs during wakeup. After that, expired NFS automounts might no longer remount correctly until you reboot the machine. If you are experiencing this problem, you should consider deactivating the energy saving settings on all machines that use directory services.
  • The graphical user interface of the Directory Access application has some issues when activating or deactivating plug-ins: You have to use the controls in a particular order when you change the settings. Otherwise the application will stop responding (freeze), or the settings will not work as expected.

To solve the latter problem, the controls of Directory Access should be used in the following order. When activating the NIS plug-in

  1. set the checkmark,
  2. press the Apply button immediately after that,
  3. then press the Configure button,
  4. enter the configuration values in the sheet,
  5. then press the OK (or Cancel) button.

When deactivating the NIS plug-in

  1. press the Configure button first,
  2. then remove the entries in the Domain Name and NIS Servers fields and press OK,
  3. then remove the checkmark for the NIS plug-in and press Apply.

If you don't follow this exact sequence, the application will freeze, or the configuration will not be updated correctly which can serious network problems.

 

Are there known problems with NIS support in Mac OS X Panther?

NIS itself works fine in Mac OS X 10.3. There were a lot of networking problems - especially with NFS - in versions 10.3 to 10.3.2 but most of the issues have been resolved in 10.3.3 and higher. The following problems remain:

  • Fast user switching may not work correctly for NIS accounts: NIS users are not displayed in the user switch list but manually entering the name of an already logged in NIS user does work in some cases. The latter fails if the computer goes to sleep. (Thanks to Walker White for the details.)
  • NFS file locking is incompatible with non-BSD NFS servers. If the user has an automounted NFS home directory this will cause the applications Address Book, Mail and iChat to silently fail without any error messages. The applications do not work because Mac OS X cannot set a lock on the user's address book files. We have posted a workaround for our NFS Manager software.
  • Due to network problems of a more general nature, Panther may activate the network port of your computer with considerable delay. The network port may be inactive at the time Directory Services try to connect to the NIS server. As a consequence, Directory Services assume the network is down and NIS support is automatically switched off. If this happens try to check the following items:
    • If you are using DHCP, is the DHCP server providing the IP address fast enough?
    • Are multiple Network Locations configured on the machine that may cause Panther not to detect the correct network environment at first?
    • Does auto-negotiation work correctly for the Ethernet port the affected computer is connected to? Did you try to use an alternative Ethernet switch? Can you verify if the Ethernet hardware configuration settings in System Preferences have an effect on the network connections at boot time?

Are there known problems with NIS support in Mac OS X Tiger?

Mac OS X Tiger is affected by a variety of design flaws. One of them is the asynchronous initialization of network client services during the startup phase. Most services are started via the new "launchd" daemon in unpredictable, almost random order. This can for example cause directory services to be launched before the network interfaces are up, or the login window to appear before directory services are ready. Although all services should be prepared for this situation because they have to support dynamic network reconfiguration at any time, this does not really work in practice. Note that not only NIS, but all directory services supported by Mac OS X are affected, so similar problems even occur if you are running Apple Open Directory in a pure Mac OS X network. Among other problems, the following effects can be seen:

  • Login at the GUI may fail for network users while it is working for non-graphical logins, e.g. a remote SSH connection.
  • Login at the GUI may fail for all users and the system has to be restarted.
  • The system appears to freeze during startup but automatically recovers after waiting 2 or 4 minutes.
  • The system freezes when waking up from sleep mode, hanging in a deadlock which cannot be resolved. The computer must be powered down.
  • Login works fine, but other components dependent on a directory services connection may temporarily fail. For example, when hosting network fonts on a central AFP file server via an automount entry defined in directory services, the mount operation may be executed too late, creating other cascading failure effects, like font cache corruption, the loss of all font deactivation preferences, etc.

The internal trigger of these problems seem to be wait situations where network daemons are reconfigured dynamically via the "launch on demand" architecture of launchd, resulting in a cascading reconfiguration of other services, which can easily lead to race conditions and circular waits with deadlock-like effects. For this reason, the likelihood of such problems increases when you are using fast systems on fast networks. This can also lead to the false impression these were bugs in the x86 version of Mac OS X, although in fact only the higher speeds and the multi-processor equipment of Intel-based Macs are responsible.

To display the current status of the directory services client directly at the login window, you can enter the command

sudo defaults write /Library/Preferences/com.apple.loginwindow AdminHostInfo DSStatus

and restart the system. Below the "Mac OS X" header line, the login window will now display a status info with a "traffic light" dot, visualizing if no (red), some (yellow) or all (green) network users can login yet.

To make sure the login window won't be displayed before all network client services are running, you can introduce an artificial delay. Enter the command

sudo defaults write /Library/Preferences/com.apple.loginwindow StartupDelay -int n

replacing n by the number of seconds for the delay. Note that Mac OS X will cancel the wait when it detects that directory services have become ready before the wait period is over.

To increase the likelihood that the dependencies between the network interfaces, the DHCP client, the lookup service (lookupd), the directory services client, and its NIS plug-in are resolved in correct order, some users had success by sending lookupd a reconfiguration signal very late in the startup process. You can do this for example by adding the command

/bin/kill -HUP `cat /var/run/lookupd.pid`

at the end of the StartService() function in the NIS startup item /System/Library/StartupItems/NIS/NIS (A lot of thanks to Susanne Ost, Bauhaus University of Weimar, for this idea).

 

Does Panther need the NISDOMAIN setting in /etc/hostconfig?

You may know the NISDOMAIN setting in /etc/hostconfig from previous versions of this document. This setting configures NIS support at early boot time directly at the Darwin level. However, this setting is no longer needed in Mac OS X 10.3 or higher. Directory Services now start ypbind under their own control, and the NIS domain name is stored in the file /Library/Preferences/DirectoryService/nisdomain. If this doesn't work for you, your computer might be affected by the "inactive network port" problem mentioned in the previous paragraph. In this case adding the NISDOMAIN setting can have a positive effect because it forces Darwin to start ypbind and wait for an NIS server connection. Note that the system might freeze if there is really no NIS server available. (See next question.)

 

I disconnected a pre-Panther computer from the network. Now Mac OS X freezes during startup waiting for the NIS server. How can I deactivate the binding?

Execute the following steps:

  1. Switch the computer on. When hearing the startup sound, press and hold Apple-s to start in single-user mode.
  2. When the first console messages appear, release the keys. Wait for the single-user prompt.
  3. Enter

    /sbin/fsck -y

    to do a file system check. Then

    /sbin/mount -uw /

    to make the system disk writable.
  4. Enter the command

    pico /etc/hostconfig
  5. This will start a text editor to modify the startup configuration of Mac OS X. Search for the line that begins with NISDOMAIN.
  6. Modify the line that it reads

    NISDOMAIN=-NO-
  7. Press ctrl-x to save the changes and leave the editor.
  8. Reboot the machine with

    reboot

I want to become member of the administrative "wheel" group but I have an NIS user account only. Should the NIS administrator add me to the wheel group?

No, in most NIS implementations the NIS administrator can't even do that, because all system group IDs (with values less than 100) aren't distributed via NIS. However, Mac OS X has no problems supporting "mixed" user groups containing both NetInfo and NIS user accounts. So just add your NIS user account to the wheel group, no matter if the group itself is only known in NetInfo.

 

NIS works fine but some users with NIS accounts still can't login

Please check the following items:

  • Does NIS lookup work for this user?
    Use the diagnostic mode of lookupd to see if correct information is provided for the user. Perhaps the system is receiving inconsistent user IDs, the NISAgent isn't running or another agent is answering before the NISAgent is queried.
  • Is the user's home directory mounted or automounted?
    The login is useless if the user sees no home directory on the Mac OS X machine. You have to make sure that the user's home directory is already mounted or gets automounted when the user logs in.
  • Is the user's shell available on the Mac OS X machine?
    Check the shell entry in the user record. (use lookupd diagnostics or ypmatch -k username passwd to display it). The specified shell has to be available on the Mac OS X system for the user to successfully log in. For example, Mac OS X does not come with the ksh shell by default. If "/bin/ksh" is specified as the user's login shell, he or she can't log in on a system missing the ksh program.
  • Is the user's shell acceptable on the Mac OS X machine?
    If the shell program is really available and executable by the user, make sure it is also marked as acceptable: Look if the program is registered in the local file /etc/shells.
  • Is the user record complete?
    Mac OS X does not allow that the "full name" field in the user table can be empty. It needs both the Unix user name (called "short name" in Mac OS X) and the complete user name, called "GECOS field" in classic Unix. Use ypcat passwd to find out if they records are complete.

Can I use NIS-based automount tables to define static NFS mounts?

Yes, this is possible by changing the automounter's parameters. In this case, all mount entries that have not been flagged with the "net" option will be interpreted as static NFS mounts. Those mounts will be activated directly without the use of symbolic links. Change the startup call of the automounter in the file /System/Library/StartupItems/NFS/NFS by removing the "static map" option. So the line

automount -m /Network/Servers -fstab -m /automount -static

needs to be changed to

automount -m /Network/Servers -fstab

Note that this is not enough. You will also have to integrate a static mount command later in the startup sequence to let Mac OS X reread the mount table after the network and NFS are up and running, e.g.

/sbin/mount -a -t nfs