Deploying an Unraid NFS Server

Guest Blog Author: TORQUEWRENCH

Introduction to NFS

Many of you are already familiar with SMB shares (colloquially known as "Windows network shares" and, among Linux users, as "CIFS shares"). If you are, then you might also wonder if there's a "Linux network share". The answer is that, yes there is: they're called "NFS shares". So what are NFS shares and why should you use them?

Why and When Should I Use NFS Shares?

First of all, NFS shares are a protocol for network file sharing. In fact, that's what "NFS" stands for: "network file system". It's a protocol that allows you to export files across a network so that additional devices can access them.

Maybe you're already using a network share, so when should you choose NFS over SMB? Here are the reasons to consider NFS over SMB/CIFS/"Windows Shares":

• If your clients are also running Linux: As you can imagine, NFS's roots are from Unix, means that it better supports Linux operations. For example, if you're using your NFS share for backups of your Linux machines, do you have symbolic links? There's a good chance you do. NFS offers much better support for those symbolic links than SMB. In contrast, SMB will often give you an error when it comes across symbolic links.
• You do a lot of short/random-read/write-like file operations: NFS tends to perform better than Microsoft's SMB here. As you deal with larger files and get more into sequential IO performance territory, though, the advantage between NFS and SMB blurs. Reference: Windows NFS vs Linux NFS Performance Comparison

When Shouldn't You Use NFS?

Just as important, and probably even more important than knowing when to use a tool, is to also know when not to use it. There are a few things to consider when choosing NFS over SMB:

• Reliability: I know, I'm living dangerously here by suggesting this, and yes, I know, anecdotal evidence is the worst kind of evidence, but in my experience NFS simply isn't as reliable as SMB. If you want to argue semantics, maybe it's more appropriate to say that NFS is much more "finicky" than SMB. NFS "stale file handles" anyone? Obviously this is a gross oversimplification since many large enterprises use NFS just fine. Don't let this scare you off from NFS, it's still reliable and, the majority of the time, the only time I have had a problem with NFS on Unraid is when I have rebooted my server. Additionally, in a future post, I will show you how to not only minimize the "NFS stale file handle" problem through good client mount configuration, but also how to allow your clients to fix the problem on their own automatically so this will be less of an issue.
• You're using a non-Linux device (i.e. Windows): NFS requires some simple additional setup on Windows devices (even that's not as big of a deal as it used to be), but most devices offer support for SMB right out of the box. If you have a mixed-OS network, SMB works very well and you should likely just stick with SMB.

In general, for most home and small business users, I would suggest that your default posture be toward SMB and you should use NFS when you have identified a specific need for it (i.e. you need some Linux-specific functionality like backing up directories with symbolic links).

How to Set Up an Unraid NFS Server

So you've decided to go with NFS on your Unraid server, where do you begin?

Enable NFS

• Start by enabling NFS (Settings > NFS > Enable NFS: Yes):

This starts up the Unraid NFS server. (Don't forget to click apply!)

Set Up NFS Shares

• With NFS enabled, exporting an NFS share is just as easy. Simply navigate to the user share (Shares > [Click on the user share you want to export via NFS] > NFS Security Settings > Export: Yes):

Deploying an Unraid NFS Server Behind a Firewall

Note: This set up is only necessary if you need to access your NFS server across a firewall or access control list (ACL). This step will likely not be necessary for most of you. The only firewall the majority of you will have will be the one on your router and you should never be exposing your NFS server directly to the internet.

This set up is for those of you who, like me, have a separate DMZ network that occasionally needs to access the Unraid server across a firewall (actually an access control list (ACL) in my case).

If you're interested in my network/DMZ ACL set up, you can read more about it here!

Introduction to DMZs, Firewalls, and ACLs

In networks exposed to potential hostiles (think networks with web servers), we typically isolate that network from the rest of the network by way of access control lists (ACLs) or firewalls. This network is known as a DMZ and the typical way of securing it is to set up firewall/ACL rules that explicitly permit only absolutely necessary traffic and block everything else by default.

Let's say we want our DMZ servers to be able to backup certain files to our Unraid server over NFS. In order to do so, we need to explicitly permit this NFS traffic through the ACL to our Unraid server. There's one slight problem though: by default NFS listening ports are randomly assigned. This makes it difficult to explicitly permit traffic through the ACL since we don't know what ports to allow through.

The solution? Set up static NFS server ports on Unraid. This will allow us to have static, predictable ports to permit through our firewall/ACL.

Today's guide will be focused on the essentials to get you up and running with NFS on Unraid so, if you want more details, or just want to know how to figure this kind of stuff out on your own, check out the notes I took when I set this up on my own server.

Set Up Static NFS Server Ports

In order to set up static NFS server ports, you'll first need to make sure you have the User Scripts plugin installed.

Once you have the User Scripts plugin installed, we'll create a new script to define those static ports. Thankfully, Arch on the Unraid forums has already written it for us:
 

#!/bin/bash DEFAULT_RPC="/etc/default/rpc" STATD_PORT=32766 LOCKD_PORT=32768 RC_NFSD="/etc/rc.d/rc.nfsd" MOUNTD_PORT=32767 nfs_config() (     set -euo pipefail sed -i ' s/^#RPC_STATD_PORT=.*/RPC_STATD_PORT='$STATD_PORT'/; s/^#LOCKD_TCP_PORT=.*/LOCKD_TCP_PORT='$LOCKD_PORT'/; s/^#LOCKD_UDP_PORT=.*/LOCKD_UDP_PORT='$LOCKD_PORT'/; ' ${DEFAULT_RPC} sed -i ' s/^\s\{4\}\/usr\/sbin\/rpc\.mountd$/ \/usr\/sbin\/rpc\.mountd -p '$MOUNTD_PORT'/; ' ${RC_NFSD} /etc/rc.d/rc.rpc restart sleep 1 /etc/rc.d/rc.nfsd restart ) nfs_config if [[ $? -ne 0 ]]; then /usr/local/emhttp/webGui/scripts/notify -i warning -s "NFS config failed" fi

Set the script to run at startup of the array:

With the above script, the relevant ports for our Unraid NFS are ports 111, 2049, and 32766-32768. These are the ports that we will need to permit through our access control list.

Permit NFS Ports Through Firewall/ACL

The exact configuration for this will depend on your specific firewall application, but in general the goal here is to permit traffic with a destination of <unraid server IP Address> on ports 111, 2049, and 32766-32768.

Since I'm using ACLs on an L3 managed switch, I use advanced ACL rules. For you visual learners, here's what they look like on my config:

Note that I only have TCP ports permitted. Unraid supports both UDP and TCP, so you can choose to permit both TCP and UDP traffic through your firewall/ACL. I use TCP exclusively for the reasons outlined here.

That's all there is to it! You've now successfully deployed an NFS server on Unraid.

In the next article, I will show you some best practices for mounting an NFS share on Ubuntu (including how to avoid the dreaded NFS "stale file handle" error and how to have your NFS client fix itself should it occur). Stay tuned!