NFS: the Linux-native file-sharing protocol

NFS (Network File System) shares files, not blocks, and it’s built around the assumption that everything talking to it understands POSIX permissions. A client mounts an NFS export and sees it as if it were a local directory, with the same ls -la output, the same UID/GID ownership model, the same symlink behavior. That’s the appeal: it’s lightweight, it’s been stable for decades, and on a Linux-to-Linux path it has less protocol overhead than SMB, which matters when you’re pushing large sequential transfers (media files, backup streams, VM disk images) across a gigabit or faster link.

The catch is exactly that POSIX assumption. NFS doesn’t ship its own user database. Permissions are enforced by matching numeric UID and GID between the client and the server, which means if your NAS has plex as UID 1000 and your Proxmox host has a different service running as UID 1000, NFS will happily let that unrelated process read and write files it has no business touching, because as far as NFS is concerned, the numbers match. Keeping UID/GID mappings consistent across every machine that mounts an export is a real operational burden, and it’s the single most common cause of “why can’t I write to this NFS share even though the permissions look fine” questions. NFSv4 added Kerberos-based identity mapping to fix this properly, but almost nobody runs it at home because setting up a Kerberos realm for a homelab is its own rabbit hole. In practice, most home NFS deployments either run everything as a shared UID or just accept the exposure on a trusted internal VLAN.

NFS has no concept of a Windows client without extra software, and modern Windows versions dropped the NFS client from default installs entirely. If anything in your household touches storage from Windows or macOS without extra configuration, NFS alone won’t cover it.

Where NFS wins: Linux-to-Linux storage, especially Proxmox or other hypervisors mounting shared storage for VM disks, and any workload where you control every client’s UID/GID mapping yourself (a media server pulling from a NAS, a backup job writing to a dedicated target). It’s also the simplest shared-storage backend to stand up for Proxmox clustering, which is worth knowing if you’ve read the clustering article on this site and are choosing what to put behind it.

SMB: the one everything actually speaks

SMB (also called CIFS in its older incarnation, implemented on Linux via Samba) is the protocol Windows file sharing is built on, and by extension the protocol every consumer OS, phone app, and smart TV has at least some support for. Where NFS assumes a POSIX world, SMB brings its own authentication (usernames and passwords, or AD/LDAP integration for anything beyond a handful of users) and its own ACL model layered on top of whatever the underlying filesystem supports. That makes permission management more self-contained: you create a Samba user, you grant that user access to a share, and it doesn’t matter what UID the client machine thinks it’s running as, because SMB handles identity at the protocol level instead of trusting numbers from the network.

The tradeoff is overhead. SMB’s protocol chattiness, especially on older SMB1/SMB2 implementations, used to make it noticeably slower than NFS for large sequential transfers on the same hardware. Modern SMB3 with multichannel support closes most of that gap on a fast local network, and for anything under 10GbE the difference rarely matters in practice, but on a tuned 10GbE or faster link doing heavy sequential I/O (bulk backups, large media ingests), NFS still tends to edge it out. SMB also does real file locking that Windows applications expect (so two people don’t silently clobber the same Office document), which NFS historically handled more loosely.

Where SMB wins: anything with Windows or macOS clients in the mix, anything accessed by phones/tablets/smart TVs, and any share where you want per-user access control without syncing UID numbers across every machine on the network. For most home data-hoarding setups, where the array gets browsed from a laptop, streamed to a TV app, and occasionally hit from a phone, SMB is the default for a reason, not an accident.

iSCSI: block storage, not file storage

iSCSI is a different category entirely. NFS and SMB hand out files and directories; iSCSI hands out a raw block device over the network, called a LUN (logical unit number), that the client formats and manages itself exactly as if it were a locally attached disk. There’s no browsing an iSCSI target in a file manager, no concept of “a file” at the protocol level at all, just blocks. The client (the initiator) connects to the target (your NAS or storage server) and gets what looks like an empty drive to partition, format, and mount.

That block-level approach has a specific, narrow set of advantages. A single filesystem on top of an iSCSI LUN performs closer to local-disk speeds than either file-sharing protocol, because there’s no file-protocol translation layer in the way, just block I/O. It’s also the protocol of choice when an application genuinely needs exclusive, low-level access to a device, databases that want direct control over their storage layout, or a Windows failover cluster that needs shared block storage multiple nodes can see.

The real cost is that iSCSI LUNs are normally single-writer. Multiple machines can see the same LUN, but unless you’re running a cluster-aware filesystem on top (VMFS-style, or a clustered filesystem like OCFS2 or GFS2) that coordinates writes, two hosts writing to the same LUN at once will corrupt it, because nothing is arbitrating file-level locks the way NFS and SMB do natively. iSCSI also adds real setup complexity: initiators, targets, portals, and on anything beyond a single connection, you’re looking at multipath configuration to get redundancy. For a typical home NAS sharing a media library or backup target, iSCSi is usually overkill. It earns its complexity when a specific workload actually needs block-level access or raw performance that file sharing can’t deliver, not as a default.

Where iSCSI wins: shared VM storage behind a hypervisor cluster where you need true block-level performance and you’re running a cluster-aware filesystem on top, or any application that explicitly wants a raw block device rather than a file-sharing mount.

The mistake: serving the same data over two protocols at once

It’s tempting to export the same directory over both NFS and SMB so every client type can reach it however it wants. Don’t, at least not for anything being written to from both sides. NFS and SMB enforce locking and permissions differently, and a file one client has open and locked under SMB semantics isn’t visible as locked to an NFS client touching the same inode, and vice versa. Two processes editing or appending the same file through different protocols at once is a real, if intermittent, path to corrupted data, worse than any single protocol’s own quirks. If you need dual access, make one protocol the single writer and the other read-only, or split the dataset so each protocol owns its own directory tree.

Picking one, in practice

For a typical data-hoarding setup, the honest default is SMB for anything a human or a consumer app touches directly, NFS for Linux-only backend plumbing (a media server’s library mount, a backup target, Proxmox shared storage) where you control both ends, and iSCSI reserved for the specific case where something genuinely needs block-level access. Don’t pick based on which one your NAS vendor made the flashiest setup wizard for. Pick based on what’s actually connecting, and change your mind later if the workload changes. Nothing here is permanent; re-exporting a dataset under a different protocol is an afternoon of work, not a migration.