- "File not found" or ENOENT problems, are almost always a
client issue. Automounter maps, /etc/vfstab, or volume manager
configuration files should be your starting points. If the client can't
even find the file, the client is probably at fault.
- EACCESS problems can be caused by inconsistent user and group
numbering, or by the root-to-nobody mapping problems described above.
While responsibility for presenting valid user and group values falls
on the client, you're also bumping into name server and file server
issues. Like ENOENT errors, these are reported by the calling process,
showing up on the command line or in a dialog box created by the
- "NFS write error" or "Stale file handle" errors are
server-specific. An error occurred on the server while handling the NFS
request, causing it to fail. You'll see these reported in the console
window and in the /var/adm/messages log, since the errors are
noticed by the kernel's NFS Remote Procedure Call (RPC) code.
NFS errors tend to be hard
to resolve because you're assigning
blame in more than one operating
system and host environment.
You have to follow the trail of network crumbs from the client back
to the server to resolve server-specific errors. Your first step: get a
general feeling for what went wrong using the NFS error number in the
console message. NFS uses the standard errno values, so "NFS write
error 28" is the same as ENOSPC, namely, the disk is full or the user
exceeded his or her disk quota while writing a file. Many NFS errors
have obvious explanations: bumping against quotas, filling up a disk,
or a disk failure that results in a general I/O error. The more
difficult one to chase is a stale file handle.
NFS file handles encode the server's filesystem ID and the file's
inode number to uniquely identify each NFS-mounted file. Each inode
also contains an inode generation number used to differentiate files
that have re-used an inode. Delete a file, for example,
/home/stern/summary, and then create a new file, say
/home/stern/report on the same filesystem. The new file
re-uses the same inode number as the previously deleted file (assuming
no other file creation activity snuck in) but increments the inode
generation number to distinguish it from the old, removed file.