Network shares are an essential part of any NAS server, as they’re responsible for providing centralized storage to your home lab paraphernalia. But when you’re a beginner, you’ll probably stick to SMB (Server Message Block) while ignoring the other protocols on your Network Attached Storage server. That’s pretty much what I did for the first couple of months after assembling a NAS from old hardware, as SMB was enough to meet my file-sharing needs.

But as I went deeper into the tinkering rabbit hole, I began experimenting with NFS (Network File System) and iSCSI (Internet Small Computer System Interface) – two protocols that are vastly different from SMB. And now that I’ve been using them for a while, I regret not setting up a unified setup involving all three protocols sooner.

I use SMB for most of my shares

It’s easier to set up than its brethren, after all

Starting with the file-sharing protocol that’s perfect for casual users, SMB has many aces up its sleeve. It has top-tier cross-platform support, and works exceedingly well with Windows clients – which comprise a considerable chunk of my home lab devices. It also plays well with Macs, and its Linux implementation isn’t bad by any means, either. Configuring the shares and granting permissions to the user is a lot easier on SMB, and for someone who often conducts multiple server experiments, I don’t need to expend a lot of brainpower when setting up a SMB share for quick transfers.

I won’t sugarcoat it: In a mixed environment such as mine, SMB is definitely more useful than its counterparts, as I don’t need to spend extra time tweaking different permissions just to get my shares working reliably on Windows. Ever since I’ve gone down the Windows Server rabbit hole, I’ve also started tinkering with the advanced SMB settings on the platform. But as much as I love SMB, it’s not perfect for my Linux tasks…

NFS is great for Linux projects

It’s also as intimidating as many folks make it out to be

Besides my Windows devices, I’ve got a bunch of virtual machines, single-board computers, and outdated rigs armed with Linux. Although I could set up SMB shares for them, its additional overhead on Linux makes it somewhat unoptimized for weak clients. That’s where NFS comes into the equation, as its lightweight design, fewer abstraction layers, and kernel-level integration grant it a speed advantage over SMB on Linux rigs.

Now, I wouldn’t go so far as to say that NFS is as easy to tinker with as SMB. Although I’ve grown somewhat familiar with the protocol, I still mess up the user and group permissions occasionally. In fact, keeping the user IDs consistent across my systems has been a bit of a challenge. I’ve also started using Kerberos authentication to safeguard my NFSv4 shares, but it’s admittedly a lot more complex than the simple (yet fairly effective) security options on SMB.

Luckily, dual-stacking SMB and NFS shares is an option on most NAS distros, and that’s pretty much how I got over my fear of the latter during my early home labbing days. Of course, configuring both protocols on the same dataset requires strict precautions, as one simultaneous write operation to the same file is all that’s needed to cause data correction. But as long as you stay vigilant about the protocol when accessing the dataset, dual-stacking is fairly useful for hybrid setups such as mine.

I love building wacky projects with iSCSI

It works well on my everyday machines and server rigs, too

Technically, iSCSI is a block-level protocol for turning a network drive into a local disk on the client’s end, making it a lot different than its file-level rivals. But it's just as useful as the other two for my home lab experiments. For example, I’ve created an iSCSI dataset from an old SSD to house the storage-hogging games for my Windows 11 PC. And as weird as it may sound, this setup works really well over a fast Ethernet connection. I’ve tried using SMB for this project in the past, but some games outright refused to boot on a network drive. Meanwhile, the same titles worked with zero latency on an iSCSI-powered “local” drive on a 2.5GbE connection. Moving over to a 10G setup and using NVMe drives made the slightly longer boot (and fast-travel) times barely noticeable, even in open-world games and multiplayer titles.

Likewise, iSCSI’s minimal latency makes it just as effective for creating data pools for my virtualization platforms. Sadly, iSCSI doesn’t play well with multiple clients, so I have to assign the entire dataset to a single PC or risk corrupting my precious data.

The best setup involves all three protocols

As much as I prefer SMB for quick projects, I refuse to part with the NFS and iSCSI shares I’ve painstakingly deployed on my NAS. If anything, configuring them on the same server has taught me about their respective strengths. Had I stuck to one faction, my NAS wouldn’t be versatile enough to serve my project-building needs.