Personal tools

Log in

Changes

From IGEP - ISEE Wiki

Jump to: navigation, search

How To Set Up an NFS Mount on Ubuntu 16.04

704 bytes removed, 10:28, 25 June 2018
no edit summary
__TOC__
 
==Introduction==
NFS, or Network File System, is a distributed file system protocol that allows you to mount remote directories on your server. This lets you manage storage space in a different location and write to that space from multiple clients. NFS provides a relatively quick and easy way to access remote systems over a network and works well in situations where the shared resources will be accessed regularly.
* Two Ubuntu 16.04 servers, each with a non-root user with sudo privileges and private networking, if it’s available to you.
Throughout the tutorial, we refer to the server that shares its directories as the '''host ''' and the server that mounts these directories as the '''client'''. In order to keep them straight, we’ll use the following IP addresses as stand-ins for the host and client values:
'''Host''': 203.0.113.0
'''Client''': 203.0.113.256
You should replace these values with your own host and client ip addresses.
===Step 1 — Downloading and Installing the Components===
We’ll begin by installing the necessary components on each server.
'''<u>On the Host</u>'''
On the host server, we will install the nfs-kernel-server package, which will allow us to share our directories. Since this is the first operation that we're performing with apt in this session, we'll refresh our local package index before the installation:
sudo apt-get update<br>sudo apt-get install nfs-kernel-server
Once these packages are installed, switch to the client server.
'''<u>On the Client</u>'''
On the client server, we need to install a package called nfs-common, which provides NFS functionality without including unneeded server components. Again, we will refresh the local package index prior to installation to ensure that we have up-to-date information:
sudo apt-get update<br>sudo apt-get install nfs-common
Now that both servers have the necessary packages, we can start configuring them.
===Step 2 — Creating the Share Directories on the Host===
We're going to share two separate directories, with different configuration settings, in order to illustrate two key ways that NFS mounts can be configured with respect to superuser access.
Sometimes, however, there are trusted users on the client system who need to be able to do these things on the mounted file system but who have no need for superuser access on the host. The NFS server can be configured to allow this, although it introduces an element of risk, as such a user could gain root access to the entire host system.
====Example 1: Exporting a General Purpose Mount====
In the first example, we’ll create a general-purpose NFS mount that uses default NFS behavior to makes it difficult for a user with root privileges on the client machine to interact with the host using those client superuser privileges. You might use something like this to store the files uploaded using a content management system or to create space for users to easily share project files.
First, make a share directory called nfs:
sudo mkdir /var/nfs/general -p
Since we’re creating it with sudo, the directory is owned by root here on the host.
ls -la /var/nfs/general
Output
4 drwxr-xr-x 2 root root 4096 Jul 25 15:26 .
NFS will translate any root operations on the client to the nobody:nogroup credentials as a security measure. Therefore, we need to change the directory ownership to match those credentials.
4 drwxr-xr-x 2 root root 4096 Jul 25 15:26 .NFS will translate any root operations on the client to the '''nobody:nogroup''' credentials as a security measure. Therefore, we need to change the directory ownership to match those credentials.  sudo chown nobody:nogroup /var/nfs/general
This directory is now ready for export.
====Example 2: Exporting the Home Directory====
In our second example, the goal is to make user home directories stored on the host available on client servers, while allowing trusted administrators of those client servers the access they need to conveniently manage users.
To do this, we’ll export the /home directory. Since it already exists, we don’t need to create it. We won’t change the permissions, either. If we did, it would cause all kinds of issues for anyone with a home directory on the host machine.
===Step 3 — Configuring the NFS Exports on the Host Server===
Next, we’ll dive into the NFS configuration file to set up the sharing of these resources.
Open the /etc/exports file in your text editor with root privileges:
sudo nano /etc/exports
The file has comments showing the general structure of each configuration line. The syntax is basically:
<span style="color: #ff0000;">/etc/exportsdirectory_to_share      directory_to_share client(share_option1,...,share_optionN)</span> 
We’ll need to create a line for each of the directories that we plan to share. Since our example client has an IP of 203.0.113.256, our lines will look like the following. Be sure to change the IPs to match your client:
/etc/exports
/var/nfs/general 203.0.113.256(rw,sync,no_subtree_check)
/home 203.0.113.256(rw,sync,no_root_squash,no_subtree_check)
We’re using the same configuration options for both directories with the exception of no_root_squash. Let’s take a look at what each one means.
rw: This option gives the client computer both read and write access to the volume.
sync: This option forces NFS to write changes to disk before replying. This results in a more stable and consistent environment since the reply reflects the actual state of the remote volume. However, it also reduces the speed of file operations.
no_subtree_check: This option prevents subtree checking, which is a process where the host must check whether the file is actually still available in the exported tree for every request. This can cause many problems when a file is renamed while the client has it opened. In almost all cases, it is better to disable subtree checking.
no_root_squash: By default, NFS translates requests from a root user remotely into a non-privileged user on the server. This was intended as security feature to prevent a root account on the client from using the file system of the host as root. no_root_squash disables this behavior for certain shares.
When you are finished making your changes, save and close the file. Then, to make the shares available to the clients that you configured, restart the NFS server with the following command:
sudo systemctl restart nfs<div style="text-kernel-serveralign: center;">'''''/etc/exports   '''''</div>Before you can actually use the new shares<code>/var/nfs/general 203.0.113.256(rw, howeversync, you’ll need to be sure that traffic to the shares is permitted by firewall rulesno_subtree_check)</code>
Step 4 — Adjusting the Firewall on the HostFirst<code>/home 203.0.113.256(rw, let’s check the firewall status to see if it’s enabled and if sosync, to see what's currently permitted:no_root_squash,no_subtree_check)</code>
sudo ufw statusWe’re using the same configuration options for both directories with the exception of no_root_squash. Let’s take a look at what each one means.OutputStatus'''rw''': activeThis option gives the client computer both read and write access to the volume.
To Action From-- ------ ----OpenSSH ALLOW AnywhereOpenSSH (v6) ALLOW Anywhere (v6)On our system, only SSH traffic is being allowed, so we’ll need '''sync''': This option forces NFS to write changes to add disk before replying. This results in a rule for NFS trafficmore stable and consistent environment since the reply reflects the actual state of the remote volume. However, it also reduces the speed of file operations.
With many applications, you can use sudo ufw app list and enable them by name'''no_subtree_check''': This option prevents subtree checking, but nfs which is not one of those. Because ufw also checks /etc/services for a process where the host must check whether the port and protocol of a service, we can file is actually still add NFS by nameavailable in the exported tree for every request. Best practice recommends that you enable This can cause many problems when a file is renamed while the most restrictive rule that will still allow the traffic you want client has it opened. In almost all cases, it is better to permit, so rather than enabling traffic from just anywhere, we’ll be specificdisable subtree checking.
Use '''no_root_squash''': By default, NFS translates requests from a root user remotely into a non-privileged user on the following command server. This was intended as security feature to open port 2049 prevent a root account on the client from using the file system of the host, being sure to substitute your client's ip address:as root. no_root_squash disables this behavior for certain shares.
sudo ufw allow from 203When you are finished making your changes, save and close the file.0.113.256 Then, to make the shares available to any port nfsYou can verify the change by typingclients that you configured, restart the NFS server with the following command:
sudo ufw statussystemctl restart nfs-kernel-serverYou should see Before you can actually use the new shares, however, you’ll need to be sure that traffic allowed from port 2049 in to the output:shares is permitted by firewall rules
Output
Status: active
To Action From
-- ------ ----OpenSSH ALLOW Anywhere
2049 ALLOW 203.0.113.256
OpenSSH (v6) ALLOW Anywhere (v6)
This confirms that UFW will only allow NFS traffic on port 2049 from our client machine.
===Step 5 4 — Creating the Mount Points on the Client===
Now that the host server is configured and serving its shares, we’ll prepare our client.
sudo mkdir -p /nfs/general
 
sudo mkdir -p /nfs/home
 ===Step 6 5 — Mounting the Directories on the Client===
Now that we have some place to put the remote shares and we've opened the firewall, we can mount the shares by addressing our host server, which in this guide is 203.0.113.0, like this:
sudo mount 203.0.113.0:/var/nfs/general /nfs/general<br>sudo mount 203.0.113.0:/home /nfs/home
These commands should 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 plain mount or findmnt command, but df -h will give you more human readable output illustrates how disk usage is displayed differently for the nfs shares:
df -h
Output
 <code>Filesystem Size Used Avail Use% Mounted on</code> <code>udev 238M 0 238M 0% /dev</code> <code>tmpfs 49M 628K 49M 2% /run</code> <code>/dev/vda1 20G 1.2G 18G 7% /</code> <code>tmpfs 245M 0 245M 0% /dev/shm</code> <code>tmpfs 5.0M 0 5.0M 0% /run/lock</code> <code>tmpfs 245M 0 245M 0% /sys/fs/cgroup</code> <code>tmpfs 49M 0 49M 0% /run/user/0</code> <code>203.0.113.0:/home 20G 1.2G 18G 7% /nfs/home</code> <code>203.0.113.0:/var/nfs/general 20G 1.2G 18G 7% /nfs/general</code> 
Both of the shares we 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 will provide a summary of usage rather than displaying the usage for every file. The -h will print human readable output.
For example:
du -sh /nfs/home
Output
  36K /nfs/home
This shows us that the contents of the entire home directory is using only 20K of the available space.
===Step 7 — Testing NFS Access===
Next, let’s 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.
Because we 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 Home Directory the same way:
sudo touch /nfs/home/home.test
Then look at the ownership of the file:
ls -l /nfs/home/home.test
Output
  -rw-r--r-- 1 root root 0 Aug 1 13:32 /nfs/home/home.test
We created home.test as root via the sudo command, exactly the same way we created the general.test file. However, in this case it is owned by root because we overrode the default behavior when we specified the no_root_squash option on this mount. This allows our 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 we don’t have to give these users root access on the host.
===Step 8 — Mounting the Remote NFS Directories at Boot===
We can mount the remote NFS shares automatically at boot by adding them to /etc/fstab file on the client.
sudo nano /etc/fstab
 
At the bottom of the file, we're going to add a line for each of our shares. They will look like this:
/etc/fstab
. . .
203.0.113.0:/var/nfs/general /nfs/general nfs auto,nofail,noatime,nolock,intr,tcp,actimeo=1800 0 0
203.0.113.0:/home /nfs/home nfs auto,nofail,noatime,nolock,intr,tcp,actimeo=1800 0 0
 . . .
 
203.0.113.0:/var/nfs/general /nfs/general nfs auto,nofail,noatime,nolock,intr,tcp,actimeo=1800 0 0<br>203.0.113.0:/home /nfs/home nfs auto,nofail,noatime,nolock,intr,tcp,actimeo=1800 0 0
Note: More information about the options we are specifying here can be found in the man page that describes NFS mounting in the fstab with the man nfs command.
The client server will automatically mount the remote partitions at boot, although it may take a few moments for the connection to be made and the shares to be available.
===Step 9 — 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 ~<br>sudo umount /nfs/home<br>sudo umount /nfs/general
This will remove the remote shares, leaving only your local storage accessible:
df -h
Output
Filesystem Size Used Avail Use% Mounted on<br>/dev/vda 59G 1.3G 55G 3% /<br>none 4.0K 0 4.0K 0% /sys/fs/cgroup<br>udev 2.0G 12K 2.0G 1% /dev<br>tmpfs 396M 320K 396M 1% /run<br>none 5.0M 0 5.0M 0% /run/lock<br>none 2.0G 0 2.0G 0% /run/shm<br>none 100M 0 100M 0% /run/user
If you also want to prevent them from being remounted on the next reboot, edit /etc/fstab and either delete the line or comment it out by placing a # symbol at the beginning of the line. You can also prevent auto-mounting by removing the auto option, which will allow you to mount it manually.
If you’re using NFS for private data, however, you’ll need to decide how you want to protect that data. You might be able to route NFS over SSH or a VPN connection to create a more secure experience, but this often comes with a serious loss of performance. If performance is an issue, consider SSHFS. It’s slightly slower than unencrypted NFS traffic, but usually much faster than tunnelled NFS. Kerberos authenticated encryption for NFS is another option to explore.
 
[[Category:Ubuntu]]
[[Category:Software distributions]]