Chapter 29. Network services

Table of Contents

29.1. The Network File System (NFS)
29.1.1. NFS setup example
29.1.2. Setting up NFS automounting for /net with amd(8)
29.2. The Network Time Protocol (NTP)

29.1. The Network File System (NFS)

Now that the network is working it is possible to share files and directories over the network using the Network File System (NFS). From the point of view of file sharing, the computer which gives access to its files and directories is called the server, and the computer using these files and directories is the client. A computer can be client and server at the same time.

Warning: NFS has no authentication, and access control is only by network address. NFS should be deployed only on restricted or firewalled networks (e.g., with npf(7); see Section 24.5, “Setting up an Internet gateway with NPF”). It is not safe to deploy on the open internet.

  • The server must enable the rpcbind(8), mountd(8), lockd(8), and statd(8) daemons, and enable the nfs_server option (which enables nfsd(8)), in /etc/rc.conf:

  • The client must enable the rpcbind(8), lockd(8), and statd(8) daemons, and enable the nfs_client option, /etc/rc.conf:

  • The server must list the exported file systems in /etc/exports (see exports(5)) and then run the command service mountd reload.

    Warning: Only entire file systems can be exported, not subtrees of file systems. You can export subdirectories of a file system as possible mount points for clients, but that exposes the entire content of the file system they live on to clients. If you want to export one subtree and prevent access to other subtrees, the exported subtree must be on its own file system.

A client host can access a remote file system through NFS if:

  • The server host exports a mount point in the file system to the client. The list of mount points a NFS server exports can be checked with the showmount -e command (see showmount(8)). For example:

    # showmount -e
    Exports list on
    /home                              host1 host2 host3
  • The client host mounts the remote directory in fstab(5) or with the command mount /home (see mount_nfs(8)).

29.1.1. NFS setup example

The scenario described here is the following: five client machines (cli1, ..., cli5) share some directories on a server ( Some of the directories exported by the server are reserved for a specific client, the other directories are common for all client machines. All the clients boot from the server and must mount the directories.

The directories exported from the server are:


the five root directories for the five client machines. Each client has its own root directory, with X = 1, 2, 3, 4, or 5.


Five swap directories for the five swap machines.


/usr directory; common for all client hosts.


Common /usr/src directory for all client machines.

The following file systems exist on the server:

/dev/ra0a on /
/dev/ra0f on /usr
/dev/ra1a on /usr/src
/dev/ra2a on /export

Each client needs the following file systems:

buzz:/export/cliX/root   on /
buzz:/export/common/usr  on /usr
buzz:/usr/src            on /usr/src

The server configuration is the following:

# /etc/exports
/usr/src  -network -mask
/export   -alldirs -maproot=root -network -mask

Note that all exported directories are on file systems other than / and /usr, so that clients can't overwrite important files like /bin/sh and /usr/bin/less or read from secret files like /root/.ssh/id_ed25519 or /etc/krb5.keytab on the server.

On the client machines /etc/fstab contains:

buzz:/export/cliX/root  /        nfs rw
buzz:/export/common/usr /usr     nfs ro,nodev,nosuid
buzz:/usr/src           /usr/src nfs rw,nodev,nosuid

Each client machine has its number substituted to the X character in the first line of the previous example.

29.1.2. Setting up NFS automounting for /net with amd(8) Introduction

The problem with NFS (and other) mounts is, that you usually have to be root to make them, which can be rather inconvenient for users. Using amd(8) you can set up a certain directory (Commonly /net), under which one can make any NFS-mount as a normal user, as long as the file system about to be accessed is actually exported by the NFS server.

To check if a certain server exports a file system, and which ones, use the showmount-command with the -e (export) switch:

$ showmount -e
Exports list on
/archive                           Everyone

If you then want to mount a directory to access anything below it (for example /archive/systems/unix/NetBSD), just change into that directory:

$ cd /net/

The file system will be mounted (by amd), and you can a access any files just as if the directory was mounted by the superuser of your system. Actual setup

You can set up such a /net directory with the following steps (including basic amd configuration):

  1. in /etc/rc.conf, set the following variable:

  2. mkdir /amd

  3. mkdir /net

  4. Taking /usr/share/examples/amd/amd.conf, put the following into /etc/amd.conf:

    [ /net ]
    map_name =              /etc/amd/net
    map_type =              file
  5. Taking /usr/share/examples/amd/net as example, put the following into /etc/amd/net:

    /defaults       type:=host;rhost:=${key};fs:=${autodir}/${rhost}/root
    *             host==${key};type:=link;fs:=/                           \
  6. Reboot, or (re)start amd by hand:

    # service amd restart

29.2. The Network Time Protocol (NTP)

It is not unusual to find that the system clock is wrong, often by several minutes: for some strange reason it seems that computer clocks are not very accurate. The problem gets worse if you administer many networked hosts: keeping the clocks in sync can easily become a nightmare. To solve this problem, the NTP protocol (version 3) comes to our aid: this protocol can be used to synchronize the clocks of a network of workstations using one or more NTP servers.

Thanks to the NTP protocol it is possible to adjust the clock of a single workstation but also to synchronize an entire network. The NTP protocol is quite complex, defining a hierarchical master-slave structure of servers divided in strata: the top of the hierarchy is occupied by stratum 1 servers, connected to an external clock (ex. a radio clock) to guarantee a high level of accuracy. Underneath, stratum 2 servers synchronize their clocks with stratum 1, and so on. The accuracy decreases as we proceed towards lower levels. This hierarchical structure avoids the congestion which could be caused by having all hosts refer to the same (few) stratum 1 servers. If, for example, you want to synchronize a network, you don't connect all the hosts to the same public stratum 1 server. Instead, you create a local server which connects to the main server and the remaining hosts synchronize their clocks with the local server.

Fortunately, to use the NTP tools you don't need to understand the details of the protocol and of its implementation (if you are interested, refer to RFC 1305) and you only need to know how to configure and start some programs. The base system of NetBSD already contains the necessary tools to utilize this protocol (and other time related protocols, as we'll see), derived from the xntp implementation. This section describes a simple method to always have a correct system time.

