A NAS for Homelab Use

Using an ARM SoC as a NAS

One of the many things one can do with a ARM Linux board like a Raspberry Pi, or Beagle Bone is use it to make a simple and highly configurable NAS.

We have a few options for handling files transfers; the most popular of which are sftp, Samba, and rysnc.

Samba is fairly attractive for a couple reasons; there are Samba clients for most OSes, back-up utilities (like Ubuntu’s Déjà Dup) play nicely with it, and set-up is fairly straight-forward. In practice, Samba may be slower than SFTP or Rsync but it’s nearly universal acceptance on a variety of platforms largely makes up for this.

Hardware Set-Up

Configure HDD Mounting

On most ARM boards internal storage (either an SD card or eMMC) is quite slow and has very limited space, making it unsuitable for NAS use. Usually we need to rely on an external on external HDD(s) connected to our host system via a USB to SATA bridge for storage.

Create Mounting Points

Unlike the root file system, external devices will not be automatically mounted at boot so our first step will be to set things up so that our drives mount properly.

First we need to create a mount point for our drives to attach to. According to the Debian File System Hierarchy Standard /mnt/ is the suitable place for temporarily mounted drives, like our external HDD(s).

sudo mkdir /mnt/data

Next we will test to make sure we can mount our drive. In this example we’re assuming our drive is formatted to ext4.

mount -t ext4 /dev/sda1  /mnt/data

We should now be able to read and write files from /mnt/data.

Identify HDDs

Now we need to find what our external HDD is labeled. We will use the lsblk command to view all devices currently visible to our system.

$ sudo lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda           8:0    0   1.8T  0 disk
└─sda1        8:1    0   1.8T  0 part /mnt/data
mmcblk1     179:0    0 117.2G  0 disk
├─mmcblk1p1 179:1    0   128M  0 part /media/boot
└─mmcblk1p2 179:2    0 117.1G  0 part /

Devices under mmcblk1 are partitions on the SD card. If eMMC memory is being used, the boot partition /media/boot and root partition / might show up somewhere. Out external HDDs should show up as sdx which will have one or mode subparitions labeled sdx1, sdx2 etc.

Once we have identified how our devices are labeled, we will need to identify the UUID associated with each device. We cannot use the device labels like /dev/sda to mount drives since these may change each time the OS starts. The UUID, however, is guaranteed to be consistent.

To identity device UUIDs we’ll use the blkid command.

$ sudo blkid
/dev/mmcblk1: PTUUID="3cedfd53" PTTYPE="dos"
/dev/mmcblk1p1: SEC_TYPE="msdos" LABEL="boot" UUID="52AA-6867" TYPE="vfat" PARTUUID="3cedfd53-01"
/dev/mmcblk1p2: LABEL="rootfs" UUID="e139ce78-9841-40fe-8823-96a304a09859" TYPE="ext4" PARTUUID="3cedfd53-02"
/dev/sda1: UUID="a7251e8a-9c50-4371-959c-b89cdac1b266" TYPE="ext4" PARTUUID="6e9882d3-a65e-443d-a808-af6aaf79216d"

In this example we see that our HDD partition labeled /dev/sda1 has the UUID a7251e8a-9c50-4371-959c-b89cdac1b266.

Edit fstab

Now that we have identified our drives we need to edit fstab to make sure our drives mount at start-up.

Adding the following line to /etc/fstab will ensure the drive(s) we identified earlier are mounted whenever our system boots.

UUID=a7251e8a-9c50-4371-959c-b89cdac1b266 /mnt/data ext4 nofail,auto,noatime,rw,user 0 0

We need to take special precautions since we are using external HDDs. If we use fstab settings that would be suitable for permanently mounted drives our system will fail to boot if a drive is not present. Since we are using an external drive through a USB adapter, we want to allow our system to boot normally if a drive is not found. The flags nofail,auto,noatime,rw,user 0 0 allow this to occur.

Samba

We’re going to assume that our ARM board is running some variant of Debian Linux. This should cover most boards, and the instructions should be adaptable to other distros with a bit of effort.

Installation

The official repos for Debian-flavored distros generally have an up-to-date Samba version, so installation is straight-forward.

sudo apt-get install samba

Set Up Samba User

We need to set a Samba-specific password for whatever user we’d like to use to access our shared files. Note this password is not the same as the user’s password. This password will need to be entered when accessing directories shared via Samba.

sudo smbpasswd -a $USER

Set Up Samba Drives

For the sake of example let’s assume we want two separate shared directories; one that stores back-up files, and one that hosts publicly visible files.

In order to make a directory visible to Samba we’ll need to edit /etc/samba/smb.conf and append the following lines.

[backup]
    comment = Sambda drive for automated backups.
    path = /mnt/data/backup
    read only = no
    browsable = yes
    writeable = yes

[public_shared]
    comment = Sambda drive for LAN-viewable files.
    path = /mnt/data/public_shared
    read only = no
    browsable = yes
    writeable = yes

Note that this will create and use the directories /backup and /public_shared on our HDD.

Improving Performance

Be default Samba can be very slow. Fortunately there are a plethora of performance options that can be tweaked to help speed things up.

Adding the following lines under the [global] section of /etc/samba/smb.conf should result in transfer speed performance improvements for most homelab set-ups.

[global]

# Make the go-fast happen
;   socket options = TCP_NODELAY SO_RCVBUF=524288 SO_SNDBUF=524288 IPTOS_LOWDELAY
;   log level = 1
;   read raw = yes
;   write raw = yes
;   max xmit = 65535
;   dead time = 15

We’ll need to restart Samba in order for these changes to take effect.

sudo service smbd restart