Who needs a custom NAS OS or a web-based GUI when command-line
NAS software is so easy to configure?
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.
The OS
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.
NFS
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.
Samba
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
Conclusion
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.
Resources
- “Papa’s
Got a Brand New NAS” by Kyle Rankin, LJ, September, 2016 - ODROID-XU4
- Official Wiki Page for ODROID-XU4
- Original Minimal Jessie Image for Odroid XU4
- Armbian Images