Earlier this week, network-storage vendor iXsystems announced the release of TrueNAS 12.0-BETA1, which will replace FreeNAS later in 2020. The major offering of the new TrueNAS Core—like FreeNAS before it—is a simplified, graphically managed way to expose the features and benefits of the ZFS filesystem to end users. In the most basic environments, this might amount to little more than a Web front-end to ZFS itself, along with the Samba open-source implementation of Microsoft's SMB network file-sharing protocol.
Although this might be sufficient for the majority of users, it only scratches the surface of what TrueNAS Core is capable of. For instance, more advanced storage users may choose to share files via NFS or iSCSI in addition to or in place of SMB. Additional services can be installed via plug-ins utilizing FreeBSD's jail (containerization) facility, and the system can even run guest operating systems by way of FreeBSD's BHyve virtualization system—all managed via Web interface alone.
TrueNAS Core will be what FreeNAS is now—the free, community version of iXsystems' NAS (Network Attached Storage) distribution. End users—and system administrators who aren't looking for paid support—can download FreeNAS or TrueNAS Core ISOs directly from iX, burn them to a bootable optical disc or thumbdrive, and install them on generic x86 hardware like any other operating system.
We've been kicking the tires on early versions of TrueNAS Core since its announcement in March, and we see no evidence of any FreeNAS functionality slipping away behind "premium only" paywalls. The dividing lines between TrueNAS Core and TrueNAS Enterprise are no different than those between earlier versions of FreeNAS and TrueNAS itself.
Due to the sheer breadth of TrueNAS Core's offerings, we can't walk you through everything it's capable of in a single article. But we will hit the major highlights along the way—we'll install the distribution and set up a storage pool on eight physical disks, join TrueNAS Core to a Windows Active Directory domain, set up some file shares, and play with ZFS snapshot and replication facilities.
The user interface has come a very long way in the six years since our 2014 review of FreeNAS. The modern TrueNAS interface has been entirely rebuilt from scratch, along much more coherent lines. If you've tried and given up on old versions of FreeNAS, it's worth taking a second look at how far it has come.
Installation
The first-boot phase of a TrueNAS Core installation is the simplest OS installation we've ever seen. TrueNAS Core doesn't ask you to do the complicated stuff during the original installation; all it wants to do is slap the operating system onto a boot disk and have done with it. You pick a disk (or USB thumb drive) to act as the boot-and-root medium, set a password, and pick UEFI- or BIOS-style boot—that's it.
All of the interesting stuff—like configuring the rest of your disks as actual storage devices or creating and exposing network shares for them—happens later.
First boot
There isn't much to do on your first reboot after installing TrueNAS Core—little or no configuration is ever done at the physical machine. By default, the system will assign configurations to any live network interfaces by DHCP. If you don't want to issue a specific DHCP reservation for the TrueNAS system at your router, you'll need to manually set an IP address in the text-based menu here.
Once you've got your TrueNAS Core system living at its "forever IP address," it's time to walk away, sit down in front of the computer or mobile device of your choice, and browse to the TrueNAS Web interface to get the real configuration work done.
Web login and initial configuration
Once you sit down at another computer and pull up TrueNAS Core by IP address, you'll get a nocturnal-user-friendly Dark Web interface laying out TrueNAS's functions. There isn't a wizard to walk you through creating your first storage pool—you'll need to get through that solo—but it's not too hard. After expanding the Storage menu on the left sidebar, select Pools and click the "Add" button. This is where the fun begins.
ZFS pool structure isn't that complex: a pool consists of vdevs, and a vdev consists of disks. Each vdev may be a RAIDz striped array, a mirror array, or a single disk. Unfortunately, most users aren't accustomed to thinking in multiple levels of organization and so conflate "pool" with "vdev" into a single, messy structure.
TrueNAS attempts to make life easier for those users without obfuscating the real structure of the system too badly. For the most part it succeeds, but it's still a bit of an adventure figuring out how the interface maps to the underlying reality on your first trip through. If you have lots of physical drives, the problems get a little worse—the "pool name" text box is visually understated, and since it sits above the list of drives, you might miss out on it entirely and wonder why TrueNAS refuses to validate your entry once you click "Create" at the bottom of the screen.
With our eight physical drives selected, TrueNAS defaulted to creating a single RAIDz2 vdev out of them—which is what most users will likely prefer. You can change this by clicking the vdev type and selecting RAIDz1, 2, or 3, or going with "Mirror" or "Stripe."
Selecting "Mirror" turns all eight disks into a single eight-wide mirror vdev—which probably isn't what users who click that selection with that many drives actually want, but we appreciate the literalness of it. The existence of "Stripe" soured us again a bit, as it's the one entry on the list that isn't a vdev type at all. Instead, it takes all selected disks and makes individual single-disk vdevs from them.
Having explored all the vdev type options, we changed back to the default RAIDz2 and clicked Create. After one final confirmation, we had our storage pool—and options to export it, add vdevs to it, scrub it, check its status, or expand it.
To create my usual preference for pool structure—a pool of two-wide mirror vdevs—we would have needed to create it one vdev at a time, selecting only two disks and creating a mirror vdev, then using the gear icon here to return and add more vdevs until we were done. Similarly, we could have created two separate four-wide RAIDz1 or RAIDz2 vdevs this way.
Joining an Active Directory domain
Joining TrueNAS to a domain allows you to take advantage of domain single sign-on (SSO). Instead of having to laboriously set up users on the NAS to match all the users on your network, TrueNAS can just consume the existing directory structure, which also avoids the need to update passwords on the NAS separately from the passwords on the users' PCs.
This, of course, requires that you have a Windows domain in the first place. For that, you'll need a copy of Windows Server running as domain controller, and you will need an actual domain set up and working prior to all this. You'll also need to make certain that the TrueNAS Core machine's DNS source is an Active Directory domain controller.
Assuming you have all those things, the domain join process in TrueNAS Core works lightning fast; it's enormously faster than joining an actual Windows PC to the domain. Well under one second after clicking "Save," we were joined to the domain—so rapidly that we went and checked Active Directory Users and Computers on the domain controller. Yep, there we were, all right!
Adding a new Samba share
It's easy enough to see that adding an SMB share is done from the Sharing menu on the left—but finding the dialog in which you create a dataset to share is a little more obtuse. It's under Storage—which is no surprise—but rather than having its own submenu there, it's inside a hamburger menu on the far-right side of your pool's name in the Pools submenu.
This created a particular problem for us, because our browser wasn't full-screen—we kept it at a relatively modest window size to make the screenshots easier to work with on the site. This unfortunately hid the hamburger menu for the pool on the wrong side of a subtly styled horizontal scrollbar, which led us to 10 or 15 minutes of frustrated tail-chasing before finally figuring out where the dataset creation menu was.
Once you're in there, creating datasets is simple enough. Just like ZFS itself, TrueNAS will default your datasets to a recordsize of 128KiB unless you ask it otherwise. We created a couple of datasets for performance testing later, with recordsizes of 1MiB and 4KiB, and TrueNAS (quite correctly) warned us that if we set recordsize so low on a pool with an eight-disk vdev, we wouldn't like how it performed. Thanks, TrueNAS!
Creating a new share mapped to our dataset exposes some of TrueNAS's best "easy mode" functionality—Windows ACLs (Access Control Lists) work right out of the box, meaning that adjusting file and folder permissions from File Explorer on Windows Clients will just work. Trying to get this right on a Linux system is just plain painful, so this is an important feature and a positive differentiator for TrueNAS and other systems which offer it.
We can also see that Shadow Copies work by default—which means those same Windows Clients will have a Previous Versions tab enabled in File Explorer while browsing shares on the NAS, enabling them to self-serve and find copies of important files that they've lost or corrupted. Unlike the Recycle Bin, this applies for file changes, not just deleted files—so if you accidentally Ctrl-A highlighted an entire document, deleted the whole thing, and then accidentally saved over the original, you can go to Previous Versions to retrieve an intact copy.
Things got a little weirder once we submitted the share, unfortunately—rather than using a set of default ACLs that just work for most people, TrueNAS insisted on us actually creating ACLs. Without doing so, users have no write access to shares—and unfortunately, the ACL dialogs turned out to be pretty buggy.
Getting the ACLs right is a bit of a chore in TrueNAS. The defaults aren't going to be usable for just about anyone, which means you'll need to dive in and create them manually. This wouldn't be so bad, but it's not entirely clear which parts of the dialog apply to the global Unix permissions and which side apply to the inside of the actual ACLs—the two are entirely separate in reality but are jumbled together in a single dialog here.
We also got frustrated with a gratuitous "click Apply or we'll eat your changes quietly" checkbox that must be ticked to apply changes to group ownership. Finally, we experienced a bug that caused TrueNAS to just quietly eat all of our changes if we ticked the "apply recursively" checkbox. We had to give up on that and apply ACLs to each share individually.
Once we'd gotten through all of that, everything worked the way it should—we had shares, they mapped properly to Domain users, and permissions could be viewed and applied correctly from Windows File Explorer.
The recursive ACL bug was fixed shortly after we encountered and reported it, so readers shouldn't encounter it themselves. The major reason we include it here is to remind readers that TrueNAS Core is still in beta—although it's usable, it is not yet production quality.
Snapshots and replication
You definitely shouldn't consider your setup process complete on any ZFS system until you've got a regularly recurring snapshot process configured. In TrueNAS, that's under Tasks–>Periodic Snapshot Tasks, and it's relatively straightforward. You can create as many snapshot jobs as you like here, along with options such as whether they're recursive (apply to datasets beneath the one the task runs on), what their naming schema looks like, and how long they should remain on the system.
That last part—the lifetime of the snapshot—isn't a ZFS feature, it's a TrueNAS feature. ZFS snapshots don't disappear unless and until manually destroyed, so you need an automated mechanism to get rid of stale snapshots for you or your drive will fill up with them eventually.
Under Tasks, we also noticed "Cloud Sync"—it's not immediately apparent just what that is from looking at the interface, but searching iXsystems' blog reveals that it's a file-based synchronization service using rclone to back files up to Amazon S3 buckets. What we were interested in was ZFS replication—which is, appropriately enough, under "Replication tasks."