Introduction

In this article, I’ll document my process of building a home server - or NAS - for local storage, smb drives, backups, processing, git, CD-rips, and other headless computing.

Why a Home Server?

The necessity of a NAS these days can be questioned, given the cheap - or free - availability of cloud storage. However, getting into a dependency with an external vendor poses significant security risk for individuals that do not enjoy the same benefits a corporate account with big bills might receive, notably -

Changes in storage tiers and costs (see Flickr limiting free user’s storage tier to 1,000 photos, from previously 1TB or Microsoft dropping unlimited storage for OneDrive - especially fun if you already have gigabytes, if not terabytes, stored there)

Upload capacity with broadband connections (except for Google Fiber, no American ISP offers symmetric up/down links) - uploading my CD vinyl collection, even ripped as compressed MP3s @ ~70GB, would take me a easily half a day - (not to mention my 2TB Steam collection) and that is only a fraction of our available local storage)

And hence, high-speed backups from all local devices, such as PCs, Macs, Routers, etc.

Privacy concerns - while you can, naturally, uploaded encrypted files, you lose the benefit of automatic syncing in most cases

Flexibility to run additional services such as a pi-hole (DNS ad blocker), monitoring software, local build server and git repositories, or VPN services

Service outages on cloud services or your local internet

However, for the record - the server where you reading this article on does get backed up to AWS S3 via an encrypted duplicity backup (which is neither free nor user-friendly). There is no “one size fits all” solution.

As a preliminary note: Do not copy paste any of the commands without making sure all parameters match your system’s configuration!

Hardware

CPU : AMD - Ryzen 3 2200G 3.5 GHz Quad-Core Processor

: AMD - Ryzen 3 2200G 3.5 GHz Quad-Core Processor Motherboard : Gigabyte - GA-AB350-GAMING 3 ATX AM4 Motherboard

: Gigabyte - GA-AB350-GAMING 3 ATX AM4 Motherboard Memory : 2x Corsair - Vengeance LPX 8 GB (1 x 8 GB) DDR4-2400 Memory

: 2x Corsair - Vengeance LPX 8 GB (1 x 8 GB) DDR4-2400 Memory Storage : Western Digital - Green 240 GB M.2-2280 Solid State Drive

: Western Digital - Green 240 GB M.2-2280 Solid State Drive Storage : 2x Western Digital - Red 6 TB 3.5” 5400RPM Internal Hard Drive

: 2x Western Digital - Red 6 TB 3.5” 5400RPM Internal Hard Drive Storage : 2x Western Digital - Red 3 TB 3.5” 5400RPM Internal Hard Drive

: 2x Western Digital - Red 3 TB 3.5” 5400RPM Internal Hard Drive Power Supply : EVGA - SuperNOVA G3 550 W 80+ Gold Certified Fully-Modular ATX Power Supply

: EVGA - SuperNOVA G3 550 W 80+ Gold Certified Fully-Modular ATX Power Supply Case Fan : 2x Noctua - NF-F12 PWM 54.97 CFM 120mm Fan

: 2x Noctua - NF-F12 PWM 54.97 CFM 120mm Fan Case Fan : 2x Noctua - NF-R8 redux-1800 PWM 31.37 CFM 80mm Fan

: 2x Noctua - NF-R8 redux-1800 PWM 31.37 CFM 80mm Fan Case: Rosewill RSV-R4000, 4U Rackmount Server Case / Server Chassis, 8

The total price (as of 2019-04-06) is roughly $1,200 USD.

I’ve also added some existing hardware, like 2x 1TB Samsung HDDs and a PCI-to-SATA extension card.

Preparation

Make sure you have the follow tools available -

A laptop or desktop running any GNU/Linux or MacOS (Windows instructions differ - you will need an ssh client like putty or MobaXTerm as well as unetbootin to burn the ISO)

An ethernet cable

A keyboard

A screwdriver

A USB thumb drive

All server hardware

(Optional) Small LCD screen and spare keyboard to access the drive if SSH won’t work for some reason

First, we’ll get ourselves a Debian 9 ISO and burn it to a USB Thumb Drive. Other operating systems are available - I like Debian for it’s stability and easy maintenance and already run several Debian boxes.

1 2 3 4 cd ~/Downloads wget https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-9.8.0-amd64-netinst.iso sudo fdisk -l | grep -B 2 -A 15 "Flash" sudo dd bs = 4M if = debian-9.8.0-amd64-netinst.iso of = /dev/sdf

