The remote file system
NFS extends a namespace across a network.
A server exports a directory tree, and an administrator or operating system mounts that export at a client path. After mounting, applications use ordinary file operations such as open, read, write, close, and readdir; the client translates those operations into NFS requests.
NFS is not the same as FTP or SFTP. Those protocols normally transfer files through an explicit client session. NFS presents a shared file-system interface, so latency, caching, failure recovery, permissions, and consistency become part of ordinary application behavior.
The operation path
NFS turns file-system calls into RPC operations.
RPC (Remote Procedure Call) gives the client a request-and-response model for invoking a procedure on a server. An NFS client can ask the server to look up a name, read file data, write data, inspect attributes, create an object, or list a directory. The result travels back as an RPC response, and the client exposes it through the local file-system API.
Older NFS deployments commonly use a port mapper or RPC bind service to discover program numbers and ports for services such as mountd, NFS, and lock management. NFSv4 reduces this collection of auxiliary services by using a more integrated protocol model, commonly over TCP port 2049.
VFS call
The application asks the local operating system to open, read, write, or inspect a path.
RPC request
The client encodes an NFS procedure and sends it to the server.
Server operation
The server checks the export, identity, permissions, and local file system.
RPC response
Status, attributes, directory entries, or file data return to the client.
Protocol generations
NFSv3 and NFSv4 make different operational trade-offs.
NFSv3 is largely stateless for file operations and commonly uses separate RPC services for mounting, port discovery, and locking. A client and server exchange file handles and attributes, while recovery and auxiliary service availability remain important operational concerns.
NFSv4 integrates more of the protocol around a stateful session, uses a compound operation model, supports stronger identity and security integration, and normally uses a single well-known service port. NFSv4.1 and later add features such as sessions, parallel NFS support in suitable deployments, and improved recovery mechanisms.
NFSv3
Older, widely deployed model with separate RPC services and largely stateless file operations.
NFSv4
Integrated protocol with a richer state and security model, commonly using TCP/2049.
File handle
An opaque server reference lets the client identify an exported object without sending a path every time.
Compound request
NFSv4 can combine related operations into one protocol exchange.
Distributed file semantics
Caching improves performance but makes consistency visible.
Clients cache file data and attributes to avoid a network request for every application operation. A cache can reduce latency and server load, but stale attributes or data may appear when several clients access the same file and the workload needs strict coordination.
Locks and leases coordinate selected concurrent operations. A network interruption can leave a client waiting, retrying, or temporarily unable to confirm whether an operation completed. NFS application behavior therefore depends on timeout, retransmission, cache, lock, and recovery semantics rather than on throughput alone.
Identity and protection
The export policy is only one part of NFS security.
Server export rules determine which clients may access an export and with which options. Traditional AUTH_SYS-style identity relies on client-supplied numeric user and group IDs, so it requires a trusted identity boundary. Root squashing can prevent a remote root user from being treated as server root.
NFSv4 can use RPCSEC_GSS mechanisms such as Kerberos for stronger authentication, integrity, or privacy, depending on the configured security flavor. Encryption of the network path, least-privilege exports, identity consistency, ACLs, and server-side permissions must be considered together.
Mini investigation
Inspect a failing mount
Select the strongest clue and identify the next check.
The server may reject the client address, export path, security flavor, or identity.
Check the export policy, client identity, NFS version, and server logs.
Knowledge check
Test your NFS model
Answer eight questions.