NFS For Network Engineers

Without beating the ‘old drum’ without reason, sometimes you have to ask does the drum still need beating. Quick 5 minute articles like this one are always worth asking that question. As system administrators make the journey to SREs or ‘Site Reliability Engineers’, network engineers are also on the same trajectory. We might start from an expected Liam Neeson story point (I have some very specific skills etc), but it’s time to become a better Dad and just stop letting them take your daughter. Sometimes we just need to understand why it’s good to understand certain technology and in this case dream boat (I watched ‘The Accountant’ night, what an excellent film), NFS provides us with the ability to write and test code on remote machines for automation use cases. Sure, it’s just a network based file share, but the power of what it allows us to do is far more interesting.

Needless to say, on the same theme as the last blog post, this is another one that is anchored around StackStorm. With our trusty platform, when we create components for a pack like a actions and sensors, it’s important to have access to an IDE or set of tools that assist and accelerate productivity. These could be style tools like flake8, or it could be a fully featured IDE like JetBrains PyCharm which has excellent debugger integration. Sure, I’ve seen it’s possible to create a Linux VM and install the trial versions of tools and then VNC or RDP to it. Not great sometimes fighting that additional graphical layer to access tools. Why bother? Just share the underlying directory and access the files using the host with tools. Install them once, get used to them and use them remotely. Makes much more sense.

A Quick Overview of NFS

Network File Share (NFS) was originally developed in 1984 by Sun Microsystems and is based on RFCs (no different from routing protocol RFCs!) and implemented on top of Open Network Computing Remote Procedure Calls (ONC RPC). Boilerplate explanations put to one-side, it allows us to share a directory from a remote machine over the network using the TCP/IP stack. This remote directory is mounted on a chosen directory mount point. We access it like any other local file system.

The Basics

For the purpose of this blog post, there is a remote host and a local host. The remote host exposes the directory or set of directories to mount by another host. These directories can have different permissions (read/write etc) and different attributes like ‘root squashing’ which ‘prevents root users connected remotely from having root privileges and assigns them the user ID for the user nfsnobody’1.

Instructions

Here’s the meat!

Remote Host

On the host that you wish to expose a directory, follow these steps (which were tried last on a Ubuntu Xenial 16.04 LTS release):

Shell

1

apt install nfs-kernel-server rpcbind

With Ubuntu 16.04, it’s recommended to use ‘apt’ instead of ‘apt-get’. Other changes include systemd by default. I’ve gone on a bit of a journal, sorry, journey, with this recently and I’ve warmed to it. I also realise I had no real reason not to embrace it other than some theoretical gripes which have been satisfied.

Next bit, we need to edit the

Shell

1

/etc/exports

file which is where NFS takes it’s configuration information. I use VIM or VI and you will need to access this as root or with sudo.

Shell

1

2

3

4

5

6

7

8

9

10

# /etc/exports: the access control list for filesystems which may be exported

sync: All file writes are committed to the disk before the write request by the client is completed. Be warned, can lower performance.

no_subtree_check: If only part of a volume is exported, a routine called subtree checking verifies that a file that is requested from the client is in the appropriate part of the volume. If the entire volume is exported, disabling this check will speed up transfers.

resvport: This is a privileged port (i.e. below port number 1024). It helps with non-root users trying to access the remote NFS share.

192.168.16.20:/opt/stackstorm/packs/testpack: This is the remote mount point information.

/home/davidgee/mynewpack: This is the local mount point.

Now we know how to mount, here’s how you unmount.

Shell

1

sudo umount/home/davidgee/mynewpack

If you get resource busy, try exiting the directory from terminal or any applications that have file descriptors open.
Sometimes you have to brute force the exit with the below.

Shell

1

sudo diskutil umount force/home/davidgee/mynewpack

So that’s that. Now you know how to get access to a remote file share using NFS. It’s easy to use and super powerful. Sure, it’s simple stuff, but for network engineers on this journey, this might be a useful trick you haven’t thought about previously!

Attempting to share visions and experience with a wider community for the greater good of our industry in areas such as network device programmability, network automation, DevOps, SDN, NFV, silicon developments and programming/coding education for networkers.
This blog is full of personal opinions that do not represent those of any employer. All thoughts and words are my own even if I occasionally have to eat them.
Currently working as the EMEA Lead in NetDev Professional Services for Brocade based in the UK. This covers automation enablement, software networking, SDN, technology placement, software development, sales and pre-sales.
Always available for a coffee fuelled debate. Nice coffee only please.
I do not make any money from this blog and do not write in exchange for goods or cash. Thoughts are influenced directly from the industry and not by monetary gain.