Network File System (NFS)

Network File System (NFS)

News	Recommended Links	Sun Documentation	Tutorials	Reference	RPC	RFCs	NFS performance tuning
share command	dfshares Command	dfstab File	Mounting NFS Resources	/etc/vfstab File	AutoFS and automountd daemon	NFS Security	Nfsstat
NFS logging	Troubleshooting	Linux NFS	SFU NFS implementation	History	Tips	Humor	Etc

 

NFS is a network filesystem originally developed by Sun (version 2, see RFC1094) and later enhanced by Network Appliance and other companies (version 3 and 4 of NFS). It works well for sharing file systems between multiple clients, but is slower then some other network filesystems (samba). It is also more fault tolerant then most other network file systems.

 

. With NFS, when a file or directory is shared from a remote machine, it appears to be part of your filesystem.  Every time you access the NFS-linked area, you're going over the network to the other machine, but that's all transparent to you (except for some delays). Because of its popularity, implementations of NFS have been created on other operating systems, for example Windows and Netware. A competing file sharing protocol called SAMBA which originated in Windows was ported and became popular on Unix. 

NFS defines an abstract model of a file system. Each OS applies the NFS model to its file system semantics and implement reading and writing operations as though they are accessing a local file.  NFS is also statelessness. You can reboot a server and the client won't crash. It won't be able to access files on the server's export while the server is down, but once it returns, you'll pick up right where things left off. Other network file sharing systems are not so resilient.

NFS is based on a client-server model. One computer works as a server and offers filesystems to other systems. This is called exporting or sharing and the filesystems offered are called "exports." The clients can mount server exports using an extension of mount command used to mount local filesystems.

File systems shared through NFS software can also be mounted automatically. Autofs, a client-side service, is a change directory intercept mechanism that catches the cases when user changes to NFS directory and transparently mounts it.  the list of mount points should be provided to Autofs as a configuration file. Essentially any I/O operation on s program notifies the automount daemon, automountd,  and it mounts it and then if there is long period of inactivity unmounts it. The automountd, daemon transparently performs mounting and unmounting of remote directories listed it Autofs configuration file on an as-needed basis. The NFS is in turn based on the Remote Procedure Call (RPC) protocol. For this reason, the RPC server daemon must be running for NFS to be implemented. You can check whether RPC is active by issuing this command at the shell prompt:

rpcinfo -p

The NFS service makes the physical location of the file system irrelevant to the user. You can use the NFS implementation to enable users to see all the relevant files regardless of location. Instead of placing copies of commonly used files on every system, the NFS service enables you to place one copy on one computer's disk and have all other systems access it across the network. Under NFS operation, remote file systems are almost indistinguishable from local ones.

Writable NFS-sharable file systems should generally be a separate disk or partition (on server). By having file systems on a separate partition of a harddisk, we can ensure that malicious users can not simply fill up the entire harddisk by writing large files onto it. This will then be able to crash other services running on the same harddisk. Prevent normal users on an NFS client from mounting an NFS file system (on server)

NFS controls who can mount an exported file system based on the host making the mount request, not the user that will actually use the file system. Hosts must be given explicit rights to mount the exported file system. Access control is not possible for users, other than file and directory permissions. In other words, once a file system is exported via NFS, any user on any remote host connected to the NFS server can access the shared data. To limit the potential risks, administrators can only allow read-only access or squashing users to a common user and groupid. But these solutions may prevent the NFS share from being used in the way it was originally intended.

Additionally, if an attacker gains control of the DNS server used by the system exporting the NFS file system, the system associated with a particular hostname or fully qualified domain name can be pointed to an unauthorized machine. At this point, the unauthorized machine is the system permitted to mount the NFS share, since no username or password information is exchanged to provide additional security for the NFS mount. The same risks hold true to compromised NIS servers, if NIS netgroups are used to allow certain hosts to mount an NFS share. By using IP addresses in /etc/exports, this kind of attack is more difficult.

Wildcards should be used sparingly when granting exporting NFS shares as the scope of the wildcard may encompass more systems than intended.

Once the NFS file system is mounted read-write by a remote host, the only protection each shared file has is its permissions. If two users that share the same userid value mount the same NFS file system, they will be able to modify each others files. Additionally, anyone logged in as root on the client system can use the su - command to become a user who could access particular files via the NFS share.

