Getting Started with NFS Part one


In this guide we will cover how to set up NFS on our file system in order to mount a directory over our network. The NFS protocol was designed in 1984 by Sun Microsystems and like any other protocol, it defines the rules and behaviors that two computers must follow in order to successfully communicate with each other. This guide will walk through the installation and setup of NFS on your file system.

The NFS installation, regardless of distribution, can be summed up in four steps:

1. Install the NFS package.

2. Create or choose the directory to be shared.

3. Edit the /etc/exports file.

4. Start the NFS service. 

This guide is aimed at beginners, who have no  previous experience setting up NFS.  In part two and three of this guide, we will cover setting up NFS  using Kerberos for authentication, and setting up NFS servers with an failover option.

Getting Started

Note: This guide is designed to introduce you to NFS. In order to make the introduction as simple as possible, this guide takes liberties in not discussing topics which will be covered in part two of this guide where we will cover authentication among other topics. The following set up is not recommended for a production environment. 


  • A Debian or Arch base distribution with an active Internet connection.
  • Ability to open and use a Linux terminal.
  • Your server must have a static IP. 

Server Side Installation

Before we begin the installation, let's take a quick moment to jot down our server’s IP address. We can do this with ifconfig 

$ Ifconfig 
lo        Link encap:Local Loopback  
         inet addr:  Mask:
         inet6 addr: ::1/128 Scope:Host
         UP LOOPBACK RUNNING  MTU:16436  Metric:1
         RX packets:8 errors:0 dropped:0 overruns:0 frame:0
         TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
         collisions:0 txqueuelen:0
         RX bytes:480 (480.0 b)  TX bytes:480 (480.0 b)

enp0S3     Link encap:Ethernet  HWaddr 00:1C:C0:AE:B5:E6  
         inet addr:  Bcast:  Mask:
         inet6 addr: fe80::21c:c0ff:feae:b5e6/64 Scope:Link
         RX packets:41620 errors:0 dropped:0 overruns:0 frame:0
         TX packets:40231 errors:0 dropped:0 overruns:0 carrier:0
         collisions:0 txqueuelen:1000
         RX bytes:21601203 (20.6 MiB)  TX bytes:6145876 (5.8 MiB)

Your output will vary from mine.  ifconfig  gives you a list of the network interfaces on your system.  The first interface you will come across is  lo otherwise known as the loopback interface, followed by however many  network interfaces you have installed on your system.

Your local IP address will follow after inet as shown above. We need the server’s IP address in order to mount our directory from the client. This is why it is important to have a static IP set up on your server. If you don’t, once your server changes its local IP, your configuration on the client side will break.

Now that we have the local IP of our server, we are ready to continue.   


With your package manager of choice, install the nfs-server package.

sudo apt install  nfs-server 

If you’re on an Arch base system you can use the pacman or yaourt package manager in order to install the NFS package. In the Arch repositories however, the NFS package is named nfs-utils.

sudo pacman -S nfs-utils

After installing NFS, we begin by creating the directory that we would like to share.

sudo mkdir -p /srv/nfs/home

In this instance, we are creating both an nfs and a home subdirectory by passing mkdir -p. Keep in mind that you have free reign when it comes to naming your directory and its location.

In order for all users to have access to our shared directory, and simplifying the authentication process.  We need to change the permissions to read, write, and execute  recursively on our directory.

sudo chmod 777 -R /srv/nfs/home

Once the directory is created and we have given it proper permissions, we are ready to continue our set up by editing the exports file in our /etc directory.  The /etc/exports file controls which directories are allowed to be mounted on remote systems.  So in order to share our newly created directory with our clients, we are going to add it to our exports file.

sudo vim /etc/exports

Let’s start by adding the name of the directory we created to the end of our /etc/exports file.  


Followed by the IP of the clients that are going to be allowed to access the shared directory. I'm on a class C network therefore I'm using the shorthand /24 to allow all local IPs to connect to my shared directory.  However, you can add access to the directory by giving the exports file specific IPs such as /srv/nfs/home


Finally we add our options.

/srv/nfs/home,sync, no_root_squash)

Save and close the file.

Make sure everything is written exactly as you see it. Typos in this configuration will cause issues when you attempt to start the nfs-server.

After finishing setting up our server configuration file, we are ready to start the nfs-server.

On a Debian base system

sudo systemctl start nfs-server

On Arch base systems you can use 

sudo systemctl start nfs-utils

Let’s check the status of the server, to ensure that it now shows as active. Use nfs-server for Debian based distributions or nfs-utils on Arch base distributions.

sudo systemctl status nfs-server

Also check that the rpcbind service is up and running.

sudo systemctl status rpcbind

