샤브의 블로그 RSS 태그 관리 글쓰기 방명록
nfs (2)
2010-09-05 00:09:20

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.

  • UMASKumask 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

2010-09-05 00:07:35
출처 짜세나게 달려보자 !!! | 짜세맨
원문 http://blog.naver.com/831jsh/70047794179

원본 : http://www.softpanorama.org/Net/Application_layer/NFS/troubleshooting_of_nfs_problems.shtml

 

Troubleshooting Solaris NFS Problems

 

News NFS overview Recommended Links Sun Documentation Tutorials Reference HOWTO FAQs RFCs  
rpcbind failure error server not responding error  NFS client fails a reboot error service not responding error  program not registered error stale file handle error  unknown host error  mount point error  no such file error No such file or directory

 

Some common NFS errors are:

  1. The rpcbind failure error
  2. The server not responding error
  3. The NFS client fails a reboot error
  4. The service not responding error
  5. The program not registered error
  6. The stale file handle error
  7. The unknown host error
  8. The mount point error
  9. The no such file error
  10. No such file or directory

Troubleshooting recommendations:

  1. The rpcbind failure Error. The following example shows the message that appears on the client
    system during the boot process or in response to an explicit mount request:
    • nfs mount: server1:: RPC: Rpcbind failure
      RPC: Timed Out
      nfs mount: retrying: /mntpoint

    The error in accessing the server is due to:

    • The combination of an incorrect Internet address and a correct host or node name in the hosts database file supporting the client node.
    • The hosts database file that supports the client has the correct server node, but the server node temporarily stops due to an overload.
    To solve the rpcbind failure error condition when the server node is operational, determine if the server is out of critical resources (for example, memory, swap, or disk space).
     
  2. The server not responding Error The following message appears during the boot process or in response to an explicit mount request, and this message indicates a known server that is inaccessible.

    NFS server server2 not responding, still trying

     Possible causes for the server not responding error are:

    • The network between the local system and the server is down. To verify that the network is down, enter the ping command (ping server2).
    •  The server ( server2) is down.
       
    The NFS client fails a reboot Error. If you attempt to boot an NFS client and the client-node stops, waits, and echoes the following message:

    Setting default interface for multicast: add net 224.0.0.0: gateway:
    client_node_name.

    these symptoms might indicate that 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.

    To solve this error, complete the following steps:

    1. To interrupt the failed client node press Stop-A, and boot the client into single-user mode.

    2. Edit the /etc/vfstab file to comment out the NFS mounts.

    3. To continue booting to the default run level (normally run level 3), press Control-D.

    4. Determine if all the NFS servers are operational and functioning properly.

    5. After you resolve problems with the NFS servers, remove the comments from the /etc/vfstab file.

    Note – If the NFS server is not available, an alternative to commenting out
    the entry in the /etc/vfstab file is to use the bg mount option so that the
    boot sequence can proceed in parallel with the attempt to perform the NFS mount.
     

  3. The service not responding ErrorThe following message appears during the boot process or in response to an explicit mount request, and indicates that an accessible server is not running the NFS server daemons.


    nfs mount: dbserver: NFS: Service not responding
    nfs mount: retrying: /mntpoint

    To solve the service not responding error condition, complete the following steps:

    1.  Enter the who -r command on the server to see if it is at run level 3. If the server is not, change to run level 3 by entering the init 3 command.
    2. Enter the ps -e command on the server to check whether the NFS server daemons are running. If they are not, start them by using the /etc/init.d/nfs.server start script.
       
  4. The program not registered Error. The following message appears during the boot process or in response to an explicit mount request and indicates that an accessible server is not running the mountd daemon.

    nfs mount: dbserver: RPC: Program not registered
    nfs mount: retrying: /mntpoint

    To solve the program not registered error condition, complete the following steps:

    1.  Enter the who -r command on the server to check that it is at run level 3. If the server is not, change to run level 3 by performing the init 3 command.
    2.  Enter the pgrep -xl mountd command. If the mountd daemon is not running, start it using the /etc/init.d/nfs.server script, first with the stop flag and then with the start flag.
    3.  Check the /etc/dfs/dfstab file entries.
       
  5. The stale NFS file handle Error. The following message appears when a process attempts to access a
    remote file resource with an out-of-date file handle.  A possible cause for the stale NFS file handle error is that the file resource on the server moved. To solve the stale NFS file handle error condition, unmount and mount the resource again on the client.
     
  6. The unknown host Error. The following message indicates that the host name of the server on the client is missing from the hosts table.

    nfs mount: sserver1:: RPC: Unknown host

    To solve the unknown host error condition, verify the host name in the hosts database that supports the client node. Note – The preceding example misspelled the node name server1 as sserver1.
     

  7. The mount point Error. The following message appears during the boot process or in response to
    an explicit mount request and indicates a non-existent mount point.

    mount: mount-point /DS9 does not exist.

    To solve the mount point error condition, check that the mount point exists on the client. Check the spelling of the mount point on the command line or in the /etc/vfstab file on the client, or comment out
    the entry and reboot the system.
     

  8. The no such file Error. The following message appears during the boot process or in response to
    an explicit mount request, which indicates that there is an unknown file
    resource name on the server.
     
  9. No such file or directory To solve the no such file error condition, check that the directory exists
    on the server. Check the spelling of the directory on the command line or in the /etc/vfstab file.

