Introduction

Setting up NFS (Network File System) on Debian 11 allows you to seamlessly share directories between remote servers. This step-by-step guide will walk you through the entire process—from installing the necessary NFS packages to configuring exports and firewall rules. Whether you’re setting up NFS mounts on the host server or ensuring they mount automatically at boot, this guide covers all the essential steps. By the end, you’ll be able to easily manage NFS shares on your Debian 11 system and streamline your file sharing between servers.

Step 1 — Downloading and Installing the Components

Alright, let’s get started! The first thing we need to do to set up NFS is install the right components on both the host and client servers. These components are what make NFS work, allowing you to share and mount directories between the two systems. Think of it like getting the keys to a shared digital space where both machines can meet and exchange files.

On the Host Server:

We’ll begin with the host server. For this, you need the nfs-kernel-server package, which is what lets the host share directories with other systems on the network. But before installing anything, we need to make sure the package list on the system is up to date. It’s like checking for updates before you install new software—just to make sure everything runs smoothly.

To refresh the package list, run:

$ sudo apt update

Once that’s done, you can go ahead and install the nfs-kernel-server package. This is the key to turning the host server into a file-sharing hub for others on the network. Here’s the command:

$ sudo apt install nfs-kernel-server

Once the package is installed, your host server is all set up and ready to share directories with the client server. You’re all set to go!

On the Client Server:

Next, we move on to the client server. This is the machine that will be accessing the directories shared by the host. The client server doesn’t need the full server-side package—just the nfs-common package. This is the one that allows the client to mount remote directories that the host shares. You’re not actually sharing anything yet, just getting the ability to connect to those directories when you need them.

As before, let’s make sure the package list is up-to-date on the client server by running:

$ sudo apt update

Once that’s done, you can install the nfs-common package using:

$ sudo apt install nfs-common

And just like that, the client server is now ready to access the directories shared by the host.

Ready for the Next Step:

Now that both the host and client servers have the necessary NFS packages installed, it’s time to dive into the next step—configuration! You’ll soon be setting up how to share and mount those directories between the two servers. But for now, you’ve laid the groundwork!

Step 2 — Creating the Share Directories on the Host

Alright, now we’re getting into the nitty-gritty of setting up the directories on the host server. Imagine this: you’re creating two special folders on the host server, each with its own settings, and these will play a big role in how NFS mounts work later. These directories will show us two important ways to configure NFS mounts, especially when it comes to superuser access.

Now, here’s the deal with superusers: they have full control over their system. They can do anything, anywhere. But when it comes to NFS-mounted directories, things work a bit differently. These directories aren’t part of the system where they’re mounted. So, by default, NFS keeps things secure by blocking operations that need superuser privileges. This means that even if you’re a superuser on the client machine, you won’t be able to change file ownership or perform any admin tasks on the NFS share.

But wait, you might be wondering, “What if I trust some users on the client machine who need to perform admin tasks, but I don’t want to give them full root access on the host server?” Well, good news. You can configure NFS to let them do it. However, there’s a catch. Allowing users to perform admin tasks on the mounted file system can introduce some risks. So, it’s a bit of a balancing act between giving the users what they need and keeping the host server secure. It’s definitely something you’ll want to think through before making any changes.

Example 1: Exporting a General Purpose Mount

Let’s start with something simple—creating a general-purpose NFS mount. This setup uses the default behavior of NFS, which is designed to make it tough for root users on the client machine to do anything harmful to the host system. Think of it like a shared folder where people can upload files from a content management system or collaborate on projects, but without risking the host system in any way.

To get started, we need to create the directory on the host server. Here’s the command for that:

$ sudo mkdir /var/nfs/general -p

The -p option is pretty useful because it makes sure the directory is created along with any necessary parent directories that might not exist yet. Since you’re using sudo here, the directory will be owned by the root user of the host server. To double-check that the directory has been created and is owned by root, run this command:

$ ls -dl /var/nfs/general

You should see something like this in the output:

drwxr-xr-x 2 root root 4096 Apr 17 23:51 /var/nfs/general

At this point, NFS has a little trick up its sleeve. When root operations are performed on the client machine, they’re converted into non-privileged actions using the nobody:nogroup credentials as a security measure. To make sure these credentials are the same on both the host and client, you’ll need to change the directory’s ownership to nobody:nogroup :

