NFS

 

Files may be shared from one system to another using the Network File System (NFS), which is a distributed file system. In a distributed file system data and metadata are delivered to the client system over the network from a disk-based file system on a server. Such files appear to the user to be on the local system, but are actually on a remote system. 

 

NFS is a TCP/IP standard: the original standard is described in RFC 1094. There are three versions currently in wide use on Solaris, Linux and Windows machines: NFS 2, 3 and 4. Solaris 9 and earlier implemented NFS 2 and 3, Solaris 10 implements NFS 4 by default, but also provides NFS 2 and 3 for backwards compatibility.

 

This powerful capability of Solaris makes it much easier to use and administer file systems in a LAN.  Software packages may be shared from one host, while another serves man pages.  User home directories are on still another.  The man page server requires no backup, and it frees other systems from having to dedicate space for man pages.  User home directories can be accessed by a user logging in on any client system, but need be backed up on only one.  Software packages can be installed and maintained on only one system.

 

This paper discusses how to share file systems on a server, remotely mount them on a client, and have them automatically mounted at boot time for NFS versions 2, 3 and 4.

 

 Sharing and Accessing File Resources in a Nutshell

 

SHARE

 

# share <absolute path to resource>

 

for example:

 

# share  /export

 

MOUNT

 

# cd /net/<NFS server name>/<resource>

 

for example:

 

# cd /net/nfs-serv/export

 

THAT’S IT!

________________________________________________

 

Solaris 10 allows the administrator to share a resource using the “share” command without setting up any files, or manually starting any daemons. Resources shared this way are NOT persistent across reboot, but this command is extremely convenient for quick file shares.

 

NFS Server Setup

 

Any machine that shares files to be mounted by another host is a file server.  With the exception of the above command, file servers must be set up to share specified files, sharing does not happen automatically.

 

Three things must happen for a system to share resources:

1. The file /etc/dfs/dfstab must have at least one entry of the form:

 

share  /path_to_resource

 

A  dfstab entry is a share command just as it would be issued at the command line. The file /etc/dfs/dfstab is read when the system enters run level 3, IF there are entries, which by default, there are not.

 

Resources do not have to be listed in /etc/dfs/dfstab in order to be shared; they may be shared at the command line, but if there are no entries at all in /etc/dfs/dfstab, then it's impossible to share anything else in Solaris 9 and earlier, and it’s impossible to share at boot in Solaris 10. 

 

2a.  For versions 2 and 3 of NFS, the NFS server daemons nfsd, mountd, lockd and statd must be running.  These are started by the script /etc/init.d/nfs.server if there is at least one entry in /etc/dfs/dfstab.  The daemon mountd provides a file handle to a client system so it can mount the remote resource; nfsd provides files to the client once the remote resource has been mounted. The script /etc/init.d/nfs.server is automatically run when the system enters run level 3; if there is at least one entry in /etc/dfs/dfstab, the daemons will be started. 

 

2b. For version 4 of NFS, the NFS server daemons nfsd, nfsmapid and nfs4cbd must be running. These are started by the SMF when the OS enters run level 3, if there is a share entry in /etc/dfs/dfstab. This entry is identical to that used by NFS 2 and 3.

 

3. The resource must be shared, using the command "share" or "shareall".  If the resource has an entry in /etc/dfs/dfstab, it will be shared when the system reaches run level 3, or when

 

# /etc/init.d/nfs.server start              (Solaris 9 and earlier)

 

OR

 

# svcadm enable nfs/server (Solaris 10)

 

is run, or when the command "shareall" is issued at the command line.  If the resource does not have an entry in /etc/dfstab, it will be shared when the explicit share command is issued on the command line.

 

Share/unshare/shareall/unshareall/dfshares/dfmounts

 

share

The share command is similar in syntax to "mount".  Whether in /etc/dfs/dfstab or issued at the command line the syntax is:

 

share [-F nfs] [-o options] [-d any_comment] path_of_resource

 

-F can be followed by any file system type, but the default argument is "nfs," so it is rarely necessary to use this. 

-o may include

ro        read only - this is a good security measure: for man pages for example.

rw       read/write allows clients to read and write to files (default).

 

The clients allowed to read or read and write the file system may be restricted by rw=client1:client2:etc... or ro=client1:client2:etc...

The list after rw= or ro= may be in the form hostname,  @129.31.3 (for example), for all systems starting with the given values, or .domain.com (for example) for all computers in the given domain, or netgroupname.

 

This provides authentication, which allows the server to control which hosts have access to NFS shared file systems. It is a very weak form of security and hacks to bypass it are well-known. NFS servers should be firewalled if security is an issue. Typically NFS is used within a data center, and a gateway filters NFS packets going to or coming from the Internet. NFS 4 uses a well-known port: 2049, which simplifies firewalling.

 

root=hostname          allows root on the named system to perform superuser requests on the resource shared. Default is no root access.

 

