NFS vs SMB vs iSCSI for Homelab Storage: What to Use Where

Your homelab NAS is running and your drives are healthy, yet every new service asks the same question in a different form: how does this machine actually get its storage over the network. Proxmox wants a place for VM disks, your Linux containers want a shared media folder, and your Windows desktop wants a backup target that just shows up in File Explorer. Three protocols answer that question, and picking the wrong one turns a simple share into a permissions puzzle or a performance bottleneck you did not expect.

NFS, SMB, and iSCSI all move storage over Ethernet, but they do it at different layers of the stack and with different assumptions about who is in charge of the filesystem. Understanding that layer difference is what makes the choice obvious for each workload. This guide compares what each protocol was built for, how file and block sharing differ in practice, what they demand from your network and your identity setup, and exactly what to use where in a homelab that mixes Linux, Windows, containers, and virtual machines.

At a Glance: NFS vs SMB vs iSCSI for Homelab Storage

What Each Protocol Was Built For

NFS was built for Unix and Linux environments where many clients need access to the same files with minimal friction. Your NAS exports a directory, your clients mount it, and the filesystem you see on the client is the same filesystem the server manages. Modern NFSv4 runs over a single TCP port, supports stronger authentication when you need it, and behaves like a natural extension of the Linux filesystem you already know. If your homelab is mostly Linux, containers, and virtualization hosts talking to each other, NFS feels like the path of least resistance.

SMB was built for the world where Windows is the client, and that heritage shapes every design choice it makes. It authenticates per user with a username and password, enforces access per share and per file, supports encryption in transit as a standard SMB3 feature, and shows up in Windows and macOS file browsers without extra tools. That user centric model is exactly why it is the right choice for anything a person browses to directly, from a photo library to a Time Machine or File History backup target.

iSCSI answers a different question entirely. Instead of sharing files, it shares raw blocks over the network, and the client treats the remote volume as if you had plugged in a local disk. The client formats it, chooses the filesystem, and controls caching and locking. That makes iSCSI ideal when the application expects a real disk device under it, not a folder on a remote server, but it also means only one host should write to a given LUN at a time unless you add clustering.

File vs Block: The Detail That Decides Most Choices

The most useful way to sort the three is by where the filesystem lives. NFS and SMB are file level protocols, which means the NAS owns the filesystem and hands out files and directories while handling locking and consistency for you. Ten Linux containers can mount the same NFS share and read and write alongside each other because the server mediates every operation. SMB does the same for desktops and laptops, with per user access control that matches what people expect when they right click a folder and set permissions.

iSCSI is block level, which means the NAS hands the client a raw volume and steps out of the way. The client creates the filesystem, decides on ext4 or XFS or NTFS, and manages its own cache and journal. That control is powerful for workloads that need to tune the filesystem or that issue many small random writes, like a database or a virtual machine disk image. It also carries a hard rule: two ordinary filesystems mounted to the same iSCSI LUN will corrupt each other quickly, because neither knows the other exists. If you need multiple hosts reading and writing the same dataset, keep it on NFS or SMB. Reserve iSCSI for volumes that one host owns at a time, like a Proxmox VM disk or a dedicated database volume.

Performance, Caching, and Network Demands

On a gigabit homelab network the three protocols will feel similar for large sequential work like media streaming or bulk file copies, because the wire and the disks set the ceiling before the protocol does. Differences emerge with small random I/O and with how each protocol caches. iSCSI tends to show the lowest latency for VM and database patterns because there is no file server in the middle translating operations. The client filesystem talks directly to blocks, which makes short bursty writes and sync heavy workloads noticeably snappier.

NFS and SMB cache differently and that shapes how they behave under load. NFS clients cache attributes and data aggressively to reduce round trips, which helps throughput but can surprise you with brief stale reads if two clients write the same file at the same moment. NFSv4 delegations improve this, and mounting with sensible options matters more than the version number for most homelabs. SMB3 added durable handles, directory leasing, and optional multichannel, plus encryption that you can enable per share. The encryption and signing add CPU cost that you will feel on a low power NAS, so measure before you leave them on for every share.

