Network File Systems - Learning Module

Loading content...

0/240

NFS Versions

Four Decades of Evolution

NFS has undergone remarkable evolution since its 1984 debut. Each major version addressed limitations discovered through real-world deployment, incorporated lessons from distributed systems research, and adapted to changing network environments—from 10 Mbps Ethernet LANs to global data centers connected by optical fiber.

Understanding NFS versions isn't merely academic. In production environments, you'll encounter all versions: legacy systems running NFSv3, modern Linux deployments on NFSv4.2, and everything in between. Knowing the capabilities and limitations of each version helps you:

Choose the right version for new deployments
Understand behavior differences when troubleshooting
Plan migration strategies for version upgrades
Configure interoperability between different systems

What You Will Learn

By the end of this page, you will understand the architectural differences between NFSv2, NFSv3, NFSv4.0, NFSv4.1, and NFSv4.2. You'll learn the key features introduced in each version, their practical implications, and be able to recommend appropriate versions for different deployment scenarios.

NFS Version History Overview

NFS Version Timeline and Key Characteristics
Version	Year	RFC/Spec	Key Innovation
NFSv2	1984	RFC 1094 (1989)	Original stateless protocol, 32-bit file sizes
NFSv3	1995	RFC 1813	64-bit files, async writes, WCC, TCP support
NFSv4.0	2003	RFC 3530 → 7530	Stateful ops, compound RPCs, ACLs, integrated locking
NFSv4.1 (pNFS)	2010	RFC 5661	Sessions, parallel/cluster NFS, directory delegations
NFSv4.2	2016	RFC 7862	Server-side copy, space reservation, labeled NFS, sparse files

Backward Compatibility Strategy

NFS maintains strong backward compatibility through graceful negotiation:

