NFS vs SMB: Performance, Security & When to Use Each

Choosing between NFS and SMB isn’t just a Linux-vs-Windows decision anymore. Modern networks are mixed-protocol environments where both coexist. This guide covers protocol internals, real-world performance, security trade-offs, and what happens when you need to migrate data between them.

Protocol Overview

NFS (Network File System)

NFS was developed by Sun Microsystems in 1984. Now at version 4.2, it’s the standard for Linux and Unix file sharing.

Version	Year	Key Features
NFSv3	1995	Stateless, UDP/TCP, AUTH_SYS
NFSv4	2003	Stateful, TCP only, Kerberos, ACLs
NFSv4.1	2010	pNFS (parallel NFS), sessions, trunking
NFSv4.2	2016	Server-side copy, sparse files, space reservation

SMB (Server Message Block)

SMB was created by IBM in 1983, then significantly developed by Microsoft. The CIFS (Common Internet File System) name refers to SMB 1.0 — modern versions are simply “SMB.”

Version	Year	Key Features
SMB 1.0 / CIFS	1996	Microsoft formalized IBM’s 1983 SMB; legacy, insecure — disable this
SMB 2.0	2006	Reduced chattiness, larger reads/writes
SMB 2.1	2010	Leasing, large MTU support
SMB 3.0	2012	Multichannel, encryption, RDMA
SMB 3.1.1	2015	Pre-auth integrity, AES-128-GCM

Performance Comparison

Sequential Large File Transfers

For large file transfers (100MB+ files) on a 10Gbps network, both protocols deliver similar throughput when properly tuned:

Configuration	NFSv4.2	SMB 3.0
Default settings	~700 MB/s	~500 MB/s
Tuned (see below)	~1,000 MB/s	~900 MB/s
Multichannel (2x 10G)	~1,000 MB/s*	~1,800 MB/s

*NFSv4.1+ supports trunking, but adoption is limited compared to SMB multichannel.

Small File Operations (Metadata-Heavy)

This is where the protocols diverge significantly. NFS operations like stat(), readdir(), and open() map almost 1:1 to the wire protocol. SMB requires more round-trips for the same operations.

Operation	NFSv4	SMB 3.0
Create 10,000 empty files	~2 seconds	~5 seconds
Stat 100,000 files	~4 seconds	~8 seconds
readdir of 50,000 entries	~1 second	~3 seconds
Random 4K reads (IOPS)	~50,000	~35,000

Why NFS Is Often Faster

1. Fewer round-trips — NFS compound operations (v4) batch multiple requests
2. Simpler metadata — no Windows security descriptors on every operation
3. Aggressive caching — delegations in NFSv4 allow extended client caching
4. Lower protocol overhead — NFS headers are smaller than SMB headers

Why SMB Can Win

1. Multichannel — SMB 3.0 bonds multiple NICs natively (killer feature for throughput)
2. Leasing/oplocks — sophisticated client caching for read-heavy workloads
3. RDMA — SMB Direct bypasses CPU for storage networking (Azure-class)
4. Better on Windows clients — kernel-integrated, not a userspace mount

Performance Tuning

NFS Tuning

# Mount options for performance
mount -t nfs4 server:/export /mnt -o \
  rsize=1048576,wsize=1048576,\    # Max read/write size (1MB)
  nconnect=8,\                      # Multiple TCP connections (Linux 5.3+)
  hard,\                             # Hard mount (retry indefinitely)
  noatime                           # Skip access time updates

# Server-side: increase NFS threads
echo 64 > /proc/fs/nfsd/threads     # Default is often 8

Key NFS tuning levers:

• nconnect — use 4-16 TCP connections per mount (biggest single improvement)
• rsize/wsize — set to 1MB for large file workloads
• NFS threads — 8 threads is the default; 32-64 is better for busy servers

For complete NFS server setup, see our NFS Exports Configuration Guide.

SMB Tuning

# Enable SMB Multichannel (usually on by default)
Set-SmbServerConfiguration -EnableMultiChannel $true

# Configure large MTU
Set-SmbServerConfiguration -MaxChannelPerSession 32

# Linux cifs mount options
mount -t cifs //server/share /mnt -o \
  vers=3.0,\
  multichannel,max_channels=8,\
  rsize=4194304,wsize=4194304,\
  cache=strict

