iSCSI vs NFS vs SMB: Beginner's Guide to Choosing the Right Network Storage Protocol
Updated on
6 min read
Network-attached storage protocols shape performance, concurrency, security, and operational complexity for infrastructure teams. This explainer compares three common options—NFS, SMB, and iSCSI—so you can pick the right protocol for Linux servers, Windows file services, hypervisors, and database workloads. The article focuses on how each protocol works, operational trade-offs, and copy-paste lab commands to validate behavior.
What is NFS, SMB, and iSCSI?
- NFS (Network File System): A file-level protocol common on Unix/Linux. NFSv4 provides stateful semantics, stronger locking, and Kerberos-based authentication (RPCSEC_GSS).
- SMB (Server Message Block / CIFS): A Windows-native file protocol with rich ACLs, Active Directory integration, and modern features in SMB3 like encryption and multichannel.
- iSCSI (Internet Small Computer Systems Interface): A block-level transport that carries SCSI commands over TCP/IP so remote LUNs appear as local block devices to initiators.
The Problem / Context
Choose based on workload semantics and operational model:
- Block vs file: Databases and VM disks prefer block access (iSCSI) when single-writer semantics and low-level control matter. Multi-client file sharing typically requires a file protocol (NFS or SMB).
- Cross-platform identity: POSIX UID/GID mapping favors NFS; Windows/AD environments favor SMB.
- Scale and HA: iSCSI needs multipathing and cluster-aware filesystems to share LUNs safely across writers; file protocols centralize coordination at the server.
Picking the wrong protocol leads to data corruption, permission mismatches, or performance surprises—so match semantics, not just throughput numbers.
How it Works / Architecture
NFS (file-level)
- Server exports directories and mediates file operations. Clients issue read, write, open, and close operations over RPC; the server enforces locks and permissions. NFSv4 introduced stateful locks and stronger auth via RPCSEC_GSS (Kerberos).
SMB (file-level)
- Session-oriented protocol with rich metadata (ACLs, oplocks) and Windows-integrated authentication (Kerberos/AD). SMB3 adds session multichannel, per-share encryption, and performance features used in Windows file server stacks.
iSCSI (block-level)
- Targets export LUNs; initiators perform SCSI commands over TCP. The initiator owns the block device and is responsible for filesystem operations and locking. Without a cluster filesystem or an external lock manager, sharing a raw LUN between multiple, uncoordinated initiators risks corruption. Production iSCSI deployments use MPIO for link-level redundancy and careful LUN planning.
- For the host-side path model, failover behavior, and Linux setup, see iSCSI multipathing explained.
Components / Variants
- NFS variants: NFSv3 (stateless), NFSv4 (stateful, ACL and Kerberos support), and pNFS (parallel access).
- SMB variants: SMB1 (deprecated), SMB2/SMB3 (current); Samba implements SMB on non-Windows systems.
- iSCSI components: targets, initiators, IQNs, LUNs, portals, CHAP for auth, and MPIO for redundancy.
Comparison (quick reference)
| Feature / Concern | NFS (v4) | SMB (3.x) | iSCSI |
|---|---|---|---|
| Protocol type | File | File | Block |
| Typical workloads | Linux file shares, container volumes | Windows file shares, AD profiles | VM disks, databases, raw block storage |
| Locking / concurrency | Server-managed locks; POSIX semantics | Server-managed locks; oplocks; ACLs | Client-managed; unsafe for multi-writer without clustering |
| Authentication | Kerberos (RPCSEC_GSS) | Active Directory / Kerberos | CHAP, IPsec for transport security |
| Encryption in transit | RPCSEC_GSS / Kerberos | SMB3 per-share encryption | IPsec or network isolation |
| Performance | Good for file workloads; tunable | Good for Windows workloads; multichannel | Best raw block I/O (single-initiator) with correct HBAs/MPIO |
| Cross-platform fit | Unix/Linux-first; Samba bridges | Windows-first; Samba interoperability | Broad hypervisor/OS support for block devices |
| Operational complexity | Low–moderate | Low–moderate | Moderate–high (multipath, LUN design) |
Real-World Use Cases
- Virtualization: iSCSI or NFS can host VM images; iSCSI gives block semantics while NFS simplifies sharing if the hypervisor manages locks.
- Home directories / Developer shares: NFS for POSIX consistency with Linux clients.
- Windows file services / user profiles: SMB3 with AD and ACLs.
- Storage spaces & hyperconverged: SMB3 (with RDMA/SMB Direct) is used in Windows-based storage fabrics.
Practical Considerations and Gotchas
- Multi-writer safety: Never mount the same raw LUN from multiple initiators unless you use a cluster-aware filesystem (GFS2, OCFS2) or a distributed lock manager.
- Identity mapping: Configure idmapd or Kerberos for NFS when users must map UIDs/GIDs across hosts; design AD group-based ACLs for SMB.
- Network & security: Use dedicated storage networks, VLANs, or IPsec to protect iSCSI traffic; prefer SMB3 encryption or RPCSEC_GSS for file protocols when traversing untrusted networks.
- Monitoring & snapshots: Place snapshot and backup responsibilities on the storage system when possible to avoid client-side performance impacts.
Getting Started — Lab Commands
Mount NFS (Linux client)
# Install client tools (Debian/Ubuntu)
sudo apt-get update && sudo apt-get install -y nfs-common
# Mount an NFSv4 export (replace IP and export path)
sudo mount -t nfs -o vers=4,proto=tcp,rsize=1048576,wsize=1048576 192.0.2.20:/export/projects /mnt/projects
# Verify
mount | grep /mnt/projects
Mount SMB (Linux client using CIFS)
# Install cifs-utils
sudo apt-get update && sudo apt-get install -y cifs-utils
# Mount a CIFS/SMB share (store credentials in /etc/smbcredentials with 600 perms)
sudo mount -t cifs //192.0.2.30/shared /mnt/shared -o vers=3.0,credentials=/etc/smbcredentials,uid=1000,gid=1000
Map SMB (Windows PowerShell)
# Map a drive to a network share
New-PSDrive -Name Z -PSProvider FileSystem -Root "\\192.0.2.30\shared" -Persist -Credential (Get-Credential)
Discover and login to an iSCSI target (Linux open-iscsi)
# Install open-iscsi
sudo apt-get update && sudo apt-get install -y open-iscsi
# Discover targets
sudo iscsiadm -m discovery -t sendtargets -p 192.0.2.10
# Login to the target (replace with discovered IQN)
sudo iscsiadm -m node -T iqn.2025-01.com.example:target1 -p 192.0.2.10 -l
# Check for new block device
lsblk
Further Operational Notes
- Multipathing: Configure MPIO on initiators for path failover; throughput gains depend on array capabilities and workload. See iSCSI multipathing explained.
- Backups: Use storage-side snapshots where possible to minimize client impact and get consistent point-in-time copies.
Common Misconceptions
- “iSCSI is always faster”: Not always—tuning, network topology, and the storage backend heavily influence real-world performance.
- “Raw LUNs can be mounted by multiple servers safely”: Only with cluster-aware filesystems or proper coordination.
- “SMB is Windows-only”: SMB is cross-platform via Samba, but it integrates best with AD-centric environments.
Related Articles
- ZFS Administration and Tuning
- Ceph Storage Cluster Deployment
- Storage Spaces Direct (S2D) Architecture