Network design decides whether any of the performance numbers hold up. Keep storage traffic on a dedicated VLAN or a separate physical link when you can, especially for iSCSI, where a congested link adds latency to every block operation. If your switch supports it, enable jumbo frames end to end for the storage VLAN and test with ping -M do -s 8972 before you claim they work, because one device with a smaller MTU silently fragments and slows everything down. For most homelabs the simpler win is just getting off Wi Fi for storage: a wired gigabit link with sane cabling beats any protocol tuning you do over wireless.

Permissions and Identity Handling

Permissions are where homelab storage goes wrong most often, and each protocol answers identity in a different way. NFS historically trusts the client to say who it is. The client sends a UID and GID, the server believes it, and access follows the usual Linux ownership and mode bits. That model is convenient inside a trusted home network where you control every client, and it breaks down the moment you have untrusted devices or users who should not see each others files. NFSv4 with Kerberos fixes the trust problem, but few homelabs run that infrastructure, so the practical answer is to keep NFS shares on a trusted VLAN and to squash or map users explicitly on the export.

SMB authenticates every connection with a real login, which is why it matches user expectations on desktops. You create users on the NAS or tie it to your directory, set per share permissions, and Windows and macOS prompt once and remember the credential. Access control lists map more naturally to what people set in a file browser, and SMB encryption lets you protect credentials and data in transit when the share crosses a less trusted network segment. The tradeoff is a bit more setup per user and occasionally chasing credential cache quirks on the client when a password changes.

iSCSI sidesteps file permissions entirely. Access is controlled at the volume boundary: the target decides which initiator may attach, usually by IQN and often by CHAP secret or by network ACL. Once the client is attached, whoever can log into the client owns the data. That makes iSCSI permissions simple to reason about and easy to protect with network segmentation, but it also means you should not use a single iSCSI volume as a multi user file server. If people need to share files, share files. Use iSCSI when the boundary you care about is which host owns the disk.

What to Use Where in a Homelab

Most homelabs end up running all three with a clear split. Put shared media and home folders on SMB when Windows or macOS is in the house, or on NFS when the clients are almost all Linux. Both handle large files well, and SMB is the easier answer the moment someone expects to browse to the NAS and log in with a familiar username. Run container volumes, Proxmox ISO and template storage, and Linux backup targets over NFS when the clients are Linux, since the tooling is native and the mount options are well understood. Reserve iSCSI for the workloads that really want a block device: virtual machine disks attached to a single hypervisor, a database that benefits from the host filesystem and cache control, or a volume you later want to back with snapshots at the block layer.

A common homelab mix looks like one NAS exporting three things at once: an SMB share for media and homes, an NFS export for containers and proxmox, and one or two iSCSI LUNs sized for VM disks on a specific host. Keep the file shares widely mounted and the block volumes narrowly attached. When a workload could plausibly use either, ask whether multiple clients need the same files at the same time. If the answer is yes, use a file share. If the answer is no and the software expects a disk, use iSCSI and let the client own the filesystem.

Quick Setup Pitfalls to Avoid

A few configuration details cause most of the frustration beginners report with all three. For NFS, set explicit squash and anon mappings on the export and align UIDs between client and server rather than opening the export to every address with permissive rights. Use NFSv4, pin the share to its own VLAN, and test with a second client writing to the same directory before you trust it with your only copy of anything. For SMB, create a dedicated user per person or per service, avoid mapping everything to guest, and decide on encryption and signing deliberately: enable them where the network is not fully trusted and leave them off on a constrained NAS only after you have measured the cost. Keep SMB and NFS on separate shares rather than exporting the same directory tree through both at once unless you have tested locking and permissions for your exact workload.

For iSCSI, give each LUN to one initiator, set a CHAP secret, and segregate the traffic on its own VLAN or at least its own subnet so discovery and data do not cross user traffic. Do not grow an iSCSI volume by editing the target size alone: grow the target, then rescan on the initiator and expand the partition and filesystem in order. Enable snapshots or replication on the NAS side for every LUN that holds something you care about, because a block volume with one attached filesystem is as vulnerable to accidental deletion as any local disk. Whichever protocol you choose, the rule that saves you is the same: keep at least one more copy of the irreplaceable data somewhere that does not depend on the NAS being up.

The right storage protocol is the one that matches the consumer, not the one that benchmarks highest on a synthetic test. Let people and containers share files over NFS and SMB, and let disks and databases own blocks over iSCSI, with each workload on its own export and its own network segment. Build that split once and your next service will connect in minutes instead of turning into a weekend of troubleshooting permissions.