From IGEP - ISEE Wiki
no edit summary
'text-align: center; '>'''''/etc/exports '''''</div>
sudo systemctl restart nfs-kernel-server
Before you can actually use the new shares, however, you’ll need to be sure that traffic to the shares is permitted by firewall rules
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:
Filesystem Size Used Avail Use% Mounted on udev 238M 0 238M 0% /dev tmpfs 49M 628K 49M 2% /run /dev/vda1 20G 1.2G 18G 7% / tmpfs 245M 0 245M 0% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs 245M 0 245M 0% /sys/fs/cgroup tmpfs 49M 0 49M 0% /run/user/0 203.0.113.0:/home 20G 1.2G 18G 7% /nfs/home203.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.
du -sh /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
-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:
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 ~sudo umount /nfs/homesudo umount /nfs/general
This will remove the remote shares, leaving only your local storage accessible:
Filesystem Size Used Avail Use% Mounted on/dev/vda 59G 1.3G 55G 3% /none 4.0K 0 4.0K 0% /sys/fs/cgroupudev 2.0G 12K 2.0G 1% /devtmpfs 396M 320K 396M 1% /runnone 5.0M 0 5.0M 0% /run/locknone 2.0G 0 2.0G 0% /run/shmnone 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.