Use of NFS Considered Harmful  

First of all usage of 'considered harmful" usually signify primitive fundamentalist stance of the critique. Also this critique is applicable only to older versions of protocols. NFS v.4 contains some improvements

Following are a few known problems with NFS and suggested workarounds.

a. Time Synchronization

NFS does not synchronize time between client and server, and offers no mechanism for the client to determine what time the server thinks it is. What this means is that a client can update a file, and have the timestamp on the file be either some time long in the past, or even in the future, from its point of view.

While this is generally not an issue if clocks are a few seconds or even a few minutes off, it can be confusing and misleading to humans. Of even greater importance is the affect on programs. Programs often do not expect time difference like this, and may end abnormally or behave strangely, as various tasks timeout instantly, or take extraordinarily long while to timeout.

Poor time synchronization also makes debugging problems difficult, because there is no easy way to establish a chronology of events. This is especially problematic when investigating security issues, such as break in attempts.

Workaround: Use the Network Time Protocol (NTP) religiously. Use of NTP can result in machines that have extremely small time differences.

Note: The NFS protocol version 3 does have support for the client specifying the time when updating a file, but this is not widely implemented. Additionally, it does not help in the case where two clients are accessing the same file from machines with drifting clocks.

b. File Locking Semantics

Programs use file locking to insure that concurrent access to files does not occur except when guaranteed to be safe. This prevents data corruption, and allows handshaking between cooperative processes.

In Unix, the kernel handles file locking. This is required so that if a program is terminated, any locks that it has are released. It also allows the operations to be atomic, meaning that a lock cannot be obtained by multiple processes.

Because NFS is stateless, there is no way for the server to keep track of file locks - it simply does not know what clients there are or what files they are using. In an effort to solve this, a separate server, the lock daemon, was added. Typically, each NFS server will run a lock daemon.

The combination of lock daemon and NFS server yields a solution that is almost like Unix file locking. Unfortunately, file locking is extremely slow, compared to NFS traffic without file locking (or file locking on a local Unix disk). Of greater concern is the behaviour of NFS locking on failure.

In the event of server failure (e.g. server reboot or lock daemon restart), all client locks are lost. However, the clients are not informed of this, and because the other operations (read, write, and so on) are not visibly interrupted, they have no reliable way to prevent other clients from obtaining a lock on a file they think they have locked.

In the event of client failure, the locks are not immediately freed. Nor is there a timeout. If the client process terminates, the client OS kernel will notify the server, and the lock will be freed. However, if the client system shuts down abnormally (e.g. power failure or kernel panic), then the server will not be notified. When the client reboots and remounts the NFS exports, the server is notified and any client locks are freed.

If the client does not reboot, for example if a frustrated user hits the power switch and goes home for the weekend, or if a computer has had a hardware failure and must wait for replacement parts, then the locks are never freed! In this unfortunate scenario, the server lock daemon must be restarted, with the same effects as a server failure.

Workaround: If possible (given program source and skill with code modification), remove locking and insure no inconsistency occurs via other mechanisms, possibly using atomic file creation (see below) or some other mechanism for synchronization. Otherwise, build platforms never fail and have a staff trained on the implications of NFS file locking failure. If NFS is used only for files that are never accessed by more than a single client, locking is not an issue.

Note: A status monitor mechanism exists to monitor client status, and free client locks if a client is unavailable. However, clients may chose not to use this mechanism, and in many implementations do not.

c. File Locking API

In Unix, there are two flavours of file locking, flock() from BSD and lockf() from System V. It varies from system to system which of these mechanisms work with NFS. In Solaris, Sun's Unix variant, lockf() works with NFS, and flock() is implemented via lockf(). On other systems, the results are less consistent. For example, on some systems, lockf() is not implemented at all, and flock() does not support NFS; while on other systems, lockf() supports NFS but flock() does not.

Regardless of the system specifics, programs often assume that if they are unable to obtain a lock, it is because another program has the lock. This can cause problems as programs wait for the lock to be freed. Since the reason the lock fails is because locking is unsupported, the attempt to obtain a lock will never work. This results in either the applications waiting forever, or aborting their operation.

These results will also vary with the support of the server. While typically the NFS server runs an accompanying lock daemon, this is not guaranteed.

Workaround: Upgrade to the latest versions of all operating systems, as they usually have improved and more consistent locking support. Also, use the lock daemon. Additionally, try to use only programs written to handle NFS locking properly, veified either by code review or a vendor compliance statement.

d. Exclusive File Creation

In Unix, when a program creates a file, it may ask for the operation to fail if the file already exists (as opposed to the default behaviour of using the existing file). This allows programs to know that, for example, they have a unique file name for a temporary file. It is also used by various daemons for locking various operations, e.g. modifying mail folders or print queues.