$ sudo chown nobody:nogroup /var/nfs/general

After running that, check the ownership again:

$ ls -dl /var/nfs/general

Now, the directory should look like this:

drwxr-xr-x 2 nobody nogroup 4096 Apr 17 23:51 /var/nfs/general

And just like that, you’re ready to export and share this directory with your client server.

Example 2: Exporting the Home Directory

Now, let’s switch gears a bit and look at something a little more personal—the /home directory. This is where all the user home directories are stored on the host server, and the goal here is to make those directories available to the client servers. But here’s the catch: you still want to give trusted admins on the client side the ability to manage those user accounts.

Good news—you don’t need to create the /home directory. It’s already there on the host server. The important thing here is that you shouldn’t change the permissions on this directory. Why? Because messing with the permissions could cause problems for the users who rely on their home directories. By leaving the permissions alone, you ensure that everyone’s access stays intact, and you won’t run into any unexpected issues.

With this setup, you’ll be able to give trusted administrators the access they need, while still keeping everything safe and secure on the host server.

Step 3 — Configuring the NFS Exports on the Host Server

Now we’re diving into the fun part of configuring NFS exports on the host server—this is where the magic of sharing directories comes to life! At this stage, you’re basically opening up parts of the host server so the client can access them. The key here is modifying the NFS configuration file to define which directories you want to share and how the client will access them.

Opening the Configuration File:

The first thing you need to do is open the /etc/exports file on the host machine. This file is where all the sharing happens. But since we’re working with system-level configurations, you’ll need to open it with root privileges. Don’t worry; it’s pretty simple. Just run this command:

$ sudo nano /etc/exports

Once it’s open, you’ll see some helpful comments explaining the structure of the configuration lines. The basic format you’ll follow is:

/etc/exports directory_to_share client(share_option1,…,share_optionN)

Each line corresponds to a directory you want to share, and the options define how the client will interact with those directories.

Adding the Export Configuration:

Now, let’s get into the actual configuration. In this case, we’ll be sharing two directories: /var/nfs/general and /home . Each directory has its own specific settings to make sure the client can access them properly.

Before you move forward, make sure to replace the client_ip placeholder with the actual IP address of your client machine that will be accessing these directories. Here’s how it should look:

/etc/exports
/var/nfs/general client_ip(rw,sync,no_subtree_check)
/home client_ip(rw,sync,no_root_squash,no_subtree_check)

What Do These Options Mean?

Let’s break down what’s going on here and what each of these options means for the directories:

• rw: This gives the client both read and write access to the shared volume. In simple terms, it means the client can modify files and create new ones in the shared directory. You want this because you’re not just sharing files—you want the client to be able to interact with them too.
• sync: This option makes sure the NFS server writes changes to disk before sending a reply to the client. Why is this important? Well, it guarantees that any changes made by the client are safely saved to disk, keeping everything consistent. Just keep in mind that it might slightly slow down file operations because it ensures everything is properly saved before responding to the client.
• no_subtree_check: By default, NFS checks to make sure the file the client is accessing is still part of the exported directory tree. This can be a pain if a file is moved or renamed while the client is using it. Disabling subtree checking with no_subtree_check helps avoid errors when files are renamed or moved while the client is still accessing them.
• no_root_squash: Normally, NFS turns any root-level operations from the client into non-privileged actions on the host system. This is a security feature designed to keep a root user from doing anything harmful to the host. But if you enable no_root_squash , it lets trusted users on the client machine perform root-level tasks on the host without actually giving them root access on the host server itself. So, if you have admins on the client that need to manage files like superusers, but you don’t want to give them full root access, this option is perfect for you.

Saving the Configuration:

Once you’ve added the necessary export configurations, it’s time to save and close the file. To do this in nano, press Ctrl + X , then Y to confirm the changes, and finally press Enter to exit.

Restarting the NFS Server:

To apply the changes and make the shares available to the client, you need to restart the NFS server. Here’s how you do it:

$ sudo systemctl restart nfs-kernel-server

Now your host server is all set up and ready to share its directories with the client.

Adjusting Firewall Rules:

