Enlarge

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

  • If these options seem overwhelming, installing and managing your own storage distribution may not be for you. Jim Salter
  • Once you've decided to install, the next question is where you want the root and boot filesystem to go. Jim Salter
  • This wasn't our first TrueNAS Core test run, so we're given the option to upgrade or install fresh. We chose the fresh install. Jim Salter
  • FORMAT! EVERYTHING! Jim Salter
  • Last chance to abort! It's a little odd that we're not told about the preference for "flash media" until the "oh no" screen, but okay. Jim Salter
  • You'll need to set a root password before rebooting. There is no strength check here; if you want to use "poop" as your password, the installer won't complain. Jim Salter
  • TrueNAS supports either UEFI or BIOS boot. Both modes worked on our Linux KVM virtual machine, and directly on the metal of the Storage Hot Rod. Jim Salter
  • That's the whole install—pop the install medium out of the system and reboot. Jim Salter

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

  • This ASCII splash screen hangs around for five seconds; if it hasn't received input by then it falls through to a standard boot. Jim Salter
  • The only thing most users will need to do at the text console is configure the network interface (which defaults to DHCP). Jim Salter
  • You might think you'd WANT to "remove the current settings of this interface"—but if you do, it just returns you to the menu. So, uh, don't? Jim Salter
  • Don't forget to configure your default route (and DNS) as well as the IP address, if you leave DHCP mode. Jim Salter

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

  • If you're accessing TrueNAS by raw IP address, the way we are here, expect the broken lock icon in the address bar—you can't give an SSL certificate to an IP address. Jim Salter
  • On your first login, you'll get a small, one-time splash dialog offering you links to documentation, forums, and optional paid support. Jim Salter
  • When you expand the Storage menu on the left sidebar, the top entry is Pools. Here's where you'll assign your disks. Jim Salter

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.

  • The most important, and easily overlooked part of this dialog—particularly if you have a ton of disks—is the free-entry text box "name". Don't forget to name your pool! Jim Salter
  • See that big, inviting add vdev button? It likely doesn't do what you think it does—it's there for adding support vdevs, not storage vdevs. Jim Salter
  • If you have a lot of disks, like we did, you'll likely need to scroll down to find the next crucial part of the create pool dialog—the "Data Vdevs" section. Click the blue right-arrow here to add the disks you checked above. Jim Salter
  • You don't actually need to check any of these boxes, unless you want to remove disks you've already inserted. Note that raidz2 is selected by default—all we need to do here is click "Create." Jim Salter
  • If you drop down the "vdev type" list, you get "stripe" and "mirror" in addition to RAIDz1, RAIDz2, and RAIDz3. Jim Salter
  • TrueNAS really does mean "mirror" as in "one big mirror vdev" here, not a pool of mirrors. Note the estimated raw capacity: it's the same as a single disk. Jim Salter
  • "Stripe" really means "make every one of these disks a singleton vdev," as you can see from the total capacity. Jim Salter

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.

  • After changing our selection back to RAIDz2, we're given a last chance to bail before nuking their partition tables and adding them to the pool as a new vdev. Jim Salter
  • We haz pool! Yay! Jim Salter
  • The gear icon off to the right exposes the option to add vdevs, scrub the pool, check its status, or export it. Jim Salter

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

  • We're going to join a Windows Active Directory Domain here, which largely avoids the need to set up individual users on the NAS itself. Jim Salter
  • Joining the domain is as simple as it can be—enter the AD domain name, a domain name and password with privileges to add a machine to AD, and check "Enable." Jim Salter
  • Active Directory domain join completed in well under one second—so rapidly, we felt the need to check Active Directory Users and Computers to make sure it worked. Jim Salter

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

  • Adding an SMB share looks straightforward enough… but it's asking for a path, and we haven't created any datasets to actually share yet. Jim Salter
  • I was very frustrated trying to figure out where to go to create a dataset. There's my pool. There's no "dataset" option under the storage menu, on the left. It's not in the gear icon, to the right. Where IS it?! Jim Salter
  • Turns out that there's a hamburger menu off to the right, hidden until I horizontally scrolled. This won't be the case for most people browsing in full-screen mode, but it frustrated me for a good 15+ minutes. Jim Salter
  • Once I found the hamburger menu, creating a dataset to map an SMB share to was easy enough. Jim Salter
  • Advanced properties for the newly created dataset—such as ZFS recordsize—live here. Jim Salter
  • I want to do some performance testing later, so I created several datasets with different recordsizes—here, TrueNAS is (quite correctly) warning me that if I create a 4K recordsize dataset, I'm not going to like how it performs. Jim Salter

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!

  • Now that we've got datasets created, it's easy enough to see them laid out in the Pools dialog. Jim Salter
  • Now that we have datasets to expose, we return to the Windows Shares (SMB) dialog to create shares that can be mapped from the network. Jim Salter
  • There are lots of options exposed for our new SMB share—of particular note, ACLs mean that file and folder permissions will map properly to Windows clients, and Enable Shadow Copies means that Windows clients will have the "Previous Versions" tab enabled in File Explorer when browsing TrueNAS. Jim Salter
  • After we click "Submit", a dialog pops up for editing ACLs (Access Control Lists, aka file and folder permissions attributes). Jim Salter
  • Just clicking "Save" isn't good enough—what TrueNAS gave us for defaults will need some modification before it's acceptable without an error being thrown. Jim Salter
  • Without actually configuring the ACLs, we don't have write permissions on the share as seen from client PCs. Jim Salter

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.

  • Our first try was just changing the existing ACL from the local "wheel" group to the domain "Domain Users" group. Jim Salter
  • On closer inspection, the ACL permissions themselves also only allowed read privileges. So we'll need to update those as well. Jim Salter
  • We only wanted a single set of permissions that covered all users, so we tried removing all permissions for the "everyone" ACL. Nope. Gotta delete that ACL instead. Jim Salter
  • Beware the lurking "Apply" checkbox, whose function is to ignore your changes if left unclicked. I do not love this convention. Jim Salter
  • Inherit is off by default… but if you don't turn inherit on, you can't proceed. OK… Jim Salter
  • Here's another thing we got wrong initially—the important part isn't really who the Unix owning group is on the left, it's who the group is INSIDE the ACL, on the right. Jim Salter
  • It took us a minute or three to get here, but we've finally got the right permissions on our share, and Domain Users can create and write files at will. Jim Salter

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

  • If you aren't taking snapshots on a recurring basis, you're leaving an awful lot of ZFS' true value on the table. Jim Salter
  • We can see all periodic snapshot tasks here, along with the policy on when those snapshots will be deleted. Jim Salter
  • We're actually not entirely clear what Cloud Sync is—but whatever it is (rsync, maybe?) it's definitely not ZFS Replication. Jim Salter

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."

Creating a replication task

  • In order to replicate to a remote system, you need to publish SSH keys, one way or another—the "Semi-automatic" method, which we did not test, only works between TrueNAS boxes. you need to publish SSH keys, one way or another—the "Semi-automatiRead More – Source [contf] [contfnew]

    arstechnica

    [contfnewc] [contfnewc]