Unfortunately, NFS does not properly implement this behaviour. A file creation will sometimes return success even if the file already exists. Programs written to work on a local file system will experience strange results when they attempt to update a file after using file creation to lock it, only to discover another file is modifying it (I have personally seen mailboxes with hundreds of mail messages corrupted because of this), because it also "locked" the file via the same mechanism.

Workaround: If possible (given program source and skill with code modification), use the following method, as documented in the Linux open() manual page:

The solution for performing atomic file locking using a lockfile is to create a unique file on the same fs (e.g., incorporating hostname and pid), use link(2) to make a link to the lockfile and use stat(2) on the unique file to check if its link count has increased to 2. Do not use the return value of the link() call.

This still leaves the issue of client failure unanswered. The suggested solution for this is to pick a timeout value and assume if a lock is older than a certain application-specific age that it has been abandoned.

e. Delayed Write Caching

In an effort to improve efficiency, many NFS clients cache writes. This means that they delay sending small writes to the server, with the idea that if the client makes another small write in a short amount of time, the client need only send a single message to the server.

Unix servers typically cache disk writes to local disks the same way. The difference is that Unix servers also keep track of the state of the file in the cache memory versus the state on disk, so programs are all presented with a single view of the file.

In NFS caching, all applications on a single client will typically see the same file contents. However, applications accessing the file from different clients will not see the same file for several seconds.

Workaround: It is often possible to disable client write caching. Unfortunately, this frequently causes unacceptably slow performance, depending on the application. (Applications that perform I/O of large chunks of data should be unaffected, but applications that perform lots of small I/O operations will be severely punished.) If locking is employed, applications can explicitly cooperate and flush files from the local cache to the server, but see the previous sections on locking when employing this solution.

f. Read Caching and File Access Time

Unix file systems typically have three times associated with a file: the time of last modification (file creation or write), the time of last "change" (write or change of inode information), or the time of last access (file execution or read). NFS file systems also report this information.

NFS clients perform attribute caching for efficiency reasons. Reading small amounts of data does not update the access time on the server. This means a server may report a file has been unaccessed for a much longer time than is accurate.

This can cause problems as administrators and automatic cleanup software may delete files that have remained unused for a long time, expecting them to be stale lock files, abandoned temporary files and so on.

Workaround: Attribute caching may be disabled on the client, but this is usually not a good idea for performance reasons. Administrators should be trained to understand the behaviour of NFS regarding file access time. Any programs that rely on access time information should be modified to use another mechanism.

g. Indestructible Files

In Unix, when a file is opened, the data of that file is accessible to the process that opened it, even if the file is deleted. The disk blocks the file uses are freed only when the last process which has it open has closed it.

An NFS server, being stateless, has no way to know what clients have a file open. Indeed, in NFS clients never really "open" or "close" files. So when a file is deleted, the server merely frees the space. Woe be unto any client that was expecting the file contents to be accessible as before, as in the Unix world!

In an effort to minimize this as much as possible, when a client deletes a file, the operating systems checks if any process on the same client box has it open. If it does, the client renames the file to a "hidden" file. Any read or write requests from processes on the client that were to the now-deleted file go to the new file.

This file is named in the form .nfsXXXX, where the XXXX value is determined by the inode of the deleted file - basically a random value. If a process (such as rm) attempts to delete this new file from the client, it is replaced by a new .nfsXXXX file, until the process with the file open closes it.

These files are difficult to get rid of, as the process with the file open needs to be killed, and it is not easy to determine what that process is. These files may have unpleasant side effects such as preventing directories from being removed.

If the server or client crashes while a .nfsXXXX file is in use, they will never be deleted. There is no way for the server or a client to know whether a .nfsXXXX file is currently being used by a client or not.

Workaround: One should be able to delete .nfsXXXX files from another client, however if a process writes to the file, it will be created at that time. It would be best to exit or kill processes using an NFS file before deleting it. Unfortunately, there is no way to know if an uncooperative process has a file open.

h. User and Group Names and Numbers

NFS uses user and group numbers, rather than names. This means that each machine that accesses an NFS export needs (or at least should) have the same user and group identifiers as the NFS export has. Note that this problem is not unique to NFS, and also applies, for instance, to removable media and archives. It is most frequently an issue with NFS, however.

Workaround: Either the /etc/passwd and /etc/group files must be synchronized, or something like NIS needs to be used for this purpose.

i. Superuser Account

NFS has special handling of the superuser account (also known as the root account). By default, the root user may not update files on an NFS mount.

Normally on a Unix system, root may do anything to any file. When an NFS drive has been mounted, this is no longer the case. This can confuse scripts and administrators alike.

To clarify: a normal user (for example "shane" or "billg") can update files that the superuser ("root") cannot.

Workaround: Enable root access to specific clients for NFS exports, but only in a trusted environment since NFS is insecure. Therefore, this does not guarantee that unauthorized client will be unable to access the mount as root.