How to Mount NFS Shares on Debian 9
Traducciones al EspañolEstamos traduciendo nuestros guías y tutoriales al Español. Es posible que usted esté viendo una traducción generada automáticamente. Estamos trabajando con traductores profesionales para verificar las traducciones de nuestro sitio web. Este proyecto es un trabajo en curso.
What is Network File System (NFS)
Network File System (NFS) is a file system protocol that allows users of Unix-like systems to access files over a network in much the same way they can with local storage. This is useful for sharing files across several Linodes or other computers on the internet. For example, you can share the home directories for your users, or system configuration files, over NFS.
However, be aware that one limitation of NFS (versions 3 and older) is that servers and clients must be restricted to a local or trusted private network since data travels unencrypted from one machine to the other. This drawback was addressed with NFS version 4, which relies on Kerberos for authentication and encryption. Unfortunately, setting up Kerberos for use with NFS is rather complicated and requires a Key Distribution Center, which is out of the scope of this tutorial.
This guide walks you through the setup of two Linodes; one is the NFS server, and the other acting as the client. In this example, both Linodes are in the same data center and will communicate using their private IP addresses, so your data will never leave Linode’s network. Caution: Other NFS setups can potentially send traffic over the public internet.
NoteThis guide is written for a non-root user. Commands that require elevated privileges are prefixed with
sudo. If you’re not familiar with the
sudocommand, you can check our Users and Groups guide.
- Two Debian 9 Linodes deployed in the same data center.
- Linodes configured to use private IPs. See our Linux Static IP Configuration guide.
NFS Server Setup
Choose one Linode to be your NFS server. Follow the instructions below to configure it.
Update your package references:
sudo apt update
Install the NFS server package
sudo apt install nfs-kernel-server
Install the Portmapper package
sudo apt-get install portmap
Prevent access to the services used by NFS by default by adding the following line to your
- File: /etc/hosts.deny
rpcbind mountd nfsd statd lockd rquotad : ALL
Allow access to the services used by NFS for your client and localhost. Add the following lines to your
example_IPwith the client Linode’s private IPv4 address.
- File: /etc/hosts.allow
1 2 3
rpcbind mountd nfsd statd lockd rquotad : 127.0.0.1 : allow rpcbind mountd nfsd statd lockd rquotad : example_IP : allow rpcbind mountd nfsd statd lockd rquotad : ALL : deny
Create a directory in your local filesystem to use as the NFS share’s root location:
sudo mkdir /var/nfsroot
Assign appropriate ownership to the NFS share’s root:
sudo chown nobody:nogroup /var/nfsroot/
Add the following line to the
example_IPwith the client Linode’s private IPv4 address. Make sure there is no space between the /17 and the opening parenthesis, and that there is a blank line at the end of the file.
- File: /etc/exports
Update the table of exported file systems with the following command:
sudo exportfs -ra
Restart the NFS service on the server Linode for your changes to take effect:
sudo systemctl restart nfs-kernel-server
Done! Now you have a basic NFS server on one of your Linodes, configured to serve the
/var/nfsroot directory to your second Linode.
NFS Client Setup
The second Linode will be your NFS client. Follow the instructions below to configure it.
Update your package references:
sudo apt update
Install the NFS client package
sudo apt install nfs-common
Create a directory in the client Linode’s local filesystem to serve as the mount point for the remote filesystem:
sudo mkdir /mnt/remotenfs
Use your favorite editor to add the following line to the client’s
example_IPwith the server Linode’s private IPv4 address.
- File: /etc/fstab
example_IP:/var/nfsroot /mnt/remotenfs nfs rw,async,hard,intr,noexec 0 0
Mount the filesystem by running the following command:
sudo mount /mnt/remotenfs
And you’re done! Now, from the client Linode, you have access to the remote filesystem hosted on your Linode NFS server. You can add more clients by adding them to the server’s
/etc/exports file, then repeating the client setup for each client.
NFS provides various mount options. In this guide, we are using the standard behaviors of read and write access, asynchronous file transfers, and interruptible hard waits, but you can configure other behaviors on your NFS shares using the following options.
These options can be specified either in
fstab, or manually using the
mount command with the
-o switch, followed by a comma-separated list of mount options.
- rw: Read/write filesystem.
- ro: Read-only filesystem. Remote NFS clients can’t modify the filesystem.
- hard: Applications using files stored on an NFS will always wait if the server goes down. User cannot terminate the process unless the option
- soft: Applications using files stored on an NFS will wait a specified time (using the
timeooption) if the server goes down, and after that, will throw an error.
- intr: Allows user interruption of processes waiting on a NFS request.
- timeo=<num>: For use with the soft option. Specify the timeout for an NFS request.
- nolock: Disable file locks. Useful with older NFS servers.
- noexec: Disable execution of binaries or scripts on an NFS share.
- nosuid: Prevents users from gaining ownership of files on the NFS share.
- rsize=<num>: Sets the read block data size. Defaults to 8192 on NFSv2 and NFSv3, and 32768 on NFSv4.
- wsize=<num>: Sets the write block data size. Defaults to 8192 on NFSv2 and NFSv3, and 32768 on NFSv4.
These options can be specified in the
- rw: Read/write filesystem.
- ro: Force clients to connect in the read-only filesystem mode only.
- no_root_squash: The root account on the client machine will have the same privilege level as the root on the server machine. This option has security implications; do not use unless you are sure you need it. On the other hand, root_squash causes root on the client to have the same access type as nobody on the server - thus preventing root on the client(s) from spreading undesired files on to the others.
- no_subtree_check: Disable file location checks on partial volume exports. This option will speed up transfers on full volume exports.
- sync: Force all transfers to operate in synchronous mode, so all clients will wait until their operations are really done. This can avoid data corruption in the event of a server crash.
In the client, create a test file named
sudo echo "Hello World" > /mnt/remotenfs/testfile.txt
If everything went as expected,
/mnt/remotenfs/testfile.txt is owned by
nobody:nogroup. You can check with
ls -l /mnt/remotenfs/testfile.txt
Likewise, the same permissions should be visible in the server if you do
ls -l /var/nfsroot/testfile.txt
Now let’s replace root_squash with no_root_squash in
/etc/exports on the server and update the table of exported shares as explained in step 8 of NFS Server Setup above. Finally, we will repeat the above exercise by creating another test file (
testfile2.txt) in the same directory (
sudo echo "Hi everyone" > /mnt/remotenfs/testfile2.txt
If you check the ownership of
testfile2.txt either on the client or the server, you’ll see that it is now owned by
root:root. These simple examples illustrate the use and implications of root_squash and no_root_squash. For your security, don’t forget to remove the latter and re-add the former in your
/etc/exports as soon as possible.
This page was originally published on