Key SMB tuning levers:

• Multichannel — enable and verify with Get-SmbMultichannelConnection
• Signing — disable if not required (20-30% throughput gain)
• Encryption — AES-128-GCM preferred over AES-128-CCM (2x faster)

Security Comparison

Feature	NFSv3	NFSv4	SMB 3.0+
Authentication	AUTH_SYS (UID/GID)	Kerberos (RPCSEC_GSS)	NTLM / Kerberos
Encryption	None	krb5p (Kerberos privacy)	AES-128-GCM, AES-256-GCM
Integrity checking	None	krb5i (Kerberos integrity)	Signing (AES-CMAC)
Access control	POSIX mode bits + IP-based	NFSv4 ACLs	NTFS ACLs / DACLs
Transport security	None	RPCSEC_GSS	TLS 1.3 (SMB 3.1.1)

NFS Security Considerations

• NFSv3 is effectively unauthenticated — it trusts the client’s claimed UID/GID. Only use on trusted networks
• NFSv4 with Kerberos provides strong authentication but requires a KDC (adds operational complexity)
• Export restrictions (/etc/exports) provide IP-based access control — not identity-based
• Root squashing maps root to nobody — don’t disable without good reason

SMB Security Considerations

• Kerberos via Active Directory is the standard — well-integrated with Windows environments
• SMB signing prevents tampering but reduces throughput 20-30%
• SMB encryption (3.0+) encrypts the entire session — required for sensitive data
• NTFS ACLs provide granular, identity-based access control

Cross-Protocol Migration Challenges

When migrating between NFS and SMB (e.g., Synology NFS to a Windows file server), several metadata translation issues arise:

1. Permission Model Mismatch

Aspect	NFS/POSIX	SMB/NTFS
Identity	UID/GID (numeric)	SID (Security Identifier)
Permissions	rwx (9-bit) + ACLs	DACL entries (allow/deny)
Inheritance	Setgid on directories	Explicit inheritance flags
Default deny	Not supported	ACE deny entries

What breaks: POSIX chmod 750 doesn’t map cleanly to an NTFS ACL. Group membership is identity-system dependent. You’ll need to plan UID-to-SID mapping or accept re-permissioning after migration.

2. Filename Encoding

• NFS: UTF-8 (typically), but the server doesn’t enforce encoding
• SMB: UTF-16LE (Windows), strict validation
• Risk: Files with invalid UTF-8 names or Windows-illegal characters (? * : " < > |) will fail to transfer

3. Timestamp Precision

• NFS: nanosecond precision (server-dependent)
• SMB/NTFS: 100-nanosecond intervals
• Risk: Timestamp comparison failures during verification if precision isn’t normalized

4. Symlinks and Hard Links

• NFS: supports both natively
• SMB: symlinks require SeCreateSymbolicLinkPrivilege on Windows; hard links supported within same share only
• Risk: Symlinks may become broken or unreachable on the destination

When to Use Which Protocol

Use NFS When:

• Linux/Unix-only environment
• High-performance computing (HPC) or scientific workloads
• Containerized infrastructure (Kubernetes NFS CSI drivers)
• Large sequential I/O (media, backup targets)
• You need the simplest possible setup

Use SMB When:

• Windows clients need access
• Active Directory integration is required
• You need SMB Multichannel for bandwidth aggregation
• Compliance requires NTFS-style auditing
• macOS clients (SMB is Apple’s default since OS X Mavericks)

Use Both When:

• Mixed Linux + Windows environment (this is most enterprises)
• NAS appliances (Synology, QNAP, TrueNAS all support both)
• Migrating between heterogeneous storage

Migrating Between NFS and SMB

If you’re migrating data between protocols:

1. Inventory permissions first — understand what ACL model each side uses
2. Plan identity mapping — how will UIDs translate to SIDs (or vice versa)?
3. Handle filenames — scan for illegal characters before transfer
4. Normalize timestamps — truncate to the coarser precision for comparison
5. Verify after migration — checksums don’t lie, metadata comparison does

For a complete migration methodology, see our Data Migration Complete Guide.

Further Reading

• Setting Up NFS Exports: Complete Configuration Guide
• Data Migration: The Complete Guide
• Data Migration Compliance Checklist
• How to Migrate Your Synology NAS