If everything is up and running, you have completed the NFS server side set up.

Client side setup


We start by installing the NFS package on the client machine. If you are using a Debian based distribution, use the following command. 

sudo apt install nfs-common

On an Arch base distribution you can use

sudo pacman –S nfs-utils 


We start by creating the directory in which we are going to mount our remote directory. 

mkdir  /mnt/sharedir

After we create our directory, we are ready to mount the remote directory we created on our server by using the mount command, followed by our server’s IP (remember to use the IP on your server) followed by a colon, and the directory we created on our server. We then give the mount command the local directory in which we will mount our remote directory. 

sudo mount  /mnt/sharedir

Your NFS directory should now be mounted and ready to use.

Let’s do a quick test.

On your client 

cd /mnt/sharedir

mkdir itworks 

Then on your server

cd /srv/nfs/home 


and you should see the itworks directory that we just created. We  can permanently mount the directory on our system, by editing the /etc/fstab file. The format for adding our directory is as follows:    /mnt/sharedir               auto,nofail          0 0   

The nofail option allows the operating system to continue its normal boot up process should the remote directory not be available to mount at the moment.

Sources / Resources

  • Linux  Linux Foundation Certified System Administrator (LFCSA v2.16) on Linux Academy. 
  • post-author-pic
    Evan L

    A few suggestions.   You may want to add a quick note about autofs or the systemd automounter which can auto-mount NFS shares when the directory is accessed rather than keeping it mounted all the time.    I strongly suggest adding a "nofail" option when using NFS mounts in /etc/fstab.  Otherwise, a down NFS server will make the client fail to boot as well!    

    When mounting /home over NFS you have additional problems.    You should probably prepare for NFS failure by having a user hierarchy under /home.   This could still cause considerable delays in login when the NFS share goes down.  I might consider a hybrid system where the NFS directory mounts elsewhere, and then use overlayfs  to mount the NFS shared system over a default directory.  If the NFS server goes down, overlayfs should simply overlay the empty directory over the top of your default tree.   This has added benefits in that you can make specific files different for each system and only NFS mount the stuff you want shared.

  • post-author-pic
    Gregory E

    Very well said, will make the changes today. Thank you. 

  • post-author-pic
    John B

    Great guide here Gregory!

  • post-author-pic
    Johnny J

     @backslash: Great job!

  • post-author-pic
    Gregory E

    Johnny Jelinek  and John BryanThank you !!!

  • post-author-pic
    Sola O

    Thanks a lot for this Gregory, well appreciated! LA, can you please add a feature to get such good articles bookmarked pleaseee, thanks.

  • post-author-pic
    Sean G

     @solao You can already do that! If you click the options button in the top right of a post you can click 'bookmark' and it will save it to your bookmarks!


  • post-author-pic
    Evan L

    Another quick browse and ... are you exporting /home and changing permissions to 777?   If you share nfs home directories you need to set up some sort of localized authentication, such as LDAP, or at the very least work up a script to sync up /etc/passwd and /etc/group between systems.  Keep the name to numeric ids matching between systems and NFS will happily obey permissions.   One of the best features of NFS is that the permission system is native to Unix.  It is REALLY bad to give people permissions to each other's home directories like that ... you just gave access to everyone's ssh keys among other things!   I realize its only an example, but someone copying the example could very well do something like that on a production system.  chmod 777 is never the answer!

  • post-author-pic
    Gregory E

    Evan you have made a very good point. I added a warning in the beginning of the guide, and will be covering other authentication methods on the second part of this guide. 

  • post-author-pic
    Evan L

    Looking forward to part 2!  Geat job

  • post-author-pic
    Gregory E

    Thank you for keeping me on my toes !!!! 

  • post-author-pic
    Patrick G

    The use of ifconfig has been deprecated for a while.

    ip addr
    is the modern command for determining your host's IP address.

  • post-author-pic
    Johnny J

     @pgoetz: Good find!

  • post-author-pic
    Roy P

    Great tutorial! Looking forward to subsequent parts.

  • post-author-pic
    Murtuza K

    Good Work. Very easy to understand. Thank you for posting this!!

  • post-author-pic
    Eran M

    You have a typo, wrote rcpbind instead of rpcbind

  • post-author-pic
    Soe W

    keep it on  next part 2

  • post-author-pic
    Mohammad Al A

    Well documented and helpful

  • post-author-pic

    Very good documentation! 

    Not sure how it was labeled "COURSE: RED HAT CERTIFIED ENGINEER (RHCE) PREP COURSE" though, when the guide states the requirement of  "A Debian or Arch base distribution with an active Internet connection.".

Looking For Team Training?

Learn More