Jump to content
Computer Audiophile
  • entries
  • comments
  • views

Review: iXsystems FreeNAS Mini: A Plug-and-Play ZFS NAS that doesn't suck to set up.

Sign in to follow this  


Like many here, I try to keep computer audio simple. My music library resides on a single external bus-powered Oyen firewire drive. Until recently, this was a 1TB Samsung HDD. I've now replaced it with a 1TB SSD, but what is of relevance here is what happened after about three years of constant, daily use. Like many drives (HHD and SSD), it started to fail. However, it wasn't obvious to me, at first, that the hardware was failing. I am still not certain. When I copied the contents of the library, I noticed some files failed to copy:


I recently found out the hard way that a music file can become corrupted without the md5sum or sha1 checksum changing.


This is because the checksum is a signature of the bit content of the data fork, whereas various extended attributes can (and do) change all the time in the resource fork of the file that is present on filesystems such as Apple's HFS+ filesystem.


If the resource fork metadata (not to be confused with music file tag metadata, which belongs to the data fork of the file) becomes corrupted, it can prevent copying or playing the music file. (So in this extreme sense, SandyK is right, files with identical checksums can sound different, but it is important to keep in mind the difference in this case is due to file system corruption).


This raises a problem: Typically we check (if at all) for file corruption based on the checksum of the data fork. Does anyone do this for resource forks? Does zfs or btrfs self-healing take this into account? Or are resource forks subject to bitrot that can go undetected?


HFS+ has a reputation for being a fragile file system. I decided if I wanted to definitively address this problem, I wanted one of the more robust "self-healing" filesystems like sfs or btrfs on a NAS. Although replacing music files that become corrupted is a pain in the arse, it is at least possible. However, for my laboratory experimental data (including many 100s of GB of X-ray diffraction images), the data files are irreplaceable. Similarly, family digital photos cannot be replaced. I decided to get a NAS as part of a (redundant) data backup and storage strategy for my research group, and this would also allow me to keep a remote backup copy of my music library (and family photos) at work. An added bonus is that these would be accessible from any computer at work (or anywhere else).


Since I have a computer hardware budget and limited time, I didn't want a DIY project. I wanted a NAS that would essentially be plug-and-play with minimal configuration. After a lot of consideration, I went for a ZFS-based freeNAS with four disc drives that could be configured in a raid array. The FreeNAS mini runs freeBSD, which happens to be the flavor of unix from which Darwin (OS X unix) was derived. The main point is it is a fairly standard unix operating system, so anyone familiar with linux, OS X, or other flavors of unix should be able to find their way around. The FreeNAS project is an open-source effort designed to allow a NAS such as the one I purchased, or one you might choose to assemble yourself, to be configured from a semi-user-friedly web-based GUI. (Although I am actually more of a unix command-line-oriented individual, rather than a GUI fan, I actually found the interface to be quite helpful. In fact, my only gripe is that the way this thing works is that changes made within the GUI persist, but many system modifications one might try to make on the command-line get wiped out upon reboot (or sooner). At first, this irritated the living shit out of me, but now I have come to appreciate the point of doing things this way, if one is administering what the vendor insists upon referring to as an "appliance." If I ever decide the GUI does more harm than good, I can always kick it to the curb, but for now I have surrendered to its functionality for the most part.)




The hardware seems to be first-rate. The chassis holds four conventional hard drives, which the vendor optionally supplies, formatted and ready to install.



I decided to take advantage of getting everything bundled, and got the largest hard drive option they sell. Their choice is the WD Red HDD, which I guess is reasonably robust, unlike the 3TB Seagate Drive with the 38% failure rate I bought at Costco.



All you do is stick the drives in the bays and plug it in. (I didn't realize you have to use the ejection lever to put the drive in properly, or it won't seat on the pins and power up. Customer service got back to me at 7 am local time when I submitted an 11th-hour plea for help via email.)


Once you get the discs installed, you have to hook up a VGA monitor temporarily, and a USB keyboard, and issue a few responses to some initialization prompts, and then you can access the web browser-based GUI from the comfort of any other computer on your local network to complete the setup process. Here is what the GUI looks like:




What you see below is the web-based interface that allows you to control the NAS. You have to configure everything using the GUI. The GUI then saves the configuration parameters in a sql-like database file, and from that file standard unix configuration files are generated (and re-generated) upon rebooting (sometimes sooner). This can be a double-edge sword. I quickly learned to stop fighting it, but it still bugs me that I can't over-ride some default settings that appear to be counter-productive or security holes, without coming up with some crazy work-around strategies (one of which I describe at the end.)




You can save the original factory settings, and each set of changes (and prune the list as you see appropriate), which allows you to go back to and boot into a previous configuration if you run into problems:




Once you configure the RAID and import some files, you can export all or portions of the RAID file system to your other computers using Apple's firesharing protocol (AFP), SMB, NFS, or other options. The GUI allows you to configure these, and importantly, restrict who can access them and from what computers (using hosts allow and host deny and/or username-based access). Here's a (redacted) copy of the first few AFP exports I created. I am able to mount (for example) my music and photos library from my laptop in a hotel room many miles away (not an option I recommend implementing normally):




Jails and Plug-ins


