Linux Commands

Overview of Nsswitch.Conf

The introduction of Network Information Services (NIS) and Domain Name System (DNS) has made it more obscure to look for the details of the user and system information. Now, it is not that simple to just look inside the local file.

Before, to check the user information, we need to refer to /etc/passwd and we need to look in the /etc/hosts for system address information. Now, there are various ways to find this type of information. You may set up which services are to be utilized to lookup the things like hostnames, password files, and group files using the /etc/nsswitch.conf file.

With the /etc/nsswitch.conf (name service switch configuration) file, we can specify the ways and their order to use them when finding a specific type of information. We can indicate the action on which the system takes on the basis of whether a method is successful or unsuccessful.

What Will We Talk About?

In this write-up, we will cover an overview of the nsswitch.conf file on the Linux operating system. Let’s get started now.

Nsswitch.Conf File Format

In the nsswitch.conf file, each line defines how to look for a piece of information. The format of a line in nsswitch.conf looks like this:

info: method [[action]] [method [[action]]...]

Where “info” refers to the information that is described by the line, “method” refers to the technique that is used to get that information, and “action” refers to the response to the return status of the previous method. The action is surrounded by square brackets.

Inside the Nsswitch.Conf File

Let’s now look into this file. The file looks like this:

# /etc/nsswitch.conf
# Name Service Switch configuration file.

passwd:     db files
shadow:     files
group:      db files

hosts:      files dns
networks:   files

ethers:     db files
protocols:  db files
rpc:        db files
services:   db files

As you would probably guess from looking at the provided table, the database is listed in the first column. The rest of this line indicates how the lookup is performed. Also, note that you have to show the manner of how it functions for each database individually. This cannot be accomplished using the conventional method of a monolithic implementation. Each database’s configuration definition may have two distinct fields: the service specification such as files, db, or nis and the response to lookup the results such as [NOTFOUND=return].

Available Options with the Nsswitch.Conf File

The options in this file must reside on different lines. The following options are available:

  1. dns: In this case, the DNS service is used to resolve the address. This is good for resolving the host addresses but not for the resolution of network addresses.
  2. files: It uses the classic /etc/hosts and /etc/network files. It looks for a local file for host or network name and its respective address.
  3. nis or nis+: To resolve the host or network address, it utilizes the Network Information System (NIS).

The ordering of the source databases controls the order in which the NSS tries to look up those sources to resolve the queries for the target service.

Actions in the NSS Configuration

The next specification item allows the user with far greater control over the lookup behavior. Action items are put in between the service specifications and are surrounded by square brackets. Generally, the action statement has the following syntax:

[ [!] status = action ... ]

Let’s break down this syntax:

  1. The action parameter has two possible actions:
    1. return: The program that tries for name resolution gets back the control. In case a lookup attempt is failed, the resolver returns zero; otherwise, it returns with the details.
    2. continue: The resolver goes to the subsequent service on the list in order to try for resolution using this service.
    3. merge: It means continuing with the lookup process while keeping the recent results. This action is usable only when the status is “success”.
  2. The (!) character is optional and basically means not. The (!) character is an inversion operation that is used in many programming languages.
  3. The status parameter: The STATUS value is compared to the output of the lookup function that the preceding service specification calls. The status value can be:
    1. success: The requested entry is obtained without difficulty. The default action is “return”.
    2. notfound: The lookup is successful. However, the target host or network is not found. The default action is “continue”.
    3. unavail: The service that is requested could not be found. It might imply that the hosts or networks file is not readable for the files service. It can also mean that a name server or NIS server did not answer for the dns or nis services. The default action here is “continue”.
    4. tryagain: This status indicates that the service is currently not available. This may imply that a file is locked or that a server is unable to accept any more connections at this time. The default action here is also “continue”.

A basic example of this mechanism can be as shown in the following illustration. It uses the “Action” statement:

hosts:  dns [!UNAVAIL=return] files
networks:   files

This example uses a DNS service for host resolution. The resolver returns the queried data if the return status is not “unavailable”. If the return status is unavailable, the local /etc/hosts file is used by the resolver.

Important Note: The user should strive to improve the lookup process. Response times vary depending on the service. A basic file lookup on a local file may be quick. However, if the file is long and the requested entry is toward the end, it may take a long time. In this scenario, the database service, which offers quick local access to big data sets, may be preferable.


In this article, we learned about an overview of the nsswitch.conf file on Linux. Even if /etc/nsswitch.conf does not exist, the NSS implementation is not absolutely helpless. There is a default value for every supported database. So, even if a file is damaged or absent, the system should typically be able to function.

About the author

Ali Imran Nagori

Ali imran is a technical writer and Linux enthusiast who loves to write about Linux system administration and related technologies. You can connect with him on LinkedIn