1 2 3 4 ➜ Downloads sudo dd bs = 4M if = debian-9.8.0-amd64-netinst.iso of = /dev/sdf 73+0 records in 73+0 records out 306184192 bytes ( 306 MB, 292 MiB ) copied, 11.6768 s, 26.2 MB/s

Hardware setup

This step is fairly straightforward. Assemble the hardware, plug in it, and make sure it posts. In the process, make sure the room you are using to assemble the system looks like a tornado went through it.

Cable management optional

Install Operating System

With your hardware connected to a screen, keyboard, and ethernet, it’s time to install the OS. Insert the flash drive, boot into it on the server hardware, and install Debian. I used my M.2 SSD with separate /home and /tmp partitions and enabled disk encryption with LUKS.

Software setup

Once the installation is completed, we can set up the software.

First, we need to configure our network. Take a backup of the configuration and edit the file with vi:

1 2 sudo cp /etc/network/interfaces /etc/network/interfaces.bak sudo vi /etc/network/interfaces

Something like this should be the content for your interface file:

1 2 3 4 5 6 7 8 9 10 11 12 13 auto lo iface lo inet loopback iface eth0 inet static address 192.168.1.130 netmask 255.255.255.0 network 192.168.1.0 broadcast 192.168.1.255 gateway 192.168.1.1 sudo vi /etc/resolv.conf nameserver 192.168.1.176

Keep in mind that your IP configuration might be different. Since I am running a pi-hole on IP 192.168.1.176, my DNS configuration refers to that server. For your environment, you probably want to go with 1.1.1.1 and 1.0.0.1 as DNS tuple. You can always check on your other devices via $ ifconfig or similar commands.

Next, we’ll configure the hostname and host resolution and restart the network service.

My hostname is “bigiron”, which might or might not be a Marty Robbins and Fallout reference. You can choose whatever you like.

1 2 3 sudo echo bigiron > /etc/hostname sudo vi /etc/hosts

1 2 3 # Example 127.0.0.1 localhost 192.168.1.130 bigiron

Before doing anything, we’ll restart the network service and test the connection. Make sure you can reach google.com.

1 2 3 sudo service networking restart if [[ $( hostname ) == "bigiron" ]] ; then echo "success" ; else echo "failed" ; fi ping google.com

Then, we’ll update our packages and install all required software:

1 2 3 4 5 6 7 8 9 10 11 12 sudo apt-get update sudo apt-get upgrade sudo apt-get install zsh \ vim \ git \ openssh-server \ parted \ wget \ curl \ cryptsetup \ mdadm \ libcups2 samba samba-common cups

The software we need to install here is fairly standard - zsh is going to be our shell, vim serves as editor, git is used to handle repositories, openssh-server is used for SSH connection, wget & curl are used for downloads and network tests, cryptsetup and mdadm are used for disk encryption and RAID arrays, and the samba dependencies are for file shares.

Disclaimer: There is a known vulnerability for wget, CVE-2019-5953.

There is a known vulnerability for wget, CVE-2019-5953

Next, we’ll configure oh-my-zsh, a neat little wrapper around zsh that is my default shell on all *NIX boxes.

1 sh -c " $( wget https://raw.githubusercontent.com/robbyrussell/oh-my-zsh/master/tools/install.sh -O - ) "

Now, we need to configure ssh to use the system remotely from our other machine.

1 sudo vim /etc/ssh/sshd_config

Add the following content (using your user name) and restart ssh. Please make sure you configure public/private key authentication in due time.

1 2 3 4 5 6 7 8 9 10 11 12 13 # Users AllowUsers christian # Logging SyslogFacility AUTH LogLevel INFO # Authentication: LoginGraceTime 2m PermitRootLogin no StrictModes yes MaxAuthTries 6 MaxSessions 10 service ssh restart

Hard drive setup

Congratulations, your system is now operational. Granted - it doesn’t do anything. But we’ll change that in a spiffy!

You can now connect to your system using SSH (which is what we are going to do).

One of our most command commands is going to be the following:

1 2 sudo fdisk -l service ssh restart

1 2 3 4 5 6 7 8 9 10 Disk /dev/sdh: 5.5 TiB, 6001175126016 bytes, 11721045168 sectors Units: sectors of 1 \* 512 = 512 bytes Sector size ( logical/physical ) : 512 bytes / 4096 bytes I/O size ( minimum/optimal ) : 4096 bytes / 4096 bytes Disklabel type: gpt Disk identifier: 46AAB764-3004-481A-AA2D-5D751D996AC1 Device Start End Sectors Size Type /dev/sdh1 2048 11721045134 11721043087 5.5T Linux filesystem service ssh restart