I mentioned FreeNAS is very intolerant of customizations you might wish to make that are not available via the GUI. Instead, if you want to run a lab website, or a music server or minecraft server or whatever, you can create what FreeBSD maintainers call a "Jail" or sandbox, which creates a FreeBSD operating system nested within the parent OS. In other words, you can run a computer within the computer, and the computer within cannot interfere with or damage or delete files in the parent computer. Its contents and functionality are jailed or sandboxed. A set of pre-prepared jails are made available as "plug-ins" that can be installed from the FreeNAS GUI, or you can create your own jail, as I did, when I cloned my lab's website. These jails get their own IP addresses, MAC addresses, and so forth, and to the outside world look like stand-alone computers. Importantly, these files reside on the RAID itself, and are not clobbered upon reconfiguration or reboot. Although I don't happen to use this NAS as a conventional music-server NAS, you can see there are several plug-in options that would enable you to do this. (You can then export your library from the main filesystem to the jail and mount it).




Turn off the damn GUI


I think having a GUI login with a root password is idiotic. It is even more idiotic to have to type the root password in via http rather than https (the default, although you can, and should, remedy this). It is even more idiotic to broadcast that GUI login page to the universe, and have no apparent way to firewall it off or restrict access to your LAN or vLAN. WTF? Even my attempts to do this in the webserver configuration files got clobbered almost immediately. One workaround I have is to ssh into the machine and kill the webserver, and then start it back up only when I need it. This is not reasonable, and even this won't survive a reboot. I defined two shell functions to try to make this easier:




I really shouldn't have to do this. Complaining got me nowhere.



Overall Assessment:


Although by no means as simple as setting up an Apple computer running OS X, assembly and set up of the FreeNAS Mini was relatively straightforward, and file exports work as expected. I am even able to do time-machine backups, although I find rsync both faster and more useful. (Time machine creates a monolithic sparse disc image file, so I would suggest not using it for NAS backups, but instead use rsync or the equivalent, especially if you are dealing with a music or photo or movie library.) The FreeNAS GUI and OS, along with the plugin/jail system, gives you the flexibility you need, within the confines imposed by the FreeNAS way of doing things. (The flip-side of the imposed restrictions is they have made administering the NAS fairly idiot-proof, and it spares you the need to learn a lot of zfs jargon and configuration, which looks to me like a fairly steep learning curve. If you have the time and patience and aptitude to DIY, you can save some money, but this "appliance" will save you a lot of grief if you are a time-strapped ADHD-addled borderline computer illiterate like I am.)


Additional Information:


Wikipedia Article on ZFS


iXSystems FreeNAS Mini NAS Review - Tom's Hardware


iXsystems FreeNAS Mini 4-Bay NAS Review




































































Sign in to follow this  


Recommended Comments

Nice write up.. Thanks for doing it.


One question, did you notice if the two included Ethernet ports can be configured individualy using an IP from a different Subnet and if so, do you think the system would allow you to assign one of those Eth ports to the Web Mgmt GUI and the other Eth port as an access port for file level access?


If any of the above was possible, you may be able to use different VLANs on a switch to island off public access to the Web GUI for better security. Of course you would need to put yourself (err.. Your computer) on that island if you needed to manage the system but I suspect that may not be too often.

Share this comment

Link to comment

I only got one of those ports with mine, but I think this should work, since I have several independent IP addresses associated with it, one of which controls access to the NAS (and GUI), and others with various jails including a lab web-server I cloned from a 2009 mac mini. You can create/spoof mac addresses easily, which I think ultimately is what is required. So if one can do it, two should be able to with ease, so what you suggest should still work. I can get in remotely from a bunch of other computers on the LAN, so this shouldn't be a problem. I should probably talk to my IT people, but that is like twisting a salted fork in my eye socket.

Share this comment

Link to comment

Thanks for the info.


Since the single Eth port allows you to assign multiple IP's to it one thing you may be able to request of the IT folks (after removal of the salty fork) and depending on the type of switch being used is that they can configure the port on the switch the NAS is plugged into as a "Trunk" port. If your not familiar with that type of configuration it will allow IT to allow multiple VLAN's access to the NAS, each being virtually separated from each other in terms of access in such a way that the resources tied to an IP using an address of is unable to access resources tied to another IP of


But, one thing I should mention about the above config is that in order for it to work properly the NAS needs to allow you to configure each of the IP's tied to the ETH port with a different gateway address. If it doesn't allow this then none of the above will work.

Share this comment

Link to comment

Many, many thanks for this write-up. I have been pondering this option for quite some time, and your nice post takes me many steps closer.


I have a probably idiotic question: if bitrot happens on a file in your music library on your external SSD, how do you avoid that the corrupt file gets propagated to the backup NAS and replaces the valid file?

Share this comment

Link to comment
That is not an idiotic question at all. The only solution I have is to do manual syncing, detect and reject any unexpected change. I do this using rsync (wrapped in a program I got called [URL="http://www.binarynights.com/forklift/"]ForkLift[/URL]). It first finds all the changes, and then it asks me which ones to propagate.

Share this comment

Link to comment
The other option is I could just network mount the NAS music files on my computer, and proceed that way. This works fine, FWIW, as would a server-side streaming software solution. But for now, I would rather have a local working copy of my library and a remote storage/backup copy of my library. (I also have other backups.)

Share this comment

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now