Moving A Bunch of Cat Pictures Around a Home Network

Helpful Sharing Tips using Network File System (NFS)

Clap if you are a pet owner!

We have three in our house and love them dearly.

Needless to say there are more than a couple of cat photos on one of our older computers that I wanted to move to network-attached storage. Being a bit cautious I also wanted to have a backup configured to a separate Linux server on our home network for key bits and pieces. This article is useful for setting up a Network File System (NFS) service on one Linux machine on a local network to enable file sharing between various computers.

Configure Server

Install NFS on the Linux machine to be designated as your server:

sudo apt-get install nfs-kernel-server nfs-common

You may also need to install rpcbind if you are working on a older machine.

Open the exports file that was created during the installation of the above packages:

sudo nano /etc/exports

Note: if you are re-installing nfs-kernel-server , you may be prompted to choose anexports file before the re-installation is completed. In this instance you will be asked whether you want to keep the modified file or the version accompanying the package. I recommend keeping the modified version.

The following step assumes you already have a folder ready to share and that your client has a static IP. Use a specific IP vice * to limit whom the share can connect to!

Choose rw if clients need the ability to read and write; otherwise choose ro. Use sync instead of async for data integrity over performance. Use no_root_squash for a simpler setup that does not require user-level access control. Use no_subtree_check for reliability over security.

Add the following lines:

Ensure you specify the correct client_IP!

Hit cntl-o to save then cntl-x to exit the text editor.

Start the NFS Server daemon:

sudo systemctl restart nfs-kernel-server

Verify the share is mounted:

sudo showmount -e server_IP

If your share(s) do not show up in the export list, try re-starting your machine then re-start the NFS daemon. Run the following command to see the status of the NFS server:

sudo service nfs-server status

After confirming the status you may have to Cntl-c to return to the shell, re-start the NFS server to ensure it is up-and-running:

sudo service nfs-server start

Test-Mount Share on Client

Next we are going to configure the client on a separate machine:

sudo apt-get install nfs-common

Create a dummy folder on the client that the shared files will be mounted in:

sudo mkdir -p /nfs/path/to/share

Example:

sudo mkdir -p /nfs/temp

Important: Ensure the local directory is empty as any contents will likely be overwritten once it is mounted!

Perform an initial mount of the NFS share to ensure it works:

sudo mount server_IP:/path/to/share /nfs/path/to/share

Example:

sudo mount 192.168.2.16:/home/my_machine/Documents /nfs/temp

Run showmount to see the mounted share(s) for the given server:

showmount -e server_IP

Example:

showmount -e 192.168.2.16

Troubleshooting on the Client

In some cases you may already have shares mounted. Before unmounting them please ensure you abide by the following:

  1. The unmount command can disrupt a running process, cause data loss OR corrupt open files. Programs accessing target DEVICE/NFS files may throw errors OR may not work properly.
  2. Do not execute umount when inside the mounted path (/nfs/path/to/share) itself. Instead, use pwd command to validate your current directory path (which should not be the mounted path), then use cd .. command to get out of the mounted path.

Proceed once you are sure you can unmount any stale folders in addition to removing them, see this post, this one and this one for details:

sudo umount -f /nfs/path/to/stale/share

sudo rmdir /nfs/path/to/stale/share

Make a new directory on this machine to point to the remote share:

sudo mkdir -p /nfs/path/to/share

Repeat the above steps as many times as necessary to create new local copies of your shared folders.

Configure Client for Startup

Assuming the share was mounted successfully you can proceed with editing the fstab file to configure the share to mount on re-boot. See this tutorial for details on modifing your fstab file.

Important: be sure to create a back-up copy of your fstab before making any changes to it! In addition, be absolutely certain you are making the proper entries as any incorrect changes to this file may result in a system that is un-bootable!

sudo nano /etc/fstab

Add the following to the file to point the NFS share to the local folder:

Ensure you specify the correct server_IP!

After a re-start I noticed it took significantly longer to get to the log-in prompt. There was a spinning wheel on the spash screen that lasted approximately a minute and a half before I was able to log-in! Oh great. Now what? Thankfully I was able to do some troubleshooting by removing the new entry from the fstab file. Re-booting confirmed my suspicions. This post was helpful as it gave me a useful command with which to determine the slowest processes on start-up. Based on this helpful post I was able to run the following command to determine loading times for various services:

systemd-analyze blame

With no new line added to fstab, the load times on my machine were:

6.711s NetworkManager-wait-online.service
 3.961s plymouth-quit-wait.service
...
790us snapd.socket

With the new line added to fstab, one of the load times ballooned to over 1 minute and thirty seconds:

1min 30.151s nfs-z_swapper.mount
6.676s NetworkManager-wait-online.service
4.636s plymouth-quit-wait.service
...
899us snapd.socket

Time to do a bit more reading! I found a couple of pages that talked about network services taking a long time on start-up, including this post as well as this one which helped narrow things further. Adding several settings to my fstab appeared to make the load times much better. Enabling automount meant that NFS was set up at the appropriate time following start-up, as opposed to blindly attempting to configure itself before network services were enabled. The new fstab lines are:

Restarting my machine, the new load times were:

6.708s NetworkManager-wait-online.service
3.966s plymouth-quit-wait.service
...
794us snapd.socket

This was a much better start-up time! Once I logged in and confirmed that the server was up-and-running, I was able to access the shared folder without issue.

If you performed the above steps and restarted your machine, when you issue the below mount command you will likely get an indication that your shares were ignored. This should not be an issue as long as NFS is configured properly in fstab.

Assuming you have not restarted your machine, you will need to mount the shared folder. Attempt to verbose mount the shared folder you configured in your fstab via:

sudo mount -a -v

Ensure you have assigned static IPs to both your Server and Client! These IPs also need to be configured correctly on both machines in export and fstab, otherwise you may get the following error when running mount as verbose:

mount.nfs: mount(2): No route to host

Run showmount to see the mounted share(s) for the given server:

showmount -e Server_IP

Postscript

If all goes well you should be able to navigate to the dummy folder in Nautilus on your client machine and view items from the corresponding folder on the server. Congrats on sharing via NFS!

What are your experiences with sharing files? How have you used NFS in your projects?

Leave a Comment

Required fields are marked *