In a recent letter to the editor, I was contacted by a reader who enjoyed my "Papa's Got a Brand New NAS" article, but wished I had spent more time describing the software I used. When I wrote the article, I decided not to dive into the software too much, because it all was pretty standard for serving files under Linux. But on second thought, if you want to re-create what I made, I imagine it would be nice to know the software side as well, so this article describes the software I use in my home NAS.
My NAS uses the ODROID-XU4 as the main computing platform, and so far, I've found its octo-core ARM CPU and the rest of its resources to be adequate for a home NAS. When I first set it up, I visited the official wiki page for the computer, which provides a number of OS images, including Ubuntu and Android images that you can copy onto a microSD card. Those images are geared more toward desktop use, however, and I wanted a minimal server image. After some searching, I found a minimal image for what was the current Debian stable release at the time (Jessie).
Although this minimal image worked okay for me, I don't necessarily recommend just going with whatever OS some volunteer on a forum creates. Since I first set up the computer, the Armbian project has been released, and it supports a number of standardized OS images for quite a few ARM platforms including the ODROID-XU4. So if you want to follow in my footsteps, you may want to start with the minimal Armbian Debian image.
If you've ever used a Raspberry Pi before, the process of setting up an alternative ARM board shouldn't be too different. Use another computer to write an OS image to a microSD card, boot the ARM board, and at boot, the image will expand to fill the existing filesystem. Then reboot and connect to the network, so you can log in with the default credentials your particular image sets up. Like with Raspbian builds, the first step you should perform with Armbian or any other OS image is to change the default password to something else. Even better, you should consider setting up proper user accounts instead of relying on the default.
The nice thing about these Debian-based ARM images is that you end up with a kernel that works with your hardware, but you also have the wide variety of software that Debian is known for at your disposal. In general, you can treat this custom board like any other Debian server. I've been using Debian servers for years, and many online guides describe how to set up servers under Debian, so it provides a nice base platform for just about anything you'd like to do with the server.
In my case, since I was migrating to this new NAS from an existing 1U Debian server, including just moving over the physical hard drives to a new enclosure, the fact that the distribution was the same meant that as long as I made sure I installed the same packages on this new computer, I could generally just copy over my configuration files wholesale from the old computer. This is one of the big benefits to rolling your own NAS off a standard Linux distribution instead of using some prepackaged NAS image. The prepackaged solution may be easier at first, but if you ever want to migrate off of it to some other OS, it may be difficult, if not impossible, to take advantage of any existing settings. In my situation, even if I had gone with another Linux distribution, I still could have copied over all of my configuration files to the new distribution—in some cases even into the same exact directories.
As I mentioned, since I was moving from an existing 1U NAS server built on top of standard Debian services, setting up my NFS service was a simple matter of installing the nfs-kernel-server Debian package, copying my /etc/exports file over from my old server and restarting the nfs-kernel-server service with:
$ sudo service nfs-kernel-server restart
If you're not familiar with setting up a traditional NFS server under Linux, so many different guides exist that I doubt I'd be adding much to the world of NFS documentation by rehashing it again here. Suffice it to say that it comes down to adding entries into your /etc/exports file that tell the NFS server which directories to share, who to share them with (based on IP) and what restrictions to use. For instance, here's a sample entry I use to share a particular backup archive directory with a particular computer on my network:
/mnt/storage/archive 192.168.0.50(fsid=715,rw)
This line tells the NFS server to share the local /mnt/storage/archive directory with the machine that has the IP 192.168.0.50, to give it read/write privileges and also to assign this particular share with a certain filesystem ID. I've discovered that assigning a unique fsid value to each entry in /etc/exports can help the NFS server identify each filesystem it's exporting explicitly with this ID, in case it can't find a UUID for the filesystem (or if you are exporting multiple directories within the same filesystem). Once I make a change to the /etc/exports file, I like to tell the NFS service to reload the file explicitly with:
$ sudo service nfs-kernel-server reload
NFS has a lot of different and complicated options you can apply to filesystems, and there's a bit of an art to tuning things exactly how you want them to be (especially if you are deciding between version 3 and 4 of the NFS protocol). I typically turn to the exports man page (type man exports in a terminal) for good descriptions of all the options and to see configuration examples.
If you just need to share files with Linux clients, NFS may be all you need. However, if you have other OSes on your network, or clients who don't have good NFS support, you may find it useful to offer Windows-style SMB/CIFS file sharing using Samba as well. Although Samba is configured quite differently from NFS, it's still not too complicated.
First, install the Samba package for your distribution. In my case, that meant:
$ sudo apt install samba
Once the package is installed, you will see that Debian provides a well commented /etc/samba/smb.conf file with ordinary defaults set. I then edited that /etc/samba/smb.conf file and made sure to restrict access to my Samba service to only those IPs I wanted to allow by setting the following options in the networking section of the smb.conf:
hosts allow = 192.168.0.20, 192.168.0.22, 192.168.0.23
interfaces = 127.0.0.1 192.168.0.1/24
bind interfaces only = Yes
These changes restrict Samba access to only a few IPs, and explicitly tell Samba to listen to localhost and a particular interface on the correct IP network.
There are additional ways you can configure access control with Samba, and by default, Debian sets it up so that Samba uses local UNIX accounts. This means you can set up local UNIX accounts on the server, give them a strong password, and then require that users authenticate with the appropriate user name and password before they have access to a file share. Because this is already set up in Debian, all I had left to do was to add some file shares to the end of my smb.conf file using the commented examples as a reference. This example shows how to share the same /mnt/storage/archive directory with Samba instead of NFS:
[archive]
path = /mnt/storage/archive/
revalidate = Yes
writeable = Yes
guest ok = No
force user = greenfly
As with NFS, there are countless guides on how to configure Samba. In addition to those guides, you can do as I do and check out the heavily commented smb.conf or type man smb.conf if you want more specifics on what a particular option does. As with NFS, when you change a setting in smb.conf, you need to reload Samba with:
$ sudo service samba reload
What's refreshing about setting up Linux as a NAS is that file sharing (in particular, replacing Windows SMB file servers in corporate environments) is one of the first major forays Linux made in the enterprise. As a result, as you have seen, setting up Linux to be a NAS is pretty straightforward even without some nice GUI. What's more, since I'm just using a normal Linux distribution instead of some custom NAS-specific OS, I also can use this same server for all sorts of other things, such as a local DNS resolver, local mail relay or any other Linux service I might think of. Plus, down the road if I ever feel a need to upgrade, it should be pretty easy to move these configurations over to brand new hardware.
Kyle Rankin is a Tech Editor and columnist at Linux Journal and the Chief Security Officer at Purism. He is the author of Linux Hardening in Hostile Networks, DevOps Troubleshooting, The Official Ubuntu Server Book, Knoppix Hacks, Knoppix Pocket Reference, Linux Multimedia Hacks and Ubuntu Hacks, and also a contributor to a number of other O'Reilly books. Rankin speaks frequently on security and open-source software including at BsidesLV, O'Reilly Security Conference, OSCON, SCALE, CactusCon, Linux World Expo and Penguicon. You can follow him at @kylerankin.