anon=EUID    where EUID is the effective UID that will be assigned to users with unknown UIDs.  Such users are root or PPP users or users from non-Unix machines, or other users which can not provide Unix-style authentication of their identity.  If anon=0, root users from clients will be given root privileges on the file systems shared.  If anon=300, and user 300 is tammy, then root users from clients will have the privileges that tammy has on the file system.  If anon=-1, unknown users are denied access.  The default is for anon to be set to the UID of "nobody".

 

unshare/shareall/unshareall/dfshares/dfmounts

 

unshare resource_path stops sharing the resource

shareall shares all resources listed in /etc/dfs/dfstab

unshareall stops sharing all resources.  To find which resources to stop sharing, this command looks in the file /etc/dfs/sharetab, where a list of currently shared resources is kept.

dfshares [hostname] lists all shared resources on the local server, or on the server whose hostname is given.  dfshares reads the file /etcdfs//sharetab.

dfmounts lists all shared resources on the local system and the clients which are using them.  dfmounts reads the file /etc/rmtab.

 

 

Mounting remote resources

 

No special set up is required to mount resources.  The daemons required, statd and lockd for NFS 2 and 3, and nfsd for NFS 4, are started automatically as the system enters run level 2. Notice that resources are mounted at run level 2, but shared at run level 3. If two systems each shares a resource that the other mounts, this can cause problems in the case of a LAN-wide power outage. Both hosts can hang at run level 2, waiting to mount the resource provided by the other host!

 

Local vs remote

Mounting remote resources is quite similar to mounting local resources:  As you may recall: local resources are mounted either at the command line or automatically at boot time with an entry in the file /etc/vfstab.  Similarly, remote resources are either mounted at the command line, or automatically with an entry in /etc/vfstab.  There are three major differences between mounting a local resource, and mounting a remote one:

 

1. The file system type for a remote resource is nfs.

 

2.  Remote file systems have no entries in the fields in /etc/vfstab concerned with fsck.

 

3. The name of the resource is given in POSIX style; hostname:pathname

 

mount/mountall/umount/umountall

 

The mount command for remote resources is:

 

# mount -o (any options, such as rw, largefiles or ro) hostname:/path_to_resource   /mount_point

 

As you can see, the main differences from a command to mount a local resource are the file system type, and the style in which the resource is named. 

 

Remote mounts may call on multiple hosts for the remote resource: If several, comma-separated server names are listed after the mount command and before the pathname, the servers are tried in order.

 

mount -F nfs -o (any options, such as rw, largefiiles or ro) hostname,host2,host3:path_to_resource mount_point

 

In the file /etc/vfstab, remote mount entries are set up like this:

 

hostname:/path                        -           /mountpoint     nfs       -           yes            options

 

Once again...the only difference is that the file system type is nfs, the resource to mount is listed in POSIX style, and fsck options are omitted.

 

The important options used with mount commands are:

 

rw – (default) read/write

ro  - read only. Both "share" and "mount" may independently impose restrictions on the use of remotely mounted resources. Why to do this: If a resource is shared ro but mounted rw, the access time (atime) is updated on the server. If the resource is mounted ro, the atime is not updated, reducing system overhead, disk access and network traffic.

retrans=m –(default = 5)  the number of times the system tries to get a requested resource from a mounted file system before it returns an error.

soft|hard (default hard) – when a remotely mounted resource is requested (for example, a user tries to read a file from a remote machine) a soft mount tries the server retrans  times, and if there is no response, the system returns an error and stops trying to access the resource.  A hard mount keeps trying until the resource is accessed.  Essential resources, such as /usr or /export/home should be hard mounted, since there is not much use to having the computer running without them.  Non-essential resources, such as software, may be soft mounted.

bg|fg  (default fg): At boot time, if a server does not respond to one mount request, further attempts to mount the resource, up to retry times, take place on the background so that the boot can finish. fg: if a server does not respond to a mount request, further attempts to mount the resource, up to retry times, take place in the foreground and the boot does not complete. If two hosts are set up to mount resources shared by the other, the entry in /etc/vfstab MUST contain “bg” or both hosts can hang.

intr/nointr (default intr)– if a hard mounted resource fails to mount so that boot hangs, a keyboard interrupt (CNTL-C) will/won't kill the attempt so that boot can finish.

suid/nosuid - this is the same as suid/nosuid on a locally mounted resource.  For security purposes, you may want to disable setuid.

retry=n – (default = 10,000) - the number of times the system tries to mount a resource before returning an error.

timeo=n – where n is the number of tenths of a second before timeout occurs for a request to a mounted file system. This option has been made obsolete by changes in TCP/IP protocols.

 

mountall - mounts all resources with entries in /etc/vfstab

mountall -l  mounts local resources with entries in /etc/vfstab

mountall -r mounts remote resources with entries in /etc/vfstab

umount mountpoint - unmounts the named resource

umountall (-l or -r) unmounts all mounted resources except /, /var and /usr. To find which resources to unmount, umountall looks in the file /etc/mnttab.