{"id":1993,"date":"2018-10-30T17:02:15","date_gmt":"2018-10-30T17:02:15","guid":{"rendered":"https:\/\/www.appservgrid.com\/paw92\/?p=1993"},"modified":"2018-10-31T03:47:19","modified_gmt":"2018-10-31T03:47:19","slug":"papas-got-a-brand-new-nas-the-software","status":"publish","type":"post","link":"https:\/\/www.appservgrid.com\/paw92\/index.php\/2018\/10\/30\/papas-got-a-brand-new-nas-the-software\/","title":{"rendered":"Papa’s Got a Brand New NAS: the Software"},"content":{"rendered":"

Who needs a custom NAS OS or a web-based GUI when command-line
\nNAS software is so easy to configure?<\/em><\/p>\n

In a recent letter to the editor, I was contacted by a reader who
\nenjoyed my “Papa’s
\nGot a Brand New NAS”<\/a> article, but wished I had
\nspent more time describing the software I used. When I
\nwrote the article, I decided not to dive into the software too much,
\nbecause it all was pretty standard for serving files under Linux.
\nBut on second thought, if you want to re-create what I made, I
\nimagine it would be nice to know the software side as well, so this article
\ndescribes the software I use in my home NAS.<\/p>\n

The OS<\/h3>\n

My NAS uses the ODROID-XU4<\/a> as the main computing platform, and so
\nfar, I’ve found its octo-core ARM CPU and the rest of its resources
\nto be adequate for a home NAS. When I first set it up, I visited the
\nofficial wiki
\npage<\/a> for the computer, which provides a number of OS
\nimages, including Ubuntu and Android images that you can copy onto a
\nmicroSD card. Those images are geared more toward desktop use,
\nhowever, and I wanted a minimal server image. After some searching,
\nI found a minimal image for what was the current Debian stable
\nrelease at the time (Jessie)<\/a>.<\/p>\n

Although this minimal image worked okay for me, I don’t necessarily
\nrecommend just going with whatever OS some volunteer on a forum
\ncreates. Since I first set up the computer, the Armbian project has
\nbeen released, and it supports a number of standardized OS images for quite
\na few ARM platforms including the ODROID-XU4. So if you
\nwant to follow in my footsteps, you may want to start with the minimal Armbian
\nDebian image<\/a>.<\/p>\n

If you’ve ever used a Raspberry Pi before, the process of setting
\nup an alternative ARM board shouldn’t be too different. Use another
\ncomputer to write an OS image to a microSD card, boot the ARM board,
\nand at boot, the image will expand to fill the existing filesystem.
\nThen reboot and connect to the network, so you can log in with the default
\ncredentials your particular image sets up. Like with Raspbian builds,
\nthe first step you should perform with Armbian or any other OS image
\nis to change the default password to something else. Even better,
\nyou should consider setting up proper user accounts instead of
\nrelying on the default.<\/p>\n

The nice thing about these Debian-based ARM images is that you end
\nup with a kernel that works with your hardware, but you also have
\nthe wide variety of software that Debian is known for at your
\ndisposal. In general, you can treat this custom board like any other
\nDebian server. I’ve been using Debian servers for years, and
\nmany online guides describe how to set up servers under Debian, so
\nit provides a nice base platform for just about anything you’d
\nlike to do with the server.<\/p>\n

In my case, since I was migrating to this new NAS from an existing
\n1U Debian server, including just moving over the physical hard drives
\nto a new enclosure, the fact that the distribution was the same
\nmeant that as long as I made sure I installed the same packages on
\nthis new computer, I could generally just copy over my configuration
\nfiles wholesale from the old computer. This is one of the big
\nbenefits to rolling your own NAS off a standard Linux distribution
\ninstead of using some prepackaged NAS image. The prepackaged solution
\nmay be easier at first, but if you ever want to migrate off of it
\nto some other OS, it may be difficult, if not impossible, to take
\nadvantage of any existing settings. In my situation, even if I had gone
\nwith another Linux distribution, I still could have copied over all
\nof my configuration files to the new distribution\u2014in some cases
\neven into the same exact directories.<\/p>\n

NFS<\/h3>\n

As I mentioned, since I was moving from an existing 1U NAS server
\nbuilt on top of standard Debian services, setting up my NFS service
\nwas a simple matter of installing the nfs-kernel-server Debian
\npackage, copying my \/etc\/exports file over from my old server and
\nrestarting the nfs-kernel-server service with:<\/p>\n

$ sudo service nfs-kernel-server restart<\/p>\n

If you’re not familiar with setting up a traditional NFS server
\nunder Linux, so many different guides exist that I
\ndoubt I’d be adding much to the world of NFS documentation
\nby rehashing it again here. Suffice it to say that it comes down to
\nadding entries into your \/etc\/exports file that tell the NFS server
\nwhich directories to share, who to share them with (based on IP)
\nand what restrictions to use. For instance, here’s a sample entry I
\nuse to share a particular backup archive directory with a particular
\ncomputer on my network:<\/p>\n

\/mnt\/storage\/archive 192.168.0.50(fsid=715,rw)<\/p>\n

This line tells the NFS server to share the local \/mnt\/storage\/archive
\ndirectory with the machine that has the IP 192.168.0.50, to give
\nit read\/write privileges and also to assign this particular share
\nwith a certain filesystem ID. I’ve discovered that assigning a
\nunique fsid value to each entry in \/etc\/exports can help the NFS
\nserver identify each filesystem it’s exporting explicitly with
\nthis ID, in case it can’t find a UUID for the filesystem (or if you
\nare exporting multiple directories within the same filesystem).
\nOnce I make a change to the \/etc\/exports file, I like to tell the
\nNFS service to reload the file explicitly with:<\/p>\n

$ sudo service nfs-kernel-server reload<\/p>\n

NFS has a lot of different and complicated options you can apply
\nto filesystems, and there’s a bit of an art to tuning things exactly
\nhow you want them to be (especially if you are deciding between
\nversion 3 and 4 of the NFS protocol). I typically turn to the exports
\nman page (type man exports in a terminal) for good descriptions
\nof all the options and to see configuration examples.<\/p>\n

Samba<\/h3>\n

If you just need to share files with Linux clients, NFS may be all
\nyou need. However, if you have other OSes on your network, or clients
\nwho don’t have good NFS support, you may find it useful to
\noffer Windows-style SMB\/CIFS file sharing using Samba as well. Although Samba
\nis configured quite differently from NFS, it’s still not too
\ncomplicated.<\/p>\n

First, install the Samba package for your distribution. In my case,
\nthat meant:<\/p>\n

$ sudo apt install samba<\/p>\n

Once the package is installed, you will see that Debian provides a
\nwell commented \/etc\/samba\/smb.conf file with ordinary defaults set.
\nI then edited that \/etc\/samba\/smb.conf file and made sure to restrict
\naccess to my Samba service to only those IPs I wanted to allow by
\nsetting the following options in the networking section of the
\nsmb.conf:<\/p>\n

hosts allow = 192.168.0.20, 192.168.0.22, 192.168.0.23
\ninterfaces = 127.0.0.1 192.168.0.1\/24
\nbind interfaces only = Yes<\/p>\n

These changes restrict Samba access to only a few IPs, and explicitly
\ntell Samba to listen to localhost and a particular interface on the
\ncorrect IP network.<\/p>\n

There are additional ways you can configure access control with
\nSamba, and by default, Debian sets it up so that Samba uses local
\nUNIX accounts. This means you can set up local UNIX accounts on the
\nserver, give them a strong password, and then require that users
\nauthenticate with the appropriate user name and password before they
\nhave access to a file share. Because this is already set up in Debian,
\nall I had left to do was to add some file shares to the end of my
\nsmb.conf file using the commented examples as a reference. This
\nexample shows how to share the same \/mnt\/storage\/archive directory
\nwith Samba instead of NFS:<\/p>\n

[archive]
\npath = \/mnt\/storage\/archive\/
\nrevalidate = Yes
\nwriteable = Yes
\nguest ok = No
\nforce user = greenfly<\/p>\n

As with NFS, there are countless guides on how to configure Samba.
\nIn addition to those guides, you can do as I do and check out the
\nheavily commented smb.conf or type man smb.conf if you want more
\nspecifics on what a particular option does. As with NFS, when you
\nchange a setting in smb.conf, you need to reload Samba with:<\/p>\n

$ sudo service samba reload<\/p>\n

Conclusion<\/h3>\n

What’s refreshing about setting up Linux as a NAS is that file
\nsharing (in particular, replacing Windows SMB file servers in corporate
\nenvironments) is one of the first major forays Linux made in the
\nenterprise. As a result, as you have seen, setting up Linux to be
\na NAS is pretty straightforward even without some nice GUI. What’s
\nmore, since I’m just using a normal Linux distribution instead of
\nsome custom NAS-specific OS, I also can use this same server for
\nall sorts of other things, such as a local DNS resolver, local mail
\nrelay or any other Linux service I might think of. Plus, down the
\nroad if I ever feel a need to upgrade, it should be pretty easy to
\nmove these configurations over to brand new hardware.<\/p>\n

Resources<\/h3>\n