Ever since I built my first Network-Attached System, I’ve been a member of the SMB faction and never really dabbled that much in the other storage protocols. After all, SMB has a simple setup process, works well with every OS in my computing arsenal, and doesn’t tax my brain cells when things go wrong. But the deeper I went into the home lab rabbit hole, the more I realized that SMB isn’t ideal for every project.

Now, I’m not trying to say that SMB is bad – quite the opposite, as it’s still my favorite storage protocol. But I’ve stopped relying on it for tasks that are better suited to NFS or iSCSI shares.

NFS is more efficient for non-Windows systems

And NFSv4 solves the authentication problem

SMB may be unmatched for Windows setups, but the situation is a lot different in the Linux ecosystem. Sure, I could configure SMB clients on my Ubuntu, Arch, and other Linux systems, but the extra overhead and the unoptimized default settings on most distributions leave a sour taste in my mouth. That’s not really an issue on hardcore NAS servers and fast bare-metal clients. But considering that I often create network shares inside VMs and use cheap SBCs as clients, SMB’s additional overhead makes it less optimal for my experiments.

Likewise, NFS is faster at transferring large files like movies, ISOs, and full device backups, which makes it better than SMB when I need to move TBs of data between my Linux virtual guests. I’ll admit that managing permissions is a royal pain on NFS, and the lack of additional authentication in the earlier versions of the protocol can be an issue if you’ve got multiple users accessing the same set of devices.

However, NFSv4 (and v4.1) supports Kerberos-based authentication to add an extra validation layer between my clients and NAS servers. I also used to be scared of failed NFS share mounts causing problems until I realized I could just set up an auto-mount entry in the /etc/fstab config file on essential Linux systems.

Dual stacking SMB and NFS is viable (with some caveats, of course)

Although I keep my SMB and NFS shares separate these days, I used dual-stacking to get familiar with the latter’s UID and GID shenanigans when I decided to take the plunge into the NFS rabbit hole. By dual-stacking, I mean I configured SMB and NFS shares on the same dataset, and as weird as it may sound, this setup works surprisingly well – provided I take enough precautions.

For example, I only kept the SMB or NFS share active at a time, and would wrap up all my data transfer tasks before switching to the other protocol. This way, I wouldn’t have to worry about accidentally causing data corruption by modifying the same files on my Windows and Linux machines.

I've started using iSCSI block shares a lot more

They're perfect for wacky NAS projects

Switching gears to block-based shares, iSCSI is surprisingly useful for certain tasks. Let’s say I want to access the games I’ve stored on my NAS. Creating an iSCSI share and mapping it as though it were a local drive on my gaming machine is probably the best way to bring this weird project to life, as network-based shares over SMB would result in crashes – or even fail to boot certain titles.

An iSCSI share, however, provides minimal latency even at 2.5G speeds, though the slow boot times can be somewhat annoying when running games off NAS drives, especially HDDs. Source? Yours truly, who has tested this idea twice – once on a 2.5G connection and later at 10G speeds, with the latter working exceptionally well when I paired the iSCSI share with old NVMe SSDs. I’ve also had better luck storing virtual drives for my VMs with iSCSI shares than SMB. Not only does iSCSI play fair with all the hypervisors in my home lab, it’s actually faster than SMB when transferring multiple small files.

The caveat with iSCSI is that I need to relegate a dataset for each device in my home lab, as it’s far from ideal for sharing files between multiple systems. Yeah, I know it’s technically possible to do so, but configuring cluster-aware file systems is a bit overkill for normal projects – even more so than NFS’ admittedly convoluted permissions. And that brings us full circle…

But I’m not going to ditch SMB, either

As much as I’ve grown fond of NFS and iSCSI, it’s not like I’ve entirely dropped SMB from my home network. For example, SMB’s broad compatibility makes it ideal for my Windows machines, and it’s what I use to bulk-transfer screenshots and code files between my PC and MacBook. Sure, Windows 11 lets me use NFS on the client machines, but SMB is still a better option for devices running Microsoft’s flagship OS. I’ve also started looking into Windows Server as of late, and the advanced SMB features on the platform make it more tempting than NFS or iSCSI. Plus, the fact that it just works on every device, regardless of the underlying OS, makes SMB pretty handy when I don’t want to dabble in NFS’ ACL rules.