First, it is necessary to find the address of the public NTP servers to use as a reference; a detailed listing can be found at As an example, for Italy the three stratum 1 servers,, and can be used.

Next, to adjust the system clock give the following command as root:

# ntpdate -b

(substitute the names of the servers in the example with the ones that you are actually using. Option -b tells ntpdate to set the system time with the settimeofday system call, instead of slewing it with adjtime (the default). This option is suggested when the difference between the local time and the correct time can be considerable.

As you've seen, ntpdate is not difficult to use. The next step is to start it automatically, in order to always have the correct system time. If you have a permanent connection to the Internet, you can start the program at boot with the following line of /etc/rc.conf:

ntpdate=YES      ntpdate_hosts=""

The name of the NTP server to use is specified in the ntpdate_hosts variable; if you leave this field empty, the boot script will try to extract the name from the /etc/ntp.conf file.

If you don't have a permanent Internet connection (ex. you have a dial-up modem connection through an ISP) you can start ntpdate from the ip-up script, as explained in Chapter 24, Setting up TCP/IP on NetBSD in practice. In this case add the following line to the ip-up script:

/usr/sbin/ntpdate -s -b

(the path is mandatory or the script will probably not find the executable). Option -s diverts logging output from the standard output (this is the default) to the system syslog(3) facility, which means that the messages from ntpdate will usually end up in /var/log/messages.

Besides ntpdate there are other useful NTP commands. It is also possible to turn one of the local hosts into an NTP server for the remaining hosts of the network. The local server will synchronize its clock with a public server. For this type of configuration you must use the ntpd daemon and create the /etc/ntp.conf configuration file. For example:


ntpd can be started too from rc.conf, using the relevant option:


NTP is not your only option if you want to synchronize your network: you can also use the timed daemon or the rdate(8) command as well. timed was developed for 4.3BSD.

Timed too uses a master-slave hierarchy: when started on a host, timed asks the network time to a master and adjusts the local clock accordingly. A mixed structure, using both timed and ntpd can be used. One of the local hosts gets the correct time from a public NTP server and is the timed master for the remaining hosts of network, which become its clients and synchronize their clocks using timed. This means that the local server must run both NTP and timed; care must be taken that they don't interfere with each other (timed must be started with the -F hostname option so that it doesn't try to adjust the local clock).

Finally, rdate(8) can be used to synchronize once against a given host, much like ntpdate(8). The host in question must have the "time" service (port 37) enabled in /etc/inetd.conf.