This shows us the physical disks in the system, as well as their partitions. As I’ve mentioned before - do not simply copy paste these commands. Otherwise you will risk losing data and messing up your system.

Make sure you always take note of your disks’ identifiers (e.g., /dev/sda) and UUIDs.

Do not copy paste any of the commands without making sure all parameters match your system’s configuration

With that out of the way, we will need to add partitions to our first set of hard drives and format them. This will delete all data on the disks.

1 2 3 4 5 6 7 sudo parted /dev/sdb ( parted ) mklabel gpt Warning: The existing disk label on /dev/sdc will be destroyed and all data on this disk will be lost. Do you want to continue ? Yes/No? y ( parted ) mkpart primary ext 0% 100% ( parted ) exit sudo mke2fs -t ext4 /dev/sdb2

Once that is done, we need to create our RAID-1 array as such. We use RAID-1 to protect ourselves against disk failures. A RAID-1 array protects against drive failures - it is not a backup!

A RAID-1 array protects against drive failures - it is not a backup!

1 mdadm --create --verbose --level = 1 --metadata = 1.2 --raid-devices = 2 /dev/md/6TB /dev/sdb1 /dev/sdc1

You can check the configuration as well as the sync status of your RAID-1 array as such:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 ➜ ~ sudo mdadm --detail /dev/md127 /dev/md127: Version : 1.2 Creation Time : Sat Apr 6 18:27:22 2019 Raid Level : raid1 Array Size : 5860390464 ( 5588.90 GiB 6001.04 GB ) Used Dev Size : 5860390464 ( 5588.90 GiB 6001.04 GB ) Raid Devices : 2 Total Devices : 2 Persistence : Superblock is persistent Intent Bitmap : Internal Update Time : Sat Apr 6 18:27:22 2019 State : clean, resyncing Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0 Resync Status : 0% complete Name : bigiron:6TB ( local to host bigiron ) UUID : ffafd947:3c116230:a1e40521:332156c7 Events : 1 Number Major Minor RaidDevice State 0 8 17 0 active sync /dev/sdb1 1 8 33 1 active sync /dev/sdc1

Encryption with LUKS

Then, we’ll add LUKS encryption to the array:

1 2 3 4 5 sudo cryptsetup luksFormat /dev/md127 sudo cryptsetup luksOpen /dev/md127 6TB \_ LUKS sudo mkfs.ext4 /dev/mapper/6TB \_ LUKS sudo mkdir /mnt/6TB sudo mount /dev/mapper/6TB \_ LUKS /mnt/6TB

Once that is done, we’ll add a key file to make sure we don’t need to punch in the password every time.

This this step, I am using an external USB thumb drive and hence am mounting /dev/sdd1 to /mnt/usb. You can also keep the key file on the system, but that would invalidate the point of having an encrypted disk in the case of theft.

1 2 sudo mount /dev/sdc1 /mnt/usb sudo dd bs = 512 count = 4 if = /dev/random of = /mnt/usb/keyfile iflag = fullblock

1 2 3 4+0 records in 4+0 records out 2048 bytes ( 2.0 kB, 2.0 KiB ) copied, 891.521 s, 0.0 kB/s

1 2 sudo chmod 600 /mnt/usb/keyfile sudo cryptsetup luksAddKey /dev/md127 /mnt/usb/keyfile --key-slot 1

Wonderful. Now, let’s make sure that the thumb drive containing the key gets mounted on boot by editing /etc/fstab

1 2 3 4 5 sudo fdisk -l sudo blkid /dev/sdc1 | awk -F '"' '{print $2}' sudo vim /etc/fstab UUID = b796c692-2ba5-49cf-a45d-dbd62228dd98 /mnt/usb auto nosuid,nodev,nofail 0 0

Then, we need to add the actual encrypted disk to /etc/fstab as well as /etc/crypttab.

1 2 3 4 5 6 7 8 9 # Get UUID sudo cryptsetup luksDump /dev/md127 | grep "UUID" # Edit /etc/crypttab sudo mdadm --detail /dev/md127 sudo vim /etc/crypttab # 6TB_LUKS UUID=e4cd8646-375d-4d84-886c-ba80b31698ad /mnt/usb/keyfile luks sudo vim /etc/fstab # /dev/mapper/6TB_LUKS /mnt/6TB ext4 defaults 0 2

In my case, I have only enabled this for the data drives, not for the boot drive. This is a matter of personal preference - I have a small 7” LCD on the 19” rack, including a keyboard, and simply punch in the LUKS key code on reboot. This won’t work you are not home, but leaving the thumb-drive in the system while you are away won’t help theft prevention of data. Feel free to send me your own best practices.