The default behavior when exporting a file system via NFS is to use root squashing. This sets the userid of anyone accessing the NFS share as the root user on their local machine to a value of the server's nobody account. Never turn off root squashing.

If exporting an NFS share read-only, consider using the all_squash option, which makes every user accessing the exported file system take the userid of the nobody user.

Before file systems or directories can be accessed (that is, mounted) by a client through NFS, they must be shared or  exported Once shared, authorized NFS clients can mount the resources. This term most often reflected in directory names for NFS resources such as /export/home or /export/swap.

To start the NFS server daemons or to specify the number of concurrent NFS requests that can be handled by the nfsd daemon, use the /etc/rc3.d/S15nfs.server script. 

You need several daemons to support NFS activities. These daemons can support both NFS client and NFS server activity, NFS server activity alone, or logging of the NFS server activity. To start the NFS server daemons or to specify the number of concurrent NFS requests that can be handled by the nfsd daemon, use the /etc/rc3.d/S15nfs.server script. There are six daemons that support NFS:

1. mountd Handles file system mount requests from remote systems, and provides access control (server)
2. nfsd Handles client file system requests (both client and server)
3. statd Works with the lockd daemon to provide crash recovery functions for the lock manager (server)
4. lockd Supports record locking operations on NFS files
5. nfslogd  Provides filesystem logging. Runs only if one or more filesystems is mounted with log attribute.

You can detect most NFS problems from console messages or from certain symptoms that appear on a client system. Some common errors are:

1. The rpcbind failure error incorrect host Internet address or server overload
    
2. The server not responding error network connection or server is down
    
3. The NFS client fails a reboot error a client is requesting an NFS mount using an entry in the /etc/vfstab file, specifying a foreground mount from a non-operational NFS server.
    
4. The service not responding error an accessible server is not running the NFS server daemons.
    
5. The program not registered error  an accessible server is not running the mountd daemon.
    
6. The stale file handle error [file moved on the server]. To solve the stale NFS file handle error condition, unmount and mount the resource again on the client.
    
7. The unknown host error the host name of the server on the client is missing from the hosts table.
    
8. The mount point error check that the mount point exists on the client
    
9. The no such file error unknown file name on the server
    
10. No such file or directory  the directory does not exists on the server

NFS Server Commands

• share Makes a local directory on an NFS server available for mounting. Without parameters displays the contents of the
  /etc/dfs/sharetab file.
• unshare Makes a previously available directory unavailable for client side mount operations.
• shareall Reads and executes share statements in the /etc/dfs/dfstab file.
• unshareall Makes previously shared resources unavailable.
• dfshares Lists available shared resources from a remote or local NFS server.
• dfmounts Displays a list of NFS server directories that are currently mounted.

NFS resources can be shared using the share command and unshared using the unshare command. In addition, any resources identified in the /etc/dfs/dfstab file are automatically shared at system boot or when the shareall command is used. Shared resources are automatically recorded in the /etc/dfs/sharetab file. When the unshareall command is used, all resources listed in the /etc/dfs/sharetab file are automatically unshared.

The share command is used to share NFS resources so that NFS clients can mount and access them. At a minimum, the full pathname of the directory (or mount point of the file system) to be shared is specified as a command-line argument. In addition, three other command-line arguments are supported:

• The -d command-line argument is followed by a description of the data being shared.

• The -F nfs command-line argument is used to specify the type of file system. If not specified, the default file system type listed in the /etc/dfs/fstypes file (NFS) is assumed.

• The -o command-line argument is followed by one or more NFS-specific options (separated by commas).

For example:

# share -F nfs -o public,ro /export/home

If the share command is used without any command-line arguments, the currently shared resources will be listed.
 

!	NFS server is started on  run level 3.The resources are unshared and the NFS server is stopped when the system run level changes to any level other than 3. The NFS client is started at run level 2.

The unshare command is used to stop the sharing of NFS resources so that NFS clients can no longer mount and access them. At a minimum, the full pathname of a directory (or mount point of the file system) that is currently shared is specified as a command-line argument.

Only one other command-line argument is supported: the -F nfs command-line argument, which is used to specify the type of file system. If not specified, the default file system type listed in the /etc/dfs/fstypes file (NFS) is assumed.

