Content

Introductory

Here's how to connect remotely to your Debian computer NFS and can be used as local storage. In this example, I will show you how to use NFS on two Debian 8 (Jessie) laptops: One will create an NFS share and the other will mount it on the local file system.

I have already made a similar description where a bind mount method I mounted a directory structure on another partition in the appropriate storage directory on the web server to extend the web hosting on that website, and now we will mount the NFS share on a remote machine in the local file structure of the computer and use it as if it were on the computer's own hard drive.

The difference here is that I'm not working on a web server at this point, but I'm going to show you how to use NFS on my two Debian 8 (Jessie) laptops. That's why I put this description in this general file system category. Nevertheless, this method can of course be used complete web server environments for example, if you need to expand storage space or work with multiple server structures.

First we define the two computers and they IP addresses. I have both machines behind my router, so they are on the same local network. The server machine on which we create the NFS shares and the client machine on which we mount them in the local file system.

• NFS server machine: IP address: 192.168.1.101, hostname: bnd-laptop
• NFS client machine: IP Address: 192.168.1.102, Host Name: bnd-laptop2

So in this tutorial I will present the problem with these two machines.

NFS server installation and configuration

Log on to the server machine as root (from where you want to share the directories) and run the following apt-get command:

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

Configuration files are also created when you install the NFS server. Then export the appropriate directories (shares).

NFS allows you to share in multiple modes:

• Public Sharing: Read-only, open-to-share sharing (root_squash, all_squash)
• Maintaining Root Rights: Write, read, and file operations on the client machine are executed on the server as the same user (no_all_squash, no_root_squash)
• To remove root rights: File operations on the client machine on the server a nobody are executed as a user. It is useful if it is difficult or impossible to reconcile users and UIDs on the two machines (root_squash, all_squash).

In this example, I show all three types of sharing with three separate subdirectories. For simplicity, create an nfs subdirectory in the / home directory of the NFS server, followed by three others to illustrate sharing modes:

mkdir -p /home/nfs/public
mkdir -p /home/nfs/root
mkdir -p /home/nfs/no-root

Migrate the directories to nobody: nogroup and then to chmod add the appropriate permission to it:

chown nobody:nogroup /home/nfs/*
chmod 0755 /home/nfs/*

Next, edit the shares on the NFS server in the configuration file:

nano /etc/exports

And add the three shares to the file:

/home/nfs/public	192.168.1.102(ro,no_subtree_check,root_squash,all_squash)
/home/nfs/root		192.168.1.102(rw,sync,no_subtree_check,no_all_squash,no_root_squash)
/home/nfs/no-root	192.168.1.102(rw,sync,no_subtree_check,root_squash,all_squash)

Restart the NFS server:

service nfs-kernel-server restart

We can check our exports:

showmount --exports --no-headers

/home/nfs/no-root 192.168.1.102
/home/nfs/root    192.168.1.102
/home/nfs/public  192.168.1.102

NFS client installation, configuration

Log on to the client machine as root and install the required package:

apt-get install nfs-common

Create a local directory structure for NFS shares

Create the directories where you want to mount the shares. For the sake of clarity, create a similar directory structure on the client computer as on the server:

mkdir -p /home/nfs-remote/public
mkdir -p /home/nfs-remote/root
mkdir -p /home/nfs-remote/no-root

Manually mount (temporarily) remote NFS shares

A mount command to temporarily count your shares, which remain valid until the machine is shut down:

mount 192.168.1.101:/home/nfs/public /home/nfs-remote/public/
mount 192.168.1.101:/home/nfs/root /home/nfs-remote/root/
mount 192.168.1.101:/home/nfs/no-root /home/nfs-remote/no-root/

Let's test the client-side operation:

nfsstat -m

And the result should be something like:

/home/nfs-remote/no-root from 192.168.1.101:/home/nfs/no-root
 Flags: rw,relatime,vers=4.0,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.102,local_lock=none,addr=192.168.1.101

/home/nfs-remote/public from 192.168.1.101:/home/nfs/public
 Flags: rw,relatime,vers=4.0,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.102,local_lock=none,addr=192.168.1.101

/home/nfs-remote/root from 192.168.1.101:/home/nfs/root
 Flags: rw,relatime,vers=4.0,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.102,local_lock=none,addr=192.168.1.101

Persistent mount of remote NFS shares

If you want to keep these links not only until you shut down the machine, but need them after rebooting, you need to save them in / etc / fstab.

To do this, first dismantle the current links so we can test the functionality:

umount /home/nfs-remote/*

Then open / etc / fstab and add the following 3 line:

192.168.1.101:/home/nfs/public	/home/nfs-remote/public		nfs		ro,sync,hard,intr  0     0
192.168.1.101:/home/nfs/root	/home/nfs-remote/root		nfs		rw,sync,hard,intr  0     0
192.168.1.101:/home/nfs/no-root	/home/nfs-remote/no-root	nfs		rw,sync,hard,intr  0     0

Perform the fstab file attachments:

mount -a

We can then double-check the success of the link:

nfsstat -m

And the output should be (almost) the same as in the above check, except that here we have public share attached in ro (readonly) mode, so that the client machine will reject write requests to the file system.

Testing

Now that we already have our exports on the server machine and mounted them on the client machine, all we have to do is try NFS on all three shares.

If you look at the local mount points with the df command, you can see the three shares from the other host. So the image in the top terminal window is the NFS client (bnd-laptop2) and the bottom is the NFS server (bnd-laptop), where we see the local / home / nfs / directory and its shared subdirectories.

In the next step, in the window below (on an NFS server), we create a file in the read-only "public" share, then check it above in the client, and then try to delete this file from the client:

As expected, the file could not be deleted from the client because the "public" share is write protected.

The remaining two read-write partitions are then tested. In the client window above, create a file in the "no-root" share, and then observe what's happening on the NFS server below:

The file has been created and we can see that its owner is a nobody: nogroup, even though it was created as root. This is because we created this share with the "root_squash, all_squash" options, which causes any client-side changes made to the share on the NFS server with the nobody: nogroup property.

In the last test example, we create a trial file in the "root" share:

Here, the file created as root in the upper client terminal was also executed as root on the lower server.

Conclusion

Thus, NFS shares allow you to manage remote file systems in more nuances, depending on what you need. For example, if you only want to share an installation set or a music collection, then "read-only mode" (root_squash, all_squash options) so you don't have to worry about clients modifying the contents of the library.

And if you run a multi-machine company internal network, then "root mode" (no_all_squash, no_root_squash options) is the right choice to create a home directory for each user on your company's central computer, so you don't have to maintain and maintain user libraries on each machine, but manage them centrally in one place.

Resources used