Before you start using the new NFS shares, there’s one more thing to check—your firewall rules. By default, the firewall on the host server might block NFS traffic, meaning your client won’t be able to access the shared directories. You’ll need to adjust the firewall settings to allow traffic on the necessary NFS ports.

Without this, even though everything is set up correctly, the client could still be blocked from accessing the shares. To fix this, you’ll adjust the firewall settings to let the necessary NFS traffic through. Once you’ve done that, the client will have smooth access to the shares, and you’ll be good to go!

What is NFS?

Step 4 — Adjusting the Firewall on the Host

Alright, now we’re getting to a crucial part of making everything run smoothly between your host and client—setting up the firewall. Think of the firewall as the security guard for your server, deciding what gets in and what stays out. So, we need to tell it to let NFS traffic through. But before we start opening any doors, let’s first check out what the firewall is currently letting through.

Checking the Firewall Status

To check the firewall’s status, just run a simple command on the host server:

$ sudo ufw status

This will show you the current state of the firewall and the rules in place. The output might look something like this:

Status: active
To                         Action      From
—                         ——      —-
OpenSSH                     ALLOW       Anywhere
OpenSSH (v6)                ALLOW       Anywhere (v6)

At this point, we can see that the firewall is active, but only SSH traffic is allowed. This means, right now, no NFS traffic is getting through. So while you can SSH into your server, the client won’t be able to access the shared directories via NFS. Let’s fix that!

Allowing NFS Traffic

If you’ve worked with firewalls before, you might be used to running commands like

sudo ufw app list

UFW (Uncomplicated Firewall) checks the /etc/services file to figure out which ports and protocols belong to which services. So, while NFS isn’t listed by default, we can still allow it by specifying it explicitly.

Here’s the key part: security best practices say you should be specific when allowing traffic. Instead of just letting NFS traffic from any source (which would be like leaving the door wide open for anyone), you’ll want to limit it to only the specific client machine that needs access. This adds an extra layer of security by making sure only your trusted client can access the shared directories.

To allow NFS traffic from your client server, use this command:

$ sudo ufw allow from client_ip to any port nfs

Just replace client_ip with the actual public IP address of your client server. This will open port 2049, the default port for NFS, and allow traffic from that specific client machine. Now, only that client can connect to the NFS shares, and no unauthorized machines will be able to get in.

Verifying the Changes

Once you’ve added the rule, it’s a good idea to double-check that everything’s working as expected. Run the

$ sudo ufw status

$ sudo ufw status

The output should now look something like this:

Status: active
To                         Action      From
—                         ——      —-
OpenSSH                     ALLOW       Anywhere
2049                        ALLOW       client_ip
OpenSSH (v6)                ALLOW       Anywhere (v6)

This confirms that the firewall is now allowing NFS traffic specifically from your client machine on port 2049. So now, the data flow between the two servers is both functional and secure—ensuring that only the right client can access the shared directories while blocking any unwanted external traffic.

And that’s it! You’ve set up your firewall to safely allow NFS traffic from the client machine, so now you’re ready to start working with those shared directories.

Step 5 — Creating Mount Points and Mounting Directories on the Client

Now that the host server is all set up and sharing its directories, it’s time to turn the spotlight on the client server. Here’s the picture: you’ve laid the groundwork, and now the client gets to step in and access those “treasures” (a.k.a. the shared directories) stored on the host server. The key here is “mounting.” Mounting is simply the process of making the directories from the host server show up on the client’s file system, so you can use them like they’re part of your own system. Pretty cool, right?

Preparing the Client: Creating Mount Points

Before we can start mounting, though, we need to do a little housekeeping. You’ll need to create some empty directories on the client machine where the shared directories from the host will live. Think of these as “parking spots” for the files you’ll be borrowing from the host.

Now, here’s a pro tip: if you try to mount an NFS share onto a directory that already has files in it, those files will vanish—they’ll be hidden as soon as the mount happens. So, it’s super important to make sure the “parking spots” are empty so nothing important gets lost.

To create the mount directories, just run these commands on your client:

sudo mkdir -p /nfs/general
sudo mkdir -p /nfs/home

These two commands will create the empty directories /nfs/general and /nfs/home. These will be the spots where you park the host server’s shared directories.

Mounting the Shares