The following listing shows using the unshare command to stop the sharing of the /export/home file system:

# unshare -F nfs /export/home

Solaris uses six configuration files to support NFS server: Three common, one specific for client and two specific for the server

	Server	Client
1.	/etc/dfs/dfstab Lists share commands to share at boot time. Similar to /etc/vfstab for local filesystems.  shareall is essentially sh /etc/dfs/dfstab	Same thing
2.	/etc/dfs/sharetab (autofile)Dynamically lists directories currently being shared by the NFS server.	Same thing
3.	/etc/dfs/fstypes List of the default file system types for each remote file systems.	Same thing
4.	/etc/rmtab (autofile) Lists  remotely mounted file systems
5.	/etc/nfs/nfslog.conf Defines the location of configuration logs used for NFS server logging.
6.	/etc/default/nfslogd Configuration of the nfslogd daemon.

NFS Logging  is accomplished by nfslogd  daemon with the configuration stored in /etc/nfs/nfslog.conf and  /etc/default/nfslogd. The functions of the nfslogd daemon:

• Converts the raw data from the logging operation into ASCII records, and stores the raw data in ASCII log files.
• Resolves IP addresses to host names and UIDs to login names.
• Maps the file handles to path names, and records the mappings in a file-handle-to-path mapping table. Each tag in the /etc/nfs/nfslog.conf file corresponds to one mapping table.

The NFS Logging Daemon monitors and analyzes RPC operations processed by the NFS server. If enabled, each RPC operation is stored in the NFS log file as a record that contains:

• Time stamp

• IP address or hostname of client

• File or directory affected by operation

• Type of operation: input, output, make directory, remove directory, or remove file

The NFS server logging consists of two phases. The first phase is performed by the kernel; it records RPC requests in a work buffer. The second phase is performed by the daemon; it reads the work buffer, constructs and writes the log records. The amount of time the daemon waits before reading the work buffer along with other configurable parameters are specified in the /etc/default/nfslogd file. /etc/default/nfslogd file can contain a number of parameters (the initial nfslogd provided with the Solaris 9 system contains only comments):

• CYCLE_FREQUENCY� Amount of time (in hours) of the log cycle (close current log and open new one). This is to prevent the logs from getting too large.

• IDLE_TIME� Amount of time (in seconds) that the logging daemon will sleep while waiting for data to be placed in the work buffer.

• MAPPING_UPDATE_INTERVAL� The amount of time (in seconds) between updates of the file handle to pathname mapping database.

• MAX_LOGS_PRESERVE� The maximum number of log files to save.

• MIN_PROCESSING_SIZE� Minimum size (in bytes) of the work buffer before the logging daemon will process its contents.

• PRUNE_TIMEOUT� The amount of time (in hours) the access time of a file associated with a record in the pathname mapping database can remain unchanged before it is removed.

• UMASK� umask used for the work buffer and file handle to pathname mapping database.

The /etc/nfs/nfslog.conf file is used to specify the location of log files, file handle to pathname mapping database, and work buffer, along with a few other parameters.  Set of parameters can be grouped together and associated with a tag. this way multiple configurations can be specified in the configuration file. The default configuration has the tag global . the following NFS logging parameters can be set:

• buffer� Specifies location of working buffer.

• defaultdir� Specifies the default directory of files. If specified, this path is added to the beginning of other parameters that are used to specify the location of files.

• fhtable� Specifies location of the file handle to pathname mapping database.

• log� Specifies location of log files.

• logformat� Specifies either basic (default) or extended logging.

For example:

#ident  "@(#)nfslog.conf        1.5     99/02/21 SMI"
#
# Copyright (c) 1999 by Sun Microsystems, Inc.
# All rights reserved.
#
# NFS server log configuration file.
#
# <tag> [ defaultdir=<dir_path> ] \
# [ log=<logfile_path> ] [ fhtable=<table_path> ] \
# [ buffer=<bufferfile_path> ] [ logformat=basic|extended ]
#

global  defaultdir=/var/nfs log=nfslog fhtable=fhtable buffer=nfslog_workbuffer

Logging is enabled on a per-share (file system/directory) basis, by adding the -o log option to the share command. 

Note:

• The configuration file that controls the number of NFS logs created and the permissions on the log files is named atypically:  /etc/default/nfslogd