With all that done, you can test the setup by mounting everything in /etc/fstab by running:

1 sudo mount -a

Repeat this process for every RAID array in the system. In my case, that would be 2.

Furthermore, to persist names for existing arrays, follow these steps:

1 2 3 4 sudo mdadm --stop /dev/md126 sudo mdadm --assemble /dev/md3 --name = 3TB --update = name /dev/sda /dev/sdb sudo mdadm -Db /dev/md3 >> /etc/mdadm/mdadm.conf sudo update-initramfs -u

On a side-node - if you have existing drives, for instance from your desktop PC, make sure to back up all your data to a different disk, as setting this up will delete all data. You can do this as such:

1 sudo rsync --partial -T /mnt/6TB/tmp -azh /mnt/3TB/ /mnt/6TB/ --exclude = ".Trash-1000" --progress

On a related note, since I transferred an existing RAID-1 array, I had some massive drive issues that resulted in odd behavior (like timeouts on the READ() call in the kernel, as followed by strace - please don’t ask me why) - if you want to debug issues like these, the following commands might come in handy.

You can see the files being accessed by commands like rsync or cp through /proc with the specific PID of a process:

1 2 ps aux | grep rsync watch sudo ls -l /proc/1446/fd

1 2 3 4 5 6 7 8 9 Every 2.0s: sudo ls -l /proc/1446/fd bigiron: Thu Apr 11 17:36:55 2019 total 0 lrwx------ 1 root root 64 Apr 11 17:03 0 -> /dev/tty1 lrwx------ 1 root root 64 Apr 11 17:03 1 -> /dev/tty1 lrwx------ 1 root root 64 Apr 11 17:03 2 -> /dev/tty1 lr-x------ 1 root root 64 Apr 11 17:24 3 -> /mnt/3TB/memes/2019/04/memes_if_i_die_before_game_of_thrones_comes_out/928_meme.jpg lrwx------ 1 root root 64 Apr 11 17:03 4 -> socket: [ 18863 ] lrwx------ 1 root root 64 Apr 11 17:03 5 -> socket: [ 18864 ]

Also, using strace, you can debug very odd, low-level issues like mine:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 strace cp broken.txt broken2.txt ecve ( "/bin/cp" , [ "cp" , "broken.txt" , "broken2.txt" ] , [ /* 24 vars */ ]) = 0 brk ( NULL ) = 0x55adfb96b000 access ( "/etc/ld.so.nohwcap" , F_OK ) = -1 ENOENT ( No such file or directory ) access ( "/etc/ld.so.preload" , R_OK ) = -1 ENOENT ( No such file or directory ) open ( "/etc/ld.so.cache" , O_RDONLY|O_CLOEXEC ) = 3 fstat ( 3, { st_mode = S_IFREG|0644, st_size = 35999, ... }) = 0 mmap ( NULL, 35999, PROT_READ, MAP_PRIVATE, 3, 0 ) = 0x7f82ba539000 close ( 3 ) = 0 access ( "/etc/ld.so.nohwcap" , F_OK ) = -1 ENOENT ( No such file or directory ) open ( "/lib/x86_64-linux-gnu/libselinux.so.1" , O_RDONLY|O_CLOEXEC ) = 3 read ( 3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0000k\0\0\0\0\0\0" ..., 832 ) = 832 fstat ( 3, { st_mode = S_IFREG|0644, st_size = 155400, ... }) = 0 mmap ( NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0 ) = 0x7f82ba537000 mmap ( NULL, 2259664, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0 ) = 0x7f82ba0f7000 mprotect ( 0x7f82ba11c000, 2093056, PROT_NONE ) = 0 mmap ( 0x7f82ba31b000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x24000 ) = 0x7f82ba31b000 mmap ( 0x7f82ba31d000, 6864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0 ) = 0x7f82ba31d000 close ( 3 ) = 0 ...

Network shares

Now, we’ll set up network shares with samba. This will allow all devices in the network to access shares on the server.

All we need to do is add a new user for samba (as smb users are separate from the host system’s users), backup our samba configuration and add shares, including valid users as such:

1 2 3 4 sudo smbpasswd -a christian sudo cp /etc/samba/smb.conf /etc/samba/smb.conf.bak sudo vim /etc/samba/smb.conf sudo service smbd restart

And:

1 2 3 4 5 6 7 8 9 10 11 [global] server min protocol = NT1 ; server max protocol = SMB3 ... [6TB] path = /mnt/6TB browseable = yes writeable = yes valid users = christian

Test your setup by mounting the smb drive on a different computer. The below example is for Arch Linux. Replace the username and password accordingly.

1 2 sudo pacman -S smbclient sudo mkdir -p /mnt/shares/6TB-Server

Add a secured, read-only file for root to store your passwords:

1 2 3 4 5 sudo mkdir -p /etc/samba/credentials/ sudo vim /etc/samba/credentials/share sudo chown root:root /etc/samba/credentials sudo chmod 700 /etc/samba/credentials sudo chmod 600 /etc/samba/credentials/share

Ini:

1 2 username = myuser password = mypass

And try connecting:

1 sudo mount -t cifs //192.168.1.213/6TB /mnt/shares/6TB-Server -o credentials = /etc/samba/credentials/share

Mounted drive on Arch Linux with KDE

I hate to admit it, but Windows makes it a bit easier. :) Please see below for the steps (for Windows 10 Pro):