Alright, now that your “parking spots” are ready, it’s time to actually mount the directories. You’ll use the host’s IP address and the path to the shared directories. It’s like saying to the client, “Hey, here’s the way to your new files!”

Run these commands on the client machine to make the connection:

sudo mount host_ip:/var/nfs/general /nfs/general
sudo mount host_ip:/home /nfs/home

Make sure to replace host_ip with the actual IP address of your host server. These commands basically tell the client, “Mount the /var/nfs/general and /home directories from the host server to the /nfs/general and /nfs/home directories on the client.”

Verifying the Mount

Once you’ve mounted the shares, it’s time to double-check that everything worked as expected. There are several ways to do this, but let’s go with the user-friendly approach: the df -h command. This command will show you how much space is available on your system and list all the mounted directories. It’s like checking a quick “map” to see if your files are exactly where they should be.

Run this command to check:

df -h

The output will look something like this:

Filesystem Size Used Avail Use% Mounted on
tmpfs 198M 972K 197M 1% /run
/dev/vda1 50G 3.5G 47G 7% /
tmpfs 989M 0 989M 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
/dev/vda15 105M 5.3M 100M 5% /boot/efi
tmpfs 198M 4.0K 198M 1% /run/user/1000
10.124.0.3:/var/nfs/general 25G 5.9G 19G 24% /nfs/general
10.124.0.3:/home 25G 5.9G 19G 24% /nfs/home

At the bottom of the output, you should see both /nfs/general and /nfs/home listed. These are the directories that have been successfully mounted from the host server. You’ll also see the size and usage for each mount, which confirms they’re working properly.

Checking Disk Usage of Mounted Directories

If you’re curious about how much space is actually being used inside each mounted directory, you can run the du (disk usage) command. This will give you a look inside your “parking spots” to see how much space they’re actually using.

To check the usage for /nfs/home, run this command:

du -sh /nfs/home

The output might look something like this:

36K /nfs/home

This means that the entire /home directory is only using 36K of space on the client machine. It’s a quick way to make sure the directory is mounted correctly and not taking up more space than expected.

And that’s it! You’ve now created the mount points, mounted the directories, and confirmed everything is working smoothly. You’re ready to start using your shared resources!

Using NFS for File Sharing

Step 6 — Testing NFS Access

Alright, now that you’ve done the hard work of setting everything up—configuring the server, creating mount points, and ensuring the firewall is in place—it’s time for the most satisfying part: testing whether everything actually works. You’ll want to make sure you can access those shared directories from the client machine and that you have the right permissions to read and write to them. It’s like checking the lights once you’ve finished installing a new piece of tech—got to make sure everything’s lit up and working!

Example 1: The General Purpose Share

Let’s kick things off by testing the General Purpose NFS share. We’re going to create a test file in the /var/nfs/general directory on the client machine. This will help you check if the share is set up correctly and accessible. To create the file, run this command:

$ sudo touch /nfs/general/general.test

This creates a blank file named general.test in the /nfs/general directory. Once the file is created, it’s time to check its ownership and permissions by running this command:

$ ls -l /nfs/general/general.test

Now, here’s what you should see in the output:

-rw-r–r– 1 nobody nogroup 0 Apr 18 00:02 /nfs/general/general.test

In this case, you’ll notice the file is owned by nobody:nogroup. So, why does it say that? Well, this happens because when you mounted the share, you didn’t change the default behavior of NFS. By default, NFS changes any root-level actions on the client into non-privileged actions on the host server. So, when you created the file as the root user on the client, it got assigned the ownership of nobody:nogroup.

Now, this isn’t a problem—it’s actually a security feature. With this setup, client superusers won’t be able to do things like change file ownership or create directories for a group of users on the mounted share. This ensures the host server stays secure, preventing root access from the client machine from interfering with the host’s system.

Example 2: The Home Directory Share

Next, we’ll test the Home Directory Share to see how it behaves compared to the General Purpose share. This time, let’s create a file in the /nfs/home directory on the client. Run the following command:

$ sudo touch /nfs/home/home.test

Then, check the file’s ownership by running:

$ ls -l /nfs/home/home.test

The output should look something like this:

-rw-r–r– 1 root root 0 Apr 18 00:03 /nfs/home/home.test

