Conducting thorough research on both the hardware and OS aspects is quite essential when building anything related to computing, be it a PC, home server, or even a seemingly simple Network-Attached Storage system. When I built my first storage server using TrueNAS ages ago, I put in some effort to familiarize myself with the intricacies of NAS devices. And I learned quite a lot from several hours of research and a few minutes of the setup process.

However, what really made me more proficient in NAS rigs wasn’t building them or configuring storage pools and network shares after the assembly stage – it was diagnosing issues and fixing them when things went wrong, which they did time and again during my early days. Truth be told, it’s thanks to my failed experiments and random errors I made early on that helped me gain more experience with all that makes my NAS tick.

But NFS permissions still frighten me

When I deployed my very first NAS, I created a Samba share with default permissions for my home lab devices, and it worked well for the most part. But as I got to know more about network security and share permissions, I began looking into more settings I could tweak to my liking. Since I didn’t know better, I’d initially configured Guest Access in my NAS, though I’ve since created separate user accounts with minimal permissions.

Once I got to TrueNAS Community Edition (or Scale, for folks who’ve been using it for as long as I have), I began tinkering with stuff like Apple Time Shares, Audit Logging, and most recently, SMB Multichannel. While it took me some time to get the hang of these facilities (especially Multichannel and its weird multiple subnet requirement), the extra effort was worth it.

Then you’ve got NFS shares, which still pose a challenge to my sanity. The first couple of NFS shares I deployed made my life a nightmare – and that’s putting it lightly. I spent a lot of time messing around with permissions, only to encounter the aggravating access denied error. Although I prefer SMB to NFS for most workloads, I’d be lying if I said the permission spaghetti didn’t teach me anything. Since I was accustomed to simple user credentials, transitioning to NFS shares helped me get used to mounting commands.

I’d left iSCSI untouched for a while, but messing around with it turned out to be a great way to familiarize myself with block-sharing protocols. Again, I had to learn about initiators and fix misconfigured settings a couple of times, but iSCSI turned out to be a solid option for storing VM data from my server nodes. And as weird as it may sound, iSCSI shares + faster Ethernet are a terrific pair for storing games on a NAS. Source: Yours truly, who has attempted this wacky project a couple of times.

Losing a dataset taught me the importance of 3-2-1 backups

I’ve since started using a secondary remote backup server

Switching gears to the storage side of things, I’ve always taken backups seriously. Although I didn’t get into fully-automated setups until recently, I’d still schedule regular backups for my PC even in my days as a fledgling home labber. For my NAS, I’d use the snapshot facility to ensure I had something to fall back on if things went wrong.

What I didn’t realize was that snapshots aren’t the same as dedicated backups and that I was essentially storing everything on the same machine. I learned the latter the hard way when I lost an entire dataset to a failed drive – and this was back when I couldn’t set up RAID because I had different disks in a JBOD setup.

This led me down the data protection rabbit hole, and I began looking into everything from S.M.A.R.T. metrics for the HDDs to Rsync tasks. In fact, I’ve already got a secondary, budget-friendly server stationed at my parents’ place that pulls essential files from my primary NAS for a full-on 3-2-1 backup setup. Had my NAS pool not broken down, I’d probably be content with my flawed single-NAS configuration – and it would’ve hurt even more now that my storage server has become an important part of my work and entertainment life.

Tinkering with RAID setups proved to be just as fruitful

There’s more to RAID levels than meets the eye

Once I’d grown out of my JBOD phase and bought some cheap 2TB hard drives, I figured I could tinker with the RAID facility that I heard every so often. However, I didn’t realize all the “gotcha” moments I’d face when trying all of them out. Even at a glance, I could tell RAID-Z1 has solid usable capacity and fault tolerance for my workloads, but I didn’t realize its resilver times were terribly slow until I tried removing a drive during one of my tests (and no, I just stored random data for the experiment).

Then I started digging into the theoretical aspect of RAID levels. A little research later, and I realized that RAID-Z1 was quite different from the write-hole-afflicted RAID 5. In fact, I could just slot hot spares into my NAS and facilitate faster recovery if one of my RAID-powered drives kicked the bucket. And I haven’t even mentioned the superior transfer speeds or simple but reliable nature of RAID 1 yet. Had I never tinkered with RAID provisions, I’d probably be stuck with a mere JBOD pool.

My obsession with containers began with my first NAS

If we’re going with everything I’ve learned from my NAS journey, this article wouldn’t be complete should I fail to mention self-hosted services. Although I’d played with virtual machines before, containerized environments were entirely new to me. TrueNAS Core introduced me to jails that, despite being pretty different from containers, piqued my curiosity. I’m pretty sure I’ve broken more containers inside virtual machines than my NAS, but working with jails was quite a challenge as a beginner. Luckily for me (and unluckily for my wallet), I stuck with them for a while, and once I got a taste for Docker environments and LXCs, there was no turning back. But that’s a story for another time…