Status: active
To Action From
-- ------ ----
OpenSSH ALLOW Anywhere
OpenSSH (v6) ALLOW Anywhere (v6)
On your system, only SSH traffic is being allowed through, so you’ll need to add a rule for NFS traffic.
With many applications, you can use sudo ufw app list
and enable them by name, but nfs
is not one of those. However, because ufw
also checks /etc/services
for the port and protocol of a service, you can still add NFS by name. Best practice recommends that you enable the most restrictive rule that will still allow the traffic you want to permit, so rather than enabling traffic from just anywhere, you’ll be specific.
Use the following command to open port 2049
on the host, being sure to substitute your client public IP address:
- sudo ufw allow from client_ip to any port nfs
You can verify the change by typing:
- sudo ufw status
You should see traffic allowed from port 2049
in the output:
Status: active
To Action From
-- ------ ----
OpenSSH ALLOW Anywhere
2049 ALLOW client_ip
OpenSSH (v6) ALLOW Anywhere (v6)
This confirms that UFW will only allow NFS traffic on port 2049
from your client machine.
Step 5 — Creating Mount Points and Mounting Directories on the Client
Now that the host server is configured and serving its shares, you’ll prepare your client.
In order to make the remote shares available on the client, you need to mount the directories on the host that you want to share to empty directories on the client.
Note: If there are files and directories in your mount point, they will become hidden as soon as you mount the NFS share. To avoid the loss of important files, be sure that if you mount in a directory that already exists that the directory is empty.
You’ll create two directories for your mounts on the client machine:
- sudo mkdir -p /nfs/general
- sudo mkdir -p /nfs/home
Now that you have a location to put the remote shares and you’ve opened the firewall, you can mount the shares using the IP address of your host server:
- sudo mount host_ip:/var/nfs/general /nfs/general
- sudo mount host_ip:/home /nfs/home
These commands will mount the shares from the host computer onto the client machine. You can double-check that they mounted successfully in several ways. You can check this with a mount
or findmnt
command, but the df -h
command, which lists available disk space, provides a more readable output:
- df -h
Filesystem Size Used Avail Use% Mounted on
tmpfs 198M 972K 197M 1% /run
/dev/vda1 50G 3.5G 47G 7% /
tmpfs 989M 0 989M 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
/dev/vda15 105M 5.3M 100M 5% /boot/efi
tmpfs 198M 4.0K 198M 1% /run/user/1000
10.124.0.3:/var/nfs/general 25G 5.9G 19G 24% /nfs/general
10.124.0.3:/home 25G 5.9G 19G 24% /nfs/home
Both of the shares you mounted appear at the bottom. Because they were mounted from the same file system, they show the same disk usage. To see how much space is actually being used under each mount point, use the disk usage command du
and the path of the mount. The -s
flag provides a summary of usage rather than displaying the usage for every file. The -h
prints human-readable output.
For example:
- du -sh /nfs/home
36K /nfs/home
This shows us that the contents of the entire home directory is using only 36K of the available space.
Step 6 — Testing NFS Access
Next, test access to the shares by writing something to each of them.
Example 1: The General Purpose Share
First, write a test file to the /var/nfs/general
share:
- sudo touch /nfs/general/general.test
Then, check its ownership:
- ls -l /nfs/general/general.test
-rw-r--r-- 1 nobody nogroup 0 Apr 18 00:02 /nfs/general/general.test
Because you mounted this volume without changing NFS’s default behavior and created the file as the client machine’s root user via the sudo
command, ownership of the file defaults to nobody:nogroup
. client superusers won’t be able to perform typical administrative actions, like changing the owner of a file or creating a new directory for a group of users, on this NFS-mounted share.
Example 2: The Home Directory Share
To compare the permissions of the General Purpose share with the Home Directory share, create a file in /nfs/home
the same way:
- sudo touch /nfs/home/home.test
Then look at the ownership of the file:
- ls -l /nfs/home/home.test
-rw-r--r-- 1 root root 0 Apr 18 00:03 /nfs/home/home.test
You created home.test
as root using the sudo
command, exactly the same way you created the general.test
file. However, in this case it is owned by root because you overrode the default behavior when you specified the no_root_squash
option on this mount. This allows your root users on the client machine to act as root and makes the administration of user accounts much more convenient. At the same time, it means you don’t have to give these users root access on the host.
Step 7 — Mounting the Remote NFS Directories at Boot
You can mount the remote NFS shares automatically at boot by adding them to /etc/fstab
file on the client.
Open this file with root privileges in your text editor:
- sudo nano /etc/fstab
At the bottom of the file, add a line for each of your shares. They will look like this:
. . .
host_ip:/var/nfs/general /nfs/general nfs auto,nofail,noatime,nolock,intr,tcp,actimeo=1800 0 0
host_ip:/home /nfs/home nfs auto,nofail,noatime,nolock,intr,tcp,actimeo=1800 0 0
Make sure you save and close this file so that your changes take effect.
Note: You can find more information about the options you are specifying here in the NFS man page. You can access this by running the following command:
- man nfs
The client will automatically mount the remote partitions at boot, although it may take a few moments to establish the connection and for the shares to be available.
Step 8 — Unmounting an NFS Remote Share
If you no longer want the remote directory to be mounted on your system, you can unmount it by moving out of the share’s directory structure and unmounting, like this:
- cd ~
- sudo umount /nfs/home
- sudo umount /nfs/general
Take note that the command is named umount
not unmount
as you may expect.
This will remove the remote shares, leaving only your local storage accessible:
- df -h
Filesystem Size Used Avail Use% Mounted on
tmpfs 198M 972K 197M 1% /run
/dev/vda1 50G 3.5G 47G 7% /
tmpfs 989M 0 989M 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
/dev/vda15 105M 5.3M 100M 5% /boot/efi
tmpfs 198M 4.0K 198M 1% /run/user/1000