Client requests highest version it supports
Server responds with highest version it supports (≤ client's request)
Both sides operate at the negotiated version

This allows gradual infrastructure upgrades—a new server can serve both legacy and modern clients simultaneously.

# Force specific version on mount
mount -t nfs -o vers=3 server:/export /mnt    # Force NFSv3
mount -t nfs -o vers=4 server:/export /mnt    # Force NFSv4.0
mount -t nfs -o vers=4.2 server:/export /mnt  # Force NFSv4.2

# Check negotiated version
nfsstat -m  # Shows mount options including version

Converting Mermaid diagram...

NFSv2: The Original Protocol

NFSv2, released with SunOS 2.0 in 1984, established the fundamental NFS model that persists today. Understanding NFSv2's limitations explains why its successors evolved as they did.

Core Characteristics of NFSv2:

Transport: UDP only (TCP added by some vendors later)
File Size: 32-bit offsets (maximum 2GB files)
Write Semantics: Synchronous only
File Handles: Fixed 32 bytes
Maximum Read/Write: 8KB per operation

NFSv2 Procedure Definitions
Proc	Name	Description
0	NULL	Null procedure for testing
1	GETATTR	Get file attributes
2	SETATTR	Set file attributes
3	ROOT	Get file system root (obsolete)
4	LOOKUP	Look up file name
5	READLINK	Read symbolic link
6	READ	Read from file
7	WRITECACHE	Write to cache (obsolete)
8	WRITE	Write to file
9	CREATE	Create file
10	REMOVE	Remove file
11	RENAME	Rename file
12	LINK	Create hard link
13	SYMLINK	Create symbolic link
14	MKDIR	Create directory
15	RMDIR	Remove directory
16	READDIR	Read directory entries
17	STATFS	Get file system statistics

NFSv2 Limitations That Drove NFSv3

NFSv2 Pain Points

•2GB File Limit — 32-bit offsets meant files larger than 2GB were impossible. As disk sizes grew, this became a critical limitation for databases and multimedia.
•Synchronous Writes — Every WRITE had to complete on server disk before returning. WRITE, fsync, return. Killed performance for write-heavy workloads.
•UDP Only (Practical) — While some vendors added TCP, the protocol was designed for UDP. Lost packets caused visible delays; WAN deployment was painful.
•8KB Max Transfer — Read/write operations were limited to 8KB. Large file transfers required many round trips.
•No Access Check — Clients couldn't check access before attempting operations, leading to failed operations and confusing error messages.
•Limited Error Information — Error codes were sparse; diagnosing failures was often guesswork.

NFSv2 Today

NFSv2 is effectively obsolete. Most modern NFS implementations disable it by default. However, you might encounter it on very old embedded systems or in legacy industrial equipment. If forced to use NFSv2, be aware of the 2GB file limit and performance constraints.

NFSv3: The Industry Workhorse

NFSv3 (RFC 1813, 1995) addressed NFSv2's most painful limitations while maintaining the stateless model. It became the dominant NFS version for over a decade and remains widely deployed today.

Key NFSv3 Improvements:

NFSv3 Enhancements

•64-bit File Sizes — Supports files up to 2^63 bytes (8 exabytes), eliminating the 2GB barrier
•Asynchronous Writes — Server can acknowledge writes before disk commit, dramatically improving performance
•Weak Cache Consistency (WCC) — Pre/post operation attributes help clients maintain cache coherence
•TCP Support — Official TCP transport for reliable WAN deployment
•Larger Transfers — Up to 1MB read/write per operation (implementation dependent)
•ACCESS Procedure — Check permissions before attempting operations
•READDIRPLUS — Get attributes with directory entries, reducing round trips
•Variable File Handles — Up to 64 bytes (better for complex file systems)

Asynchronous Writes: The Game Changer

NFSv3's asynchronous write capability was transformative for performance. The WRITE procedure includes a stable parameter:

WRITE Stability Modes:

UNSTABLE (0):  "Write to server memory, don't wait for disk"
               Fast, but data at risk if server crashes
               
DATA_SYNC (1): "Write data to disk, metadata can be cached"
               Moderate speed, data safe, metadata at risk
               
FILE_SYNC (2): "Write everything to disk before returning"
               Slow, full durability (like NFSv2)

The COMMIT procedure complements UNSTABLE writes:

Client sends multiple UNSTABLE writes (fast)
Client sends COMMIT covering all written ranges
Server flushes to disk and returns
Client knows data is durable

NFSv3 Write Patterns

Protocol Example

=== Synchronous Write Pattern (Safe but Slow) ===
 
Client                              Server
  |                                    |
  |-- WRITE(stable=FILE_SYNC, 0-8K) ->|  Write + fsync
  |<- OK, committed=FILE_SYNC --------|  8K durable on disk
  |                                    |
  |-- WRITE(stable=FILE_SYNC, 8K-16K)->|  Write + fsync
  |<- OK, committed=FILE_SYNC --------|  16K durable on disk
  |                                    |
  Total: 2 disk syncs, ~20ms latency each = ~40ms minimum
 
 
=== Asynchronous Write Pattern (Fast) ===
 
Client                              Server
  |                                    |
  |-- WRITE(stable=UNSTABLE, 0-8K) -->|  Write to memory
  |<- OK, committed=UNSTABLE ---------|  
  |                                    |
  |-- WRITE(stable=UNSTABLE, 8K-16K)->|  Write to memory
  |<- OK, committed=UNSTABLE ---------|  
  |                                    |
  |-- COMMIT(0, 16K) ---------------->|  Flush all to disk
  |<- OK, verf=XYZ -------------------|  Now durable
  |                                    |
  Total: 1 disk sync, much lower latency!
 
 
=== Server Crash During Async Writes ===
 
Client                              Server
  |                                    |
  |-- WRITE(UNSTABLE, 0-8K) --------->|  In memory
  |<- OK ------------------------------|
  |-- WRITE(UNSTABLE, 8K-16K) -------->|  In memory  
  |<- OK ------------------------------|
  |                                    X  CRASH! (data lost)
  |-- COMMIT(0, 16K) ----------------->|  Server reboots
  |<- ERROR or different verf ---------|
  |                                    |
  |  Client detects verf changed,     |
  |  must re-send all writes!         |
  |                                    |

Weak Cache Consistency (WCC)

WCC provides pre-operation and post-operation attributes with modifying operations. This lets clients detect concurrent modifications:

/* WCC example: WRITE response */
struct WRITE3resok {
    wcc_data     file_wcc;        /* Before/after attributes */
    count3       count;           /* Bytes written */  
    stable_how   committed;       /* How stable is the write? */
    writeverf3   verf;            /* Server write verifier */
};

struct wcc_data {
    pre_op_attr  before;          /* size, mtime, ctime before */
    post_op_attr after;           /* Full attrs after */
};

The client compares before with its cached attributes:

Match: cache was valid, update with after attributes
Mismatch: someone else changed the file, invalidate cache

NFSv3 Is Still Great for Many Workloads

NFSv3 remains an excellent choice for many scenarios: excellent performance, simple configuration, wide compatibility, and no complex state to manage. For purely Linux environments, NFSv4 has advantages, but NFSv3 shouldn't be dismissed as 'old'.

NFSv4.0: The Complete Redesign

NFSv4 (RFC 3530, 2003) was not an incremental update—it was a fundamental redesign. The IETF working group incorporated lessons from AFS, CIFS, and distributed systems research to create a more robust, secure, and WAN-friendly protocol.

Philosophical Shifts in NFSv4:

NFSv4 Design Philosophy

•Single Protocol — No more separate mount, lock, and NFS protocols. Everything (including locking) is part of NFS itself.
•Single Port — All operations through TCP port 2049. Firewall-friendly, NAT-friendly.
•Stateful Operations — Delegations, open state, and integrated locking provide correctness guarantees that statelessness couldn't.
•Compound Operations — Multiple operations in a single RPC reduce round trips dramatically.
•Strong Security — First-class support for Kerberos (RPCSEC_GSS) and NFSv4 ACLs.
•Internet-Ready — Designed for WAN deployment, not just LANs.

Compound Operations: Reducing Round Trips

NFSv4 allows multiple operations in a single RPC call. Consider accessing /export/home/alice/project/README.md:

NFSv3 requires:

RPC 1: LOOKUP(export_fh, "home")     → home_fh
RPC 2: LOOKUP(home_fh, "alice")     → alice_fh
RPC 3: LOOKUP(alice_fh, "project")  → project_fh
RPC 4: LOOKUP(project_fh, "README.md") → file_fh
RPC 5: READ(file_fh, 0, 4096)       → data

5 round trips!

NFSv4 compound:

RPC 1: COMPOUND {
    PUTROOTFH                        // Start at export root
    LOOKUP("home")                   // Navigate
    LOOKUP("alice")         
    LOOKUP("project")
    LOOKUP("README.md")
    READ(0, 4096)                    // Get data
}

1 round trip!

NFSv4 Compound Operation Example
XDR Definition
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
/* NFSv4 Compound Request Structure */
 
struct COMPOUND4args {
    utf8str_cs      tag;              /* Debugging tag */
    uint32_t        minorversion;     /* 0 for NFSv4.0 */
    nfs_argop4      argarray<>;       /* Array of operations */
};
 
/* Each operation in the compound */
union nfs_argop4 switch (nfs_opnum4 argop) {
    case OP_ACCESS:      ACCESS4args     opaccess;
    case OP_CLOSE:       CLOSE4args      opclose;
    case OP_COMMIT:      COMMIT4args     opcommit;
    case OP_CREATE:      CREATE4args     opcreate;
    case OP_DELEGRETURN: DELEGRETURN4args opdelegreturn;
    case OP_GETATTR:     GETATTR4args    opgetattr;
    case OP_GETFH:       void;           /* No arguments */
    case OP_LOOKUP:      LOOKUP4args     oplookup;
    case OP_OPEN:        OPEN4args       opopen;
    case OP_PUTFH:       PUTFH4args      opputfh;
    case OP_PUTROOTFH:   void;
    case OP_READ:        READ4args       opread;
    case OP_READDIR:     READDIR4args    opreaddir;
    case OP_WRITE:       WRITE4args      opwrite;
    /* ... many more operations */
};
 
/* 
 * Example: Open and read a file in one RPC
 * 
 * COMPOUND {
 *     PUTROOTFH,           // Start at export root
 *     LOOKUP("data"),      // Navigate to data/
 *     LOOKUP("file.txt"),  // Navigate to file.txt
 *     OPEN(READ),          // Open for reading (stateful!)
 *     GETFH,               // Get file handle
 *     READ(0, 32768),      // Read first 32KB
 *     CLOSE(stateid)       // Close the open
 * }
 */

Delegations: Safe Client-Side Caching

Delegations allow the server to grant caching rights to clients. When a client holds a delegation, it can cache aggressively without revalidation:

Read Delegation:

Server guarantees no other client will modify the file
Client can cache data and attributes without checking server
If another client wants to write, server recalls the delegation

Write Delegation:

Server guarantees no other client will read or write
Client can buffer writes locally without sending to server
Recall happens before any other access

This provides the performance benefits of aggressive caching while maintaining correctness—something NFSv3's weak consistency couldn't achieve.

NFSv4.0 vs NFSv3 Feature Comparison
Feature	NFSv3	NFSv4.0
Transport	UDP or TCP	TCP only
Port	2049 + dynamic (mountd, lockd)	2049 only
Mount Protocol	Separate (RFC 1094)	Integrated (PUTROOTFH)
Locking	Separate NLM protocol	Integrated (LOCK, LOCKT, LOCKU)
State	Stateless (mostly)	Stateful (leased)
Compound Ops	No	Yes
Delegations	No	Yes (read, write)
Authentication	AUTH_SYS (weak)	RPCSEC_GSS (Kerberos)
ACLs	No (posix permissions)	Yes (Windows-style)
Unicode	Partial	Full UTF-8 support
Replication	No	Basic referrals

NFSv4 Migration Considerations

NFSv4 export syntax differs from NFSv3. There's no /etc/exports 'mountable path' concept—NFSv4 uses a pseudofs (pseudo file system) for namespace. Migration requires understanding this new model. Additionally, ID mapping (user@domain) replaces numeric UID/GID transmission, requiring idmapd configuration.

NFSv4.1: pNFS and Sessions

NFSv4.1 (RFC 5661, 2010) introduced two major innovations: Sessions for exactly-once semantics, and pNFS for parallel data access across clustered storage.

Sessions: Solving the Exactly-Once Problem

NFSv4.0's idempotency approach wasn't perfect—some operations (like CREATE) couldn't be made truly idempotent. NFSv4.1 sessions provide exactly-once semantics through sequence numbers:

Session Model:

1. Client establishes session with server (CREATE_SESSION)
2. Session has 'slots' - each slot tracks one outstanding request
3. Each request carries (slotid, sequence_number)
4. Server tracks highest completed sequence per slot
5. Duplicate detection is now deterministic, not probabilistic

NFSv4.1 Session and Sequence
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
/* NFSv4.1 Session Structure */
 
struct nfs41_session {
    session4_id     sess_id;          /* Server-assigned session ID */
    uint32_t        fore_channel_attrs[]; /* Forward channel (client→server) */
    uint32_t        back_channel_attrs[]; /* Callback channel (server→client) */
    
    /* Slot table for exactly-once semantics */
    struct nfs41_slot *slots;         /* Array of slots */
    uint32_t        num_slots;        /* Number of slots */
};
 
struct nfs41_slot {
    uint32_t        slot_id;          /* Slot identifier */
    uint32_t        seq_num;          /* Current sequence number */
    uint32_t        highest_seq;      /* Highest completed sequence */
    bool            in_use;           /* Slot currently active? */
    
    /* Cached result for exactly-once replay */
    struct nfs_reply_cache *cached_reply;
};
 
/* Every NFSv4.1 COMPOUND starts with SEQUENCE */
struct SEQUENCE4args {
    sessionid4      sessionid;        /* Session ID */
    sequenceid4     sequenceid;       /* Sequence number for this slot */
    slotid4         slotid;           /* Which slot this request uses */
    slotid4         highest_slotid;   /* Hint for slot table sizing */
    bool            cachethis;        /* Should server cache reply? */
};
 
/*
 * Exactly-once execution:
 * 
 * Request 1: seq=5 on slot 0 → Server executes, remembers seq=5
 * Request 2: seq=6 on slot 0 → Server executes, remembers seq=6
 * Network loss, client retries:
 * Request 2 again: seq=6 on slot 0 → Server sees seq=6 already done,
 *                                     returns cached result
 */

pNFS: Parallel Network File System

pNFS enables clients to perform data I/O directly to storage devices, bypassing the NFS server for data paths while retaining metadata centralization:

Traditional NFS:

  Client ←───────────────→ NFS Server ←→ Storage
        All data flows through server
        Server is bandwidth bottleneck


pNFS Architecture:

                    ┌─→ Storage Device 1
  Client ─┬─ Data ─→├─→ Storage Device 2
          │         └─→ Storage Device 3
          │
          └─ Metadata ─→ Metadata Server (MDS)
          
  Data flows directly to storage!
  Metadata server not in data path

Converting Mermaid diagram...

pNFS Layout Types

The 'layout' describes how data is distributed across storage. NFSv4.1 defines three layout types:

1. File Layout (RFC 5661)

Data striped across multiple NFS data servers
Simple, NFS-native approach

2. Block Layout (RFC 5663)

Client accesses block storage directly (iSCSI, FC)
Requires block protocol stack on client
Highest performance potential

3. Object Layout (RFC 5664)

Data stored as objects (like in object storage)
Used with OSD (Object-based Storage Device) protocols

pNFS Use Cases

pNFS shines in HPC, big data, and media environments where aggregate bandwidth exceeds what a single server can provide. For typical file serving, traditional NFS is simpler. pNFS requires compatible storage infrastructure and careful configuration.

NFSv4.2: Modern File System Features

NFSv4.2 (RFC 7862, 2016) brings NFS into the modern era with features addressing cloud, virtualization, and security requirements.

Key NFSv4.2 Features:

NFSv4.2 Innovations

•Server-Side Copy (COPY) — Copy files within or between servers without data traversing the client network. Huge for VM cloning and backups.
•Space Reservation (ALLOCATE, DEALLOCATE) — Pre-allocate or punch holes in files, essential for databases and virtual disk images.
•Sparse Files (READ_PLUS, SEEK) — Efficiently handle files with holes. READ_PLUS can return 'hole' info instead of zeros.
•Application I/O Hints (IO_ADVISE) — Client tells server its access patterns for optimization.
•Labeled NFS (RPCSEC_GSS version 3) — Mandatory Access Control (MAC) labels for SELinux/AppArmor enforcement across NFS.
•Clone (CLONE) — Create copy-on-write clones for efficient snapshots.

Server-Side Copy: Revolutionary for Virtualization

Consider cloning a VM with a 100GB disk image:

Traditional approach:

Client reads 100GB from source NFS server
Client writes 100GB to destination NFS server
Transfers: 100GB download + 100GB upload = 200GB client bandwidth
Time: Minutes to hours

NFSv4.2 server-side copy:

Client sends COPY command
Server(s) copy data internally
Transfers: Two small NFS commands
Time: Seconds (limited by server disk speed, not network)

For cloud providers and virtualization platforms, this is transformative.

Server-Side Copy (RFC 7862)
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
/* NFSv4.2 Server-Side Copy Operations */
 
/* 
 * Intra-server copy (same server):
 * COPY(src_stateid, dst_stateid, src_offset, dst_offset, count)
 * Server copies internally, client only sends/receives status
 */
 
/* For inter-server copy, use COPY_NOTIFY + COPY */
 
/* Step 1: Client gets copy permission from source server */
struct COPY_NOTIFY4args {
    stateid4        src_stateid;    /* Open stateid for source */
    netloc4         dst_server;     /* Destination server identity */
};
 
struct COPY_NOTIFY4resok {
    nfstime4        lease_time;     /* How long permission is valid */
    netloc4         source_server<>;/* Addresses dest can contact for data */
};
 
/* Step 2: Client sends COPY to destination server */
struct COPY4args {
    stateid4        src_stateid;    /* Source file stateid */
    stateid4        dst_stateid;    /* Destination file stateid */
    offset4         src_offset;     /* Where to start reading */
    offset4         dst_offset;     /* Where to start writing */
    length4         count;          /* How many bytes to copy */
    bool            consecutive;    /* Must complete in order? */
    bool            synchronous;    /* Wait for completion? */
    netloc4         src_server<>;   /* Source server (from COPY_NOTIFY) */
};
 
/*
 * Workflow:
 * 1. Client: OPEN source file on server A, OPEN dest file on server B
 * 2. Client → Server A: COPY_NOTIFY (dest is server B)
 * 3. Client → Server B: COPY (source is server A)
 * 4. Server B → Server A: Direct data transfer
 * 5. Server B → Client: COPY result (bytes copied, completion status)
 */
 
/* Sparse file support */
struct READ_PLUS4resok {
    bool            eof;
    contents        contents<>;     /* May be data, hole, or both */
};
 
enum data_content4 {
    NFS4_CONTENT_DATA = 0,          /* Actual data bytes */
    NFS4_CONTENT_HOLE = 1           /* Sparse hole (implied zeros) */
};
 
/* 
 * READ_PLUS can return:
 * "Offset 0-1MB: data"
 * "Offset 1MB-10GB: hole"  
 * "Offset 10GB-10.1GB: data"
 * 
 * Client displays/processes hole info without transferring 9GB of zeros!
 */

Labeled NFS: MAC Security Across the Network

Labeled NFS enables SELinux and similar MAC (Mandatory Access Control) systems to work across NFS:

Without Labeled NFS:
- File has SELinux label on server: httpd_sys_content_t
- When accessed via NFS, label is lost
- Client can't enforce SELinux policy for NFS files
- Security model is weakened

With Labeled NFS:
- Server includes security label in GETATTR responses
- Client enforces local MAC policy using server's labels
- SELinux policies work consistently across local and NFS files

This is critical for security-sensitive environments like government and financial systems.

NFSv4.2 Adoption

NFSv4.2 is the current recommended version for new deployments on Linux. It's the default in RHEL 8+/CentOS 8+ and recent Ubuntu/Debian. Server-side copy in particular is worth enabling for virtual machine and container workloads.

Version Selection Guidelines

Choosing the right NFS version requires balancing features, compatibility, and operational complexity. Here's a decision framework:

When to Use Each NFS Version
Scenario	Recommended	Rationale
Modern Linux-only environment	NFSv4.2	Best features, performance, security
Mixed Linux/Windows environment	NFSv3 or NFSv4.0	Wide compatibility; NFSv4 ACLs help Windows
Legacy or embedded systems	NFSv3	Maximum compatibility
WAN or firewall-restricted	NFSv4.x	Single port, designed for WAN
High-security requirements	NFSv4.x + Kerberos	Strong authentication and encryption
Very high bandwidth needs	NFSv4.1 pNFS	Parallel data access
VM cloning/backup workloads	NFSv4.2	Server-side copy eliminates data transfer
SELinux/MAC enforcement	NFSv4.2	Labeled NFS support

Migration Considerations

Moving from NFSv3 to NFSv4:

Configuration Changes:

NFSv4 exports don't use /etc/exports the same way
The pseudofs (fsid=0) creates a virtual root
ID mapping replaces numeric UID/GID

# NFSv3 export
/export/home  192.168.1.0/24(rw,sync)

# NFSv4 export (add fsid=0 for root)
/export       *(ro,fsid=0)             # Pseudofs root
/export/home  192.168.1.0/24(rw,sync)  # Actual data

ID Mapping:

# /etc/idmapd.conf
[General]
Domain = example.com

# Users 'alice@example.com' mapped to local UID

Testing Strategy:

Set up NFSv4 server alongside existing NFSv3
Test with non-production clients
Verify ID mapping, ACLs, lock behavior
Migrate clients incrementally
Monitor for issues before decommissioning NFSv3

Version Verification Commands
Bash
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
# Check which NFS versions server supports
rpcinfo -p server.example.com | grep nfs
 
# Sample output:
#    100003    3   tcp   2049  nfs
#    100003    4   tcp   2049  nfs
 
# Check mounted NFS version
nfsstat -m
# Output shows: vers=4.2, proto=tcp, etc.
 
# Or via mount options in /proc
grep nfs /proc/mounts
 
# View NFS server version configuration (Linux)
cat /proc/fs/nfsd/versions
# Output: +2 +3 +4 +4.1 +4.2  (+ means enabled)
 
# Disable older versions on server
echo "-2 -3 +4 +4.1 +4.2" > /proc/fs/nfsd/versions
# Or in /etc/nfs.conf:
# [nfsd]
# vers2=n
# vers3=n
# vers4=y
# vers4.1=y
# vers4.2=y
 
# Force client to use specific version
mount -t nfs -o vers=4.2 server:/export /mnt
 
# Test connectivity at specific version
mount -t nfs -o vers=3,proto=tcp server:/export /mnt/test && umount /mnt/test && echo "NFSv3 TCP: OK"
mount -t nfs -o vers=4.2 server:/export /mnt/test && umount /mnt/test && echo "NFSv4.2: OK"

Version Negotiation Gotcha

If you don't specify a version, clients negotiate automatically. This can lead to different mounts using different versions. For consistency, explicitly specify vers= in mount options or /etc/fstab entries.

Summary: NFS Version Mastery

We've journeyed through four decades of NFS evolution. Each version addressed real-world limitations while building on the fundamental principles established in NFSv2. Let's consolidate the key points:

Key Takeaways

•NFSv2 established foundations — Stateless, file handles, RPC. Limited by 2GB files and synchronous writes.
•NFSv3 is the industry workhorse — 64-bit files, async writes, WCC. Simple, performant, widely compatible. Still excellent for many workloads.
•NFSv4.0 was a complete redesign — Stateful ops, compound RPCs, integrated locking, single port (2049). Better security with RPCSEC_GSS. Requires configuration changes from v3.
•NFSv4.1 enables scale-out — Sessions for exactly-once semantics. pNFS for parallel data access across clustered storage. Directory delegations.
•NFSv4.2 is today's standard — Server-side copy eliminates data transfer. Space reservation, sparse files, labeled NFS for security. Recommended for new deployments.
•Version selection is workload-dependent — Modern Linux: NFSv4.2. Mixed environments: NFSv3 or NFSv4.0. High-security: NFSv4.x with Kerberos. High-bandwidth: pNFS.

What's Next

With NFS version capabilities understood, we'll explore Performance Considerations—how to optimize NFS for your workload. We'll cover tuning parameters, caching strategies, network considerations, and common performance pitfalls. This practical knowledge helps you get the most from your NFS infrastructure.

Page Complete

You now understand the evolution, features, and trade-offs of all NFS versions. You can recommend appropriate versions for different scenarios, plan migrations, and understand version-specific behavior when troubleshooting. This knowledge is essential for NFS architecture and deployment decisions.

NFS Versions

Four Decades of Evolution

Choose the right version for new deployments
Understand behavior differences when troubleshooting
Plan migration strategies for version upgrades
Configure interoperability between different systems

What You Will Learn

NFS Version History Overview

NFS Version Timeline and Key Characteristics
Version	Year	RFC/Spec	Key Innovation
NFSv2	1984	RFC 1094 (1989)	Original stateless protocol, 32-bit file sizes
NFSv3	1995	RFC 1813	64-bit files, async writes, WCC, TCP support
NFSv4.0	2003	RFC 3530 → 7530	Stateful ops, compound RPCs, ACLs, integrated locking
NFSv4.1 (pNFS)	2010	RFC 5661	Sessions, parallel/cluster NFS, directory delegations
NFSv4.2	2016	RFC 7862	Server-side copy, space reservation, labeled NFS, sparse files

Backward Compatibility Strategy

NFS maintains strong backward compatibility through graceful negotiation:

Client requests highest version it supports
Server responds with highest version it supports (≤ client's request)
Both sides operate at the negotiated version

This allows gradual infrastructure upgrades—a new server can serve both legacy and modern clients simultaneously.

# Force specific version on mount
mount -t nfs -o vers=3 server:/export /mnt    # Force NFSv3
mount -t nfs -o vers=4 server:/export /mnt    # Force NFSv4.0
mount -t nfs -o vers=4.2 server:/export /mnt  # Force NFSv4.2

# Check negotiated version
nfsstat -m  # Shows mount options including version

Converting Mermaid diagram...

NFSv2: The Original Protocol

NFSv2, released with SunOS 2.0 in 1984, established the fundamental NFS model that persists today. Understanding NFSv2's limitations explains why its successors evolved as they did.

Core Characteristics of NFSv2:

Transport: UDP only (TCP added by some vendors later)
File Size: 32-bit offsets (maximum 2GB files)
Write Semantics: Synchronous only
File Handles: Fixed 32 bytes
Maximum Read/Write: 8KB per operation

NFSv2 Procedure Definitions
Proc	Name	Description
0	NULL	Null procedure for testing
1	GETATTR	Get file attributes
2	SETATTR	Set file attributes
3	ROOT	Get file system root (obsolete)
4	LOOKUP	Look up file name
5	READLINK	Read symbolic link
6	READ	Read from file
7	WRITECACHE	Write to cache (obsolete)
8	WRITE	Write to file
9	CREATE	Create file
10	REMOVE	Remove file
11	RENAME	Rename file
12	LINK	Create hard link
13	SYMLINK	Create symbolic link
14	MKDIR	Create directory
15	RMDIR	Remove directory
16	READDIR	Read directory entries
17	STATFS	Get file system statistics

NFSv2 Limitations That Drove NFSv3

NFSv2 Pain Points

•2GB File Limit — 32-bit offsets meant files larger than 2GB were impossible. As disk sizes grew, this became a critical limitation for databases and multimedia.
•Synchronous Writes — Every WRITE had to complete on server disk before returning. WRITE, fsync, return. Killed performance for write-heavy workloads.
•UDP Only (Practical) — While some vendors added TCP, the protocol was designed for UDP. Lost packets caused visible delays; WAN deployment was painful.
•8KB Max Transfer — Read/write operations were limited to 8KB. Large file transfers required many round trips.
•No Access Check — Clients couldn't check access before attempting operations, leading to failed operations and confusing error messages.
•Limited Error Information — Error codes were sparse; diagnosing failures was often guesswork.

NFSv2 Today

NFSv3: The Industry Workhorse

NFSv3 (RFC 1813, 1995) addressed NFSv2's most painful limitations while maintaining the stateless model. It became the dominant NFS version for over a decade and remains widely deployed today.

Key NFSv3 Improvements:

NFSv3 Enhancements

•64-bit File Sizes — Supports files up to 2^63 bytes (8 exabytes), eliminating the 2GB barrier
•Asynchronous Writes — Server can acknowledge writes before disk commit, dramatically improving performance
•Weak Cache Consistency (WCC) — Pre/post operation attributes help clients maintain cache coherence
•TCP Support — Official TCP transport for reliable WAN deployment
•Larger Transfers — Up to 1MB read/write per operation (implementation dependent)
•ACCESS Procedure — Check permissions before attempting operations
•READDIRPLUS — Get attributes with directory entries, reducing round trips
•Variable File Handles — Up to 64 bytes (better for complex file systems)

Asynchronous Writes: The Game Changer

NFSv3's asynchronous write capability was transformative for performance. The WRITE procedure includes a stable parameter:

WRITE Stability Modes:

UNSTABLE (0):  "Write to server memory, don't wait for disk"
               Fast, but data at risk if server crashes
               
DATA_SYNC (1): "Write data to disk, metadata can be cached"
               Moderate speed, data safe, metadata at risk
               
FILE_SYNC (2): "Write everything to disk before returning"
               Slow, full durability (like NFSv2)

The COMMIT procedure complements UNSTABLE writes:

Client sends multiple UNSTABLE writes (fast)
Client sends COMMIT covering all written ranges
Server flushes to disk and returns
Client knows data is durable

NFSv3 Write Patterns

Protocol Example

=== Synchronous Write Pattern (Safe but Slow) ===
 
Client                              Server
  |                                    |
  |-- WRITE(stable=FILE_SYNC, 0-8K) ->|  Write + fsync
  |<- OK, committed=FILE_SYNC --------|  8K durable on disk
  |                                    |
  |-- WRITE(stable=FILE_SYNC, 8K-16K)->|  Write + fsync
  |<- OK, committed=FILE_SYNC --------|  16K durable on disk
  |                                    |
  Total: 2 disk syncs, ~20ms latency each = ~40ms minimum
 
 
=== Asynchronous Write Pattern (Fast) ===
 
Client                              Server
  |                                    |
  |-- WRITE(stable=UNSTABLE, 0-8K) -->|  Write to memory
  |<- OK, committed=UNSTABLE ---------|  
  |                                    |
  |-- WRITE(stable=UNSTABLE, 8K-16K)->|  Write to memory
  |<- OK, committed=UNSTABLE ---------|  
  |                                    |
  |-- COMMIT(0, 16K) ---------------->|  Flush all to disk
  |<- OK, verf=XYZ -------------------|  Now durable
  |                                    |
  Total: 1 disk sync, much lower latency!
 
 
=== Server Crash During Async Writes ===
 
Client                              Server
  |                                    |
  |-- WRITE(UNSTABLE, 0-8K) --------->|  In memory
  |<- OK ------------------------------|
  |-- WRITE(UNSTABLE, 8K-16K) -------->|  In memory  
  |<- OK ------------------------------|
  |                                    X  CRASH! (data lost)
  |-- COMMIT(0, 16K) ----------------->|  Server reboots
  |<- ERROR or different verf ---------|
  |                                    |
  |  Client detects verf changed,     |
  |  must re-send all writes!         |
  |                                    |

Weak Cache Consistency (WCC)

WCC provides pre-operation and post-operation attributes with modifying operations. This lets clients detect concurrent modifications:

/* WCC example: WRITE response */
struct WRITE3resok {
    wcc_data     file_wcc;        /* Before/after attributes */
    count3       count;           /* Bytes written */  
    stable_how   committed;       /* How stable is the write? */
    writeverf3   verf;            /* Server write verifier */
};

struct wcc_data {
    pre_op_attr  before;          /* size, mtime, ctime before */
    post_op_attr after;           /* Full attrs after */
};

The client compares before with its cached attributes:

Match: cache was valid, update with after attributes
Mismatch: someone else changed the file, invalidate cache

NFSv3 Is Still Great for Many Workloads

NFSv4.0: The Complete Redesign

Philosophical Shifts in NFSv4:

NFSv4 Design Philosophy

•Single Protocol — No more separate mount, lock, and NFS protocols. Everything (including locking) is part of NFS itself.
•Single Port — All operations through TCP port 2049. Firewall-friendly, NAT-friendly.
•Stateful Operations — Delegations, open state, and integrated locking provide correctness guarantees that statelessness couldn't.
•Compound Operations — Multiple operations in a single RPC reduce round trips dramatically.
•Strong Security — First-class support for Kerberos (RPCSEC_GSS) and NFSv4 ACLs.
•Internet-Ready — Designed for WAN deployment, not just LANs.

Compound Operations: Reducing Round Trips

NFSv4 allows multiple operations in a single RPC call. Consider accessing /export/home/alice/project/README.md:

NFSv3 requires:

RPC 1: LOOKUP(export_fh, "home")     → home_fh
RPC 2: LOOKUP(home_fh, "alice")     → alice_fh
RPC 3: LOOKUP(alice_fh, "project")  → project_fh
RPC 4: LOOKUP(project_fh, "README.md") → file_fh
RPC 5: READ(file_fh, 0, 4096)       → data

5 round trips!

NFSv4 compound:

RPC 1: COMPOUND {
    PUTROOTFH                        // Start at export root
    LOOKUP("home")                   // Navigate
    LOOKUP("alice")         
    LOOKUP("project")
    LOOKUP("README.md")
    READ(0, 4096)                    // Get data
}

1 round trip!

NFSv4 Compound Operation Example
XDR Definition
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
/* NFSv4 Compound Request Structure */
 
struct COMPOUND4args {
    utf8str_cs      tag;              /* Debugging tag */
    uint32_t        minorversion;     /* 0 for NFSv4.0 */
    nfs_argop4      argarray<>;       /* Array of operations */
};
 
/* Each operation in the compound */
union nfs_argop4 switch (nfs_opnum4 argop) {
    case OP_ACCESS:      ACCESS4args     opaccess;
    case OP_CLOSE:       CLOSE4args      opclose;
    case OP_COMMIT:      COMMIT4args     opcommit;
    case OP_CREATE:      CREATE4args     opcreate;
    case OP_DELEGRETURN: DELEGRETURN4args opdelegreturn;
    case OP_GETATTR:     GETATTR4args    opgetattr;
    case OP_GETFH:       void;           /* No arguments */
    case OP_LOOKUP:      LOOKUP4args     oplookup;
    case OP_OPEN:        OPEN4args       opopen;
    case OP_PUTFH:       PUTFH4args      opputfh;
    case OP_PUTROOTFH:   void;
    case OP_READ:        READ4args       opread;
    case OP_READDIR:     READDIR4args    opreaddir;
    case OP_WRITE:       WRITE4args      opwrite;
    /* ... many more operations */
};
 
/* 
 * Example: Open and read a file in one RPC
 * 
 * COMPOUND {
 *     PUTROOTFH,           // Start at export root
 *     LOOKUP("data"),      // Navigate to data/
 *     LOOKUP("file.txt"),  // Navigate to file.txt
 *     OPEN(READ),          // Open for reading (stateful!)
 *     GETFH,               // Get file handle
 *     READ(0, 32768),      // Read first 32KB
 *     CLOSE(stateid)       // Close the open
 * }
 */

Delegations: Safe Client-Side Caching

Delegations allow the server to grant caching rights to clients. When a client holds a delegation, it can cache aggressively without revalidation:

Read Delegation:

Server guarantees no other client will modify the file
Client can cache data and attributes without checking server
If another client wants to write, server recalls the delegation

Write Delegation:

Server guarantees no other client will read or write
Client can buffer writes locally without sending to server
Recall happens before any other access

This provides the performance benefits of aggressive caching while maintaining correctness—something NFSv3's weak consistency couldn't achieve.

NFSv4.0 vs NFSv3 Feature Comparison
Feature	NFSv3	NFSv4.0
Transport	UDP or TCP	TCP only
Port	2049 + dynamic (mountd, lockd)	2049 only
Mount Protocol	Separate (RFC 1094)	Integrated (PUTROOTFH)
Locking	Separate NLM protocol	Integrated (LOCK, LOCKT, LOCKU)
State	Stateless (mostly)	Stateful (leased)
Compound Ops	No	Yes
Delegations	No	Yes (read, write)
Authentication	AUTH_SYS (weak)	RPCSEC_GSS (Kerberos)
ACLs	No (posix permissions)	Yes (Windows-style)
Unicode	Partial	Full UTF-8 support
Replication	No	Basic referrals

NFSv4 Migration Considerations

NFSv4.1: pNFS and Sessions

NFSv4.1 (RFC 5661, 2010) introduced two major innovations: Sessions for exactly-once semantics, and pNFS for parallel data access across clustered storage.

Sessions: Solving the Exactly-Once Problem

NFSv4.0's idempotency approach wasn't perfect—some operations (like CREATE) couldn't be made truly idempotent. NFSv4.1 sessions provide exactly-once semantics through sequence numbers:

Session Model:

1. Client establishes session with server (CREATE_SESSION)
2. Session has 'slots' - each slot tracks one outstanding request
3. Each request carries (slotid, sequence_number)
4. Server tracks highest completed sequence per slot
5. Duplicate detection is now deterministic, not probabilistic

NFSv4.1 Session and Sequence
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
/* NFSv4.1 Session Structure */
 
struct nfs41_session {
    session4_id     sess_id;          /* Server-assigned session ID */
    uint32_t        fore_channel_attrs[]; /* Forward channel (client→server) */
    uint32_t        back_channel_attrs[]; /* Callback channel (server→client) */
    
    /* Slot table for exactly-once semantics */
    struct nfs41_slot *slots;         /* Array of slots */
    uint32_t        num_slots;        /* Number of slots */
};
 
struct nfs41_slot {
    uint32_t        slot_id;          /* Slot identifier */
    uint32_t        seq_num;          /* Current sequence number */
    uint32_t        highest_seq;      /* Highest completed sequence */
    bool            in_use;           /* Slot currently active? */
    
    /* Cached result for exactly-once replay */
    struct nfs_reply_cache *cached_reply;
};
 
/* Every NFSv4.1 COMPOUND starts with SEQUENCE */
struct SEQUENCE4args {
    sessionid4      sessionid;        /* Session ID */
    sequenceid4     sequenceid;       /* Sequence number for this slot */
    slotid4         slotid;           /* Which slot this request uses */
    slotid4         highest_slotid;   /* Hint for slot table sizing */
    bool            cachethis;        /* Should server cache reply? */
};
 
/*
 * Exactly-once execution:
 * 
 * Request 1: seq=5 on slot 0 → Server executes, remembers seq=5
 * Request 2: seq=6 on slot 0 → Server executes, remembers seq=6
 * Network loss, client retries:
 * Request 2 again: seq=6 on slot 0 → Server sees seq=6 already done,
 *                                     returns cached result
 */

pNFS: Parallel Network File System

pNFS enables clients to perform data I/O directly to storage devices, bypassing the NFS server for data paths while retaining metadata centralization:

Traditional NFS:

  Client ←───────────────→ NFS Server ←→ Storage
        All data flows through server
        Server is bandwidth bottleneck


pNFS Architecture:

                    ┌─→ Storage Device 1
  Client ─┬─ Data ─→├─→ Storage Device 2
          │         └─→ Storage Device 3
          │
          └─ Metadata ─→ Metadata Server (MDS)
          
  Data flows directly to storage!
  Metadata server not in data path

Converting Mermaid diagram...

pNFS Layout Types

The 'layout' describes how data is distributed across storage. NFSv4.1 defines three layout types:

1. File Layout (RFC 5661)

Data striped across multiple NFS data servers
Simple, NFS-native approach

2. Block Layout (RFC 5663)

Client accesses block storage directly (iSCSI, FC)
Requires block protocol stack on client
Highest performance potential

3. Object Layout (RFC 5664)

Data stored as objects (like in object storage)
Used with OSD (Object-based Storage Device) protocols

pNFS Use Cases

NFSv4.2: Modern File System Features

NFSv4.2 (RFC 7862, 2016) brings NFS into the modern era with features addressing cloud, virtualization, and security requirements.

Key NFSv4.2 Features:

NFSv4.2 Innovations

•Server-Side Copy (COPY) — Copy files within or between servers without data traversing the client network. Huge for VM cloning and backups.
•Space Reservation (ALLOCATE, DEALLOCATE) — Pre-allocate or punch holes in files, essential for databases and virtual disk images.
•Sparse Files (READ_PLUS, SEEK) — Efficiently handle files with holes. READ_PLUS can return 'hole' info instead of zeros.
•Application I/O Hints (IO_ADVISE) — Client tells server its access patterns for optimization.
•Labeled NFS (RPCSEC_GSS version 3) — Mandatory Access Control (MAC) labels for SELinux/AppArmor enforcement across NFS.
•Clone (CLONE) — Create copy-on-write clones for efficient snapshots.

Server-Side Copy: Revolutionary for Virtualization

Consider cloning a VM with a 100GB disk image:

Traditional approach:

Client reads 100GB from source NFS server
Client writes 100GB to destination NFS server
Transfers: 100GB download + 100GB upload = 200GB client bandwidth
Time: Minutes to hours

NFSv4.2 server-side copy:

Client sends COPY command
Server(s) copy data internally
Transfers: Two small NFS commands
Time: Seconds (limited by server disk speed, not network)

For cloud providers and virtualization platforms, this is transformative.

Server-Side Copy (RFC 7862)
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
/* NFSv4.2 Server-Side Copy Operations */
 
/* 
 * Intra-server copy (same server):
 * COPY(src_stateid, dst_stateid, src_offset, dst_offset, count)
 * Server copies internally, client only sends/receives status
 */
 
/* For inter-server copy, use COPY_NOTIFY + COPY */
 
/* Step 1: Client gets copy permission from source server */
struct COPY_NOTIFY4args {
    stateid4        src_stateid;    /* Open stateid for source */
    netloc4         dst_server;     /* Destination server identity */
};
 
struct COPY_NOTIFY4resok {
    nfstime4        lease_time;     /* How long permission is valid */
    netloc4         source_server<>;/* Addresses dest can contact for data */
};
 
/* Step 2: Client sends COPY to destination server */
struct COPY4args {
    stateid4        src_stateid;    /* Source file stateid */
    stateid4        dst_stateid;    /* Destination file stateid */
    offset4         src_offset;     /* Where to start reading */
    offset4         dst_offset;     /* Where to start writing */
    length4         count;          /* How many bytes to copy */
    bool            consecutive;    /* Must complete in order? */
    bool            synchronous;    /* Wait for completion? */
    netloc4         src_server<>;   /* Source server (from COPY_NOTIFY) */
};
 
/*
 * Workflow:
 * 1. Client: OPEN source file on server A, OPEN dest file on server B
 * 2. Client → Server A: COPY_NOTIFY (dest is server B)
 * 3. Client → Server B: COPY (source is server A)
 * 4. Server B → Server A: Direct data transfer
 * 5. Server B → Client: COPY result (bytes copied, completion status)
 */
 
/* Sparse file support */
struct READ_PLUS4resok {
    bool            eof;
    contents        contents<>;     /* May be data, hole, or both */
};
 
enum data_content4 {
    NFS4_CONTENT_DATA = 0,          /* Actual data bytes */
    NFS4_CONTENT_HOLE = 1           /* Sparse hole (implied zeros) */
};
 
/* 
 * READ_PLUS can return:
 * "Offset 0-1MB: data"
 * "Offset 1MB-10GB: hole"  
 * "Offset 10GB-10.1GB: data"
 * 
 * Client displays/processes hole info without transferring 9GB of zeros!
 */

Labeled NFS: MAC Security Across the Network

Labeled NFS enables SELinux and similar MAC (Mandatory Access Control) systems to work across NFS:

Without Labeled NFS:
- File has SELinux label on server: httpd_sys_content_t
- When accessed via NFS, label is lost
- Client can't enforce SELinux policy for NFS files
- Security model is weakened

With Labeled NFS:
- Server includes security label in GETATTR responses
- Client enforces local MAC policy using server's labels
- SELinux policies work consistently across local and NFS files

This is critical for security-sensitive environments like government and financial systems.

NFSv4.2 Adoption

Version Selection Guidelines

Choosing the right NFS version requires balancing features, compatibility, and operational complexity. Here's a decision framework:

When to Use Each NFS Version
Scenario	Recommended	Rationale
Modern Linux-only environment	NFSv4.2	Best features, performance, security
Mixed Linux/Windows environment	NFSv3 or NFSv4.0	Wide compatibility; NFSv4 ACLs help Windows
Legacy or embedded systems	NFSv3	Maximum compatibility
WAN or firewall-restricted	NFSv4.x	Single port, designed for WAN
High-security requirements	NFSv4.x + Kerberos	Strong authentication and encryption
Very high bandwidth needs	NFSv4.1 pNFS	Parallel data access
VM cloning/backup workloads	NFSv4.2	Server-side copy eliminates data transfer
SELinux/MAC enforcement	NFSv4.2	Labeled NFS support

Migration Considerations

Moving from NFSv3 to NFSv4:

Configuration Changes:

NFSv4 exports don't use /etc/exports the same way
The pseudofs (fsid=0) creates a virtual root
ID mapping replaces numeric UID/GID

# NFSv3 export
/export/home  192.168.1.0/24(rw,sync)

# NFSv4 export (add fsid=0 for root)
/export       *(ro,fsid=0)             # Pseudofs root
/export/home  192.168.1.0/24(rw,sync)  # Actual data

ID Mapping:

# /etc/idmapd.conf
[General]
Domain = example.com

# Users 'alice@example.com' mapped to local UID

Testing Strategy:

Set up NFSv4 server alongside existing NFSv3
Test with non-production clients
Verify ID mapping, ACLs, lock behavior
Migrate clients incrementally
Monitor for issues before decommissioning NFSv3

Version Verification Commands
Bash
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
# Check which NFS versions server supports
rpcinfo -p server.example.com | grep nfs
 
# Sample output:
#    100003    3   tcp   2049  nfs
#    100003    4   tcp   2049  nfs
 
# Check mounted NFS version
nfsstat -m
# Output shows: vers=4.2, proto=tcp, etc.
 
# Or via mount options in /proc
grep nfs /proc/mounts
 
# View NFS server version configuration (Linux)
cat /proc/fs/nfsd/versions
# Output: +2 +3 +4 +4.1 +4.2  (+ means enabled)
 
# Disable older versions on server
echo "-2 -3 +4 +4.1 +4.2" > /proc/fs/nfsd/versions
# Or in /etc/nfs.conf:
# [nfsd]
# vers2=n
# vers3=n
# vers4=y
# vers4.1=y
# vers4.2=y
 
# Force client to use specific version
mount -t nfs -o vers=4.2 server:/export /mnt
 
# Test connectivity at specific version
mount -t nfs -o vers=3,proto=tcp server:/export /mnt/test && umount /mnt/test && echo "NFSv3 TCP: OK"
mount -t nfs -o vers=4.2 server:/export /mnt/test && umount /mnt/test && echo "NFSv4.2: OK"

Version Negotiation Gotcha

Summary: NFS Version Mastery

Key Takeaways

•NFSv2 established foundations — Stateless, file handles, RPC. Limited by 2GB files and synchronous writes.
•NFSv3 is the industry workhorse — 64-bit files, async writes, WCC. Simple, performant, widely compatible. Still excellent for many workloads.
•NFSv4.0 was a complete redesign — Stateful ops, compound RPCs, integrated locking, single port (2049). Better security with RPCSEC_GSS. Requires configuration changes from v3.
•NFSv4.1 enables scale-out — Sessions for exactly-once semantics. pNFS for parallel data access across clustered storage. Directory delegations.
•NFSv4.2 is today's standard — Server-side copy eliminates data transfer. Space reservation, sparse files, labeled NFS for security. Recommended for new deployments.
•Version selection is workload-dependent — Modern Linux: NFSv4.2. Mixed environments: NFSv3 or NFSv4.0. High-security: NFSv4.x with Kerberos. High-bandwidth: pNFS.

What's Next

Page Complete