Right-click on “This PC” and “Map network drive”

Map Drive

Mapped Drive (the size might be off - this happened due to invalid permissions)

Backups

Last but not least, we’ll enable automatic updates for a GNU/Linux machine.

This is done with an encrypted duplicity backup. Make sure you store your GPG keys somewhere secure, like an encrypted USB drive.

1 2 3 4 5 6 7 8 sudo su apt-get install duplicity gpg gpg --gen-key gpg --list-keys # Take the GPG_KEY from here touch /root/backup_arch.sh chmod +x /root/backup_arch.sh vim /root/backup_arch.sh

Script:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 #!/bin/sh export GPG_KEY = YOUR_KEY_HERE if [ " ${ EUID } " -ne 0 ] ; then echo "You're not root" exit fi s # Check if external drive is mounted SHARE = /mnt/shares/6TB-Server if [[ -z $( mount -t cifs | grep " ${ SHARE } " ) ]] ; then echo "Disk not connected, aborting" exit 1 else echo "Disk available, continuing..." fi #MOUNTPONT=$(findmnt -rn -S UUID="${UUID}") if [ -z " ${ MOUNTPONT } " ] ; then mount -t cifs //192.168.1.213/6TB /mnt/shares/6TB-Server -o credentials = /etc/samba/credentials/share RET = $? fi # Check success if [ $RET -ne 0 ] ; then echo "Mount failed!" exit 1 fi # Delete any older than 1 month #duplicity remove-older-than 7D --force --encrypt-key=9CE17035 --sign-key=9CE17035 file:///mnt/5TB/arch_backup/ # Make the regular backup # Will be a full backup if past the older-than parameter duplicity --full-if-older-than 7D --encrypt-key = ${ GPG_KEY } --sign-key = ${ GPG_KEY } -exclude = /proc --exclude = /lost+found --exclude = /backups --exclude = /mnt --exclude = /sys --exclude = /opt/virtual / file:///mnt/shares/6TB-Server/backups/arch/ export GPG_KEY =

You can know schedule this with cron (the below command will run it every day at midnight):

1 2 crontab -e 0 0 * * * /root/backup_arch.sh > /var/log/backup/ $( date --iso ) _backup.log

Further Steps

There are a lot more steps that you can take to make your server fully operational.

Here are some ideas -

Plex or other home media shares to access your media on e.g. your AppleTV

Running your own git server

Running your own build server

Running nextCloud

Enabling wireguard or other VPNs for external access

Enable rotating logs and log-backups

Enable a duplicity backup pipeline to an external hard drive to safeguard against fires, electrical issues, or theft (a RAID-1 array protects against drive failures - it is not a backup!)

Furthermore, I strongly recommend setting up the following security best practices:

Enable ssh login via public/private keys only

Enable apparmor to restrict service account’s permissions (this can be very, very time intensive and may break existing software)

Enable proper iptable rules

Secure your outgoing and incoming ports on your router and physical network (switches)

Secure your samba configuration

Conclusion

Running a home server can be taxing on free time and costs, but does allow for some powerful computing capabilities in your own home. Following similar steps like the ones highlighted above allow you to properly own your data, have control over your backups, and be independent of Cloud providers.

It is also a wonderful learning experience for everyone who has interest in GNU/Linux and Sysadmin tasks, but doesn’t want to be limited to small computing power (Raspberry Pi) or purely on fun projects (like running a barebones Debian on an old laptop).

While a regular external hard drive for Backups and Cloud services for anything else might be plenty for most people, if you have the energy to be your own admin, I can highly recommend putting a 19” rack in your house.

Disclaimer: In case you are married, you might need couples counseling after putting 100lbs of solid steel and a plethora of ethernet cables in your office.

Final Setup