Here’s where things get interesting. Unlike the general.test file, this file is owned by root:root. So, what’s up with that? Well, remember when you set up the /home share, you used the no_root_squash option in the NFS export configuration. This special option disables the default behavior that maps root users on the client to non-privileged users on the host.

With no_root_squash enabled, root users on the client machine can act as root when accessing the /home directory on the host. This allows trusted administrators on the client machine to manage user accounts with root-level permissions, without needing full root access on the host server. It’s like giving a trusted admin the keys to a few locked doors, but still keeping the rest of the system secure.

Introduction to NFS Storage

Step 7 — Mounting the Remote NFS Directories at Boot

So, you’ve done all the hard work to get your NFS shares up and running, right? But now, there’s just a little housekeeping left to do—making sure those shares are automatically mounted every time your client server reboots. Imagine this: every time you restart your machine, the system comes back to life and automatically mounts all the directories it needs, just like magic. No more manual mounting each time; it’s all taken care of in the background. That’s what we’re going to set up.

Editing the /etc/fstab File

Here’s the thing: the secret to making this work is a file called /etc/fstab . This file is like the map that tells the system how to mount disk partitions and network file systems when the computer boots up. So, we’re going to add some lines to this file to make sure the NFS shares are automatically mounted.

To start, open the /etc/fstab file using a text editor with root privileges. The best tool for the job is nano (it’s simple and easy to use). Run this command:

$ sudo nano /etc/fstab

Once the file is open, scroll all the way to the bottom. This is where you’ll add the magic lines for the NFS shares you want to mount at boot. It’ll look something like this:

host_ip:/var/nfs/general /nfs/general nfs auto,nofail,noatime,nolock,intr,tcp,actimeo=1800 0 0
host_ip:/home /nfs/home nfs auto,nofail,noatime,nolock,intr,tcp,actimeo=1800 0 0

Make sure to replace host_ip with the actual IP address of your host server. This is where your NFS shares are coming from, and by adding this information, the client machine will know exactly where to look when it boots up.

Understanding the Options

Now, you might be wondering what those options mean. Here’s a quick rundown:

• auto : This one is pretty straightforward. It tells the system, “Hey, mount this share automatically when the system starts up.”
• nofail : This is a bit of a safety net. It ensures that if the NFS share isn’t available for some reason (maybe the network is down or the host is temporarily unreachable), the system won’t fail to boot. It keeps things running even if the NFS share isn’t there right away.
• noatime : This one’s for performance. It stops the system from updating the “last accessed” time of files on the NFS share every time they’re opened. It saves some unnecessary write operations and speeds things up.
• nolock : This disables file locking. Some environments don’t need it, and sometimes, file locking can cause issues, so this option is a way to turn it off if it’s not necessary.
• intr : This option lets the NFS mount be interrupted if the server is unresponsive. This is a lifesaver if something goes wrong, like a network failure—it stops the client from just hanging there forever.
• tcp : This forces the system to use TCP instead of UDP for communication. TCP is more reliable and ensures a stable connection between the client and server.
• actimeo=1800 : This one controls how long the client caches file attributes before checking the server for updates. The value 1800 means 30 minutes. It’s a way to balance performance with accuracy in terms of how up-to-date your data is.

Saving the Changes

After adding these lines to /etc/fstab , you’re almost there. Now, save the file and exit the editor. If you’re using nano, just press Ctrl + X to close it, then hit Y to confirm the changes, and press Enter to save.

Applying the Changes

Once you’ve updated the /etc/fstab file, the system will automatically mount the NFS shares at boot time. But, don’t expect instant magic—you might need to give it a moment for the network to connect and for the shares to appear after the system starts up. It’s like getting out of bed in the morning—sometimes, it takes a second to get moving.

Accessing the NFS Man Page

Curious about all the other options you can use in /etc/fstab ? No problem! The NFS manual page has all the details you need. To take a look, just run this command:

$ man nfs

This will bring up the manual, where you can dive deeper into all the available options and learn exactly how they work. It’s like having a guidebook for customizing your NFS setup to fit your specific needs.

And there you have

Step 8 — Unmounting an NFS Remote Share

Alright, so you’ve got your NFS shares up and running, and now, let’s say you don’t need them anymore. Whether you’re cleaning up or just making room for something else, you might want to unmount those remote shares. This step will help you remove those mounted directories from your system and regain full control over your local storage. Think of it like shutting down a program you no longer need—everything goes back to its original state.

Unmounting the NFS Shares

The first thing you need to do when unmounting an NFS share is make sure you’re not inside one of the mounted directories. You don’t want to be in the middle of a directory when you try to unmount it, trust me. So, step one: move out of the mounted directories. You can do this by navigating back to your home directory or anywhere that’s not part of the mounted share.

Run this command to get to your home directory:

$ cd ~

Now that you’re safely away from the mounted share, it’s time to use the umount command. Yep, you read that right: it’s umount , not unmount (I know, it’s one of those quirks that trips everyone up). This command is used to remove mounted file systems, and here’s how you do it:

$ sudo umount /nfs/home

$ sudo umount /nfs/general

By running these commands, you’ll disconnect the /nfs/home and /nfs/general directories from the system. They’ll no longer be accessible until you decide to mount them again.

Verifying the Unmount

Now that you’ve unmounted the directories, let’s make sure everything’s good. You don’t want to wonder whether the unmount was successful, right? So, check to see that those directories are really gone. You can do that with the df -h command, which gives you a snapshot of the available disk space and the mount points on your system.

Run the following command:

$ df -h

The output will look something like this:

Filesystem     Size  Used Avail Use% Mounted on
tmpfs          198M  972K  197M   1% /run
/dev/vda1      50G   3.5G   47G   7% /
tmpfs          989M     0  989M   0% /dev/shm
tmpfs          5.0M    0  5.0M   0% /run/lock
/dev/vda15     105M  5.3M  100M   5% /boot/efi
tmpfs          198M  4.0K  198M   1% /run/user/1000

If you look closely at the output, you’ll see that the previously mounted shares—like /nfs/home and /nfs/general —are no longer there. That means the unmount was successful, and your system is now free of those remote mounts.

Preventing Automatic Mounting at Boot

Now, let’s say you don’t want those NFS shares to pop up again the next time the system reboots. You know how some apps like to start themselves automatically on boot? Well, we’re going to make sure your NFS shares don’t do that. To prevent them from auto-mounting at boot, you’ll need to edit the /etc/fstab file.

Open up that file with root privileges using your preferred text editor (we’re sticking with nano for simplicity):

$ sudo nano /etc/fstab

Once it’s open, scroll down to find the lines that correspond to the NFS shares you no longer want to mount automatically. You have two options here:

• Delete the lines that correspond to the NFS shares.
• Or, comment them out by adding a # at the beginning of each line, like so:

# host_ip:/var/nfs/general /nfs/general nfs auto,nofail,noatime,nolock,intr,tcp,actimeo=1800 0 0
# host_ip:/home /nfs/home nfs auto,nofail,noatime,nolock,intr,tcp,actimeo=1800 0 0

Alternatively, if you want to keep the lines but just stop the shares from mounting automatically, you can remove the auto option from the configuration. This way, you’ll still be able to manually mount the shares when you need them but won’t have to worry about them showing up on every reboot.

Once you’ve made your changes, save the file and exit the editor. If you’re using nano, press Ctrl + X , then press Y to confirm the changes, and hit Enter to save.

Now, when the system restarts, the NFS shares won’t be mounted automatically. You’ve got full control over when those shares appear on your system. Nice job!

By following these steps, you’ve successfully unmounted the NFS shares and ensured they won’t sneak back onto your system without your permission. You’re now the boss of your file system!

NFS Security Guide (2025)

Conclusion

In conclusion, setting up NFS on Debian 11 enables seamless file sharing between remote servers, simplifying data access across your network. By following the steps outlined in this guide, you can easily install the necessary NFS packages, configure shared directories, and ensure the proper mounting of shares on both the host and client systems. With a focus on security, we’ve also covered configuring firewall rules and automating NFS mounts at boot. Whether you’re managing NFS mounts for everyday tasks or troubleshooting access, these steps provide a solid foundation for using NFS on Debian 11. Looking ahead, as network technologies evolve, staying up-to-date on NFS features and security practices will ensure your server setups remain efficient and secure.

Master LAMP Stack Installation: Setup Linux, Apache, MariaDB, PHP on Debian 10 (2025)