Introduction
Setting up NFS (Network File System) on Rocky Linux 9 allows seamless sharing of directories between a server and client. By configuring NFS, you can efficiently manage networked file access and storage across systems. This step-by-step guide will walk you through installing NFS utilities, configuring shared directories, and ensuring smooth mounting and unmounting of shares. Whether you’re managing a small network or setting up enterprise-level systems, mastering NFS on Rocky Linux 9 can enhance your file management capabilities. Let’s dive into the essential steps for setting up NFS on your system.
What is Network File System (NFS)?
NFS is a system that lets you share files and directories between different computers over a network. It allows one computer (the host) to make its files accessible to others (the clients), so they can manage or store data remotely. This system is useful for regularly accessing shared resources and managing storage across multiple devices.
Step 1 — Downloading and Installing the Components
Alright, so here’s where the fun begins! You’re about to kick off the setup by getting the essential parts that make nfs work smoothly on both your host and client servers running Rocky Linux . Think of these components like the glue that keeps shared folders connected across your network — they’re what make your systems talk to each other efficiently.
On the Host
Let’s start with your host server, which is basically the “main character” in this setup. This is the machine that’ll share its directories with others — the one that says, “Hey, I’ve got files, come grab them!” To do that, you’ll need to install the nfs-utils package using the dnf package manager. That’s where all the cool NFS tools live. Here’s the command to run:
$ sudo dnf install nfs-utils
This command grabs everything you need, downloads it, and installs all the bits and pieces that help your host share files safely and efficiently. Once it’s done, your host is officially NFS-ready — ready to start exporting shared directories like a pro.
When you’re done with that, you can move over to your client system. This is the machine that’ll reach out and mount those shared folders from the host.
On the Client
Now switch gears to your client server — this is the computer that’s going to connect to the host and use those shared directories. It’s kind of like setting up a receiver for the files you just shared. To keep both systems in sync and ensure they understand each other, you’ll need to install the same nfs-utils package here too.
Run this command on your client:
$ sudo dnf install nfs-utils
By doing this, your client gets all the tools it needs to connect, mount, and manage NFS shares like a champ. You’ll now have commands to mount directories, check connections, and even manage permissions across systems — everything you need for a smooth nfs experience on Rocky Linux .
Once both the host and client have these packages installed, you’re all set with the foundation. Both systems are now on the same page, ready to talk to each other over the network. From here, you can move on to the next exciting part — configuring how they share directories, setting up access permissions, and creating a secure way to let the data flow seamlessly between them.
Read more about installing and configuring NFS on Rocky Linux Install and Configure NFS Server on Rocky Linux
Step 2 — Creating the Share Directories on the Host
Alright, here’s where you start setting things up on your Rocky Linux host to make the nfs magic happen. You’re going to build two separate directories here, and each one shows a different way to deal with those all-powerful superuser privileges when working with shared folders. Think of it as learning how to share files safely without letting anyone accidentally mess things up. The goal is to understand how nfs handles admin-level access across systems that need to share files.
Now, superusers — or as we like to call them, root users — are basically the bosses of the system. They can do anything, anywhere, anytime. But here’s the catch: when you mount directories over nfs, those directories technically belong to another system. For safety reasons, the nfs server says, “Hold on, root, you’re not the boss here!” So, it doesn’t let superuser actions from a client run directly on the host. That means if you’re logged in as root on a client machine, you won’t be able to do things like write files as root, change file ownership, or edit protected directories inside the nfs mount.
But sometimes, you might have trusted admins on client machines who need a bit more control to do their job properly. In those cases, you can tweak your nfs server’s configuration to give them those extra powers. Just keep in mind, this also opens the door a little wider for security risks — like the chance that someone could take advantage of that access and gain root-level control over your host system. So, it’s a bit of a balancing act between convenience and safety.
Example 1: Exporting a General-Purpose Mount
Let’s kick things off with the first example. You’re going to make a general-purpose nfs mount that uses nfs’s default security settings. These defaults keep root users on client systems from pulling any admin-level tricks on your host. This kind of setup works great for shared folders in group projects, where people might upload and edit files together — like team docs, project folders, or even shared directories for web apps such as content management systems.
Start by creating the directory you’ll be sharing. You can use the -p flag with mkdir , which tells it to make the whole path if it doesn’t already exist:
$ sudo mkdir /var/nfs/general -p
Since you’re using sudo , the directory will belong to the root user on your host machine. You can double-check that by listing the details like this:
$ ls -dl /var/nfs/general
Output:
drwxr-xr-x 2 root root 4096 Apr 17 23:51 /var/nfs/general
By default, nfs has a neat safety trick — it changes any root actions from a client into actions by a special “nobody” user. This keeps those powerful client-side root privileges from touching sensitive data on the host. So, before you share this directory, you’ll want to give ownership to that “nobody” user to make sure it’s ready for shared access:
$ sudo chown nobody /var/nfs/general
Once you’ve updated the ownership, your directory is officially ready to be shared. You can now export it as an nfs share, making it safe and accessible for client systems to mount and use without putting your host’s security at risk.
Example 2: Exporting the Home Directory
Now let’s move on to something a little different — exporting the /home directory. This time, you’re setting things up so that the nfs server shares the home directories of your users stored on the host. The idea is to let people log in from different client machines and still have access to their personal files, no matter which system they’re using. It’s super handy in environments where users bounce between multiple servers but want their stuff to follow them.
The /home directory already exists on your Rocky Linux system, so you don’t need to create a new one.
And whatever you do, don’t change its permissions. Messing with those could cause all kinds of chaos for users who rely on their current folder setups and file ownership.
By setting up these two directories — one general-purpose share and one for home directories — you’re laying down the groundwork to see how nfs manages permissions and superuser behavior between client and host systems. The first example gives you a secure, default setup, while the second one shows you how to make things more flexible when client-side admins need extra control. Both approaches give you valuable insights into how nfs works under Rocky Linux in real-world use cases.
Read more about creating and managing shared directories on a server Network File System — Documentation for Rocky Linux
Step 2 — Creating the Share Directories on the Host
Alright, let’s get things rolling on your Rocky Linux setup with nfs! In this step, you’ll be creating two separate directories on your host machine. Each one is going to show you a different way to handle superuser privileges when working with shared folders. Think of it like testing two security setups to see how permissions play out when files are shared across systems.
Superusers, often called root users, are basically the all-powerful administrators who can do anything on a system. But here’s the twist — when you’re working with nfs , any directory you mount technically belongs to another system. Because of that, the nfs server plays it safe. It doesn’t let superuser actions from a client happen directly on the host. In plain English, if you’re logged in as root on your client machine, you won’t be able to do stuff like write files as root, change who owns files, or mess with protected folders inside your mounted nfs share.
Now, sometimes you’ve got trusted admins on the client side who need that extra access to manage files properly. In those situations, you can configure your nfs server to give them the permissions they need. But fair warning — doing that opens up a little security risk. There’s always a chance that someone sneaky could abuse that access and get root-level control of your host system. So, while it’s powerful, it’s something to use carefully.
Example 1: Exporting a General-Purpose Mount
Let’s start with the first setup. Here, you’ll make a general-purpose nfs mount that sticks to the default nfs security behavior. This setup keeps root users on the client from using their admin powers to change things on your host. It’s perfect for shared spaces where multiple people are working together — maybe uploading files, editing project folders, or running web apps like content management systems that need access to shared storage.
To kick things off, create the directory you want to share. Use the -p flag with mkdir to make sure it builds the whole path if it doesn’t already exist:
$ sudo mkdir /var/nfs/general -p
Since you used sudo , the directory will belong to the root user on your host. You can check the ownership and permissions by running:
$ ls -dl /var/nfs/general
Output
drwxr-xr-x 2 root root 4096 Apr 17 23:51 /var/nfs/general
By default, nfs has a neat security rule — it translates any root actions done on the client into actions performed by the “nobody” user. This prevents root users on the client from doing anything too powerful on your host. To get this directory ready for sharing, you’ll need to switch its ownership to “nobody,” which represents anonymous access in nfs . Here’s how you do it:
$ sudo chown nobody /var/nfs/general
Once you’ve updated the ownership, this directory is ready to be shared safely as an nfs export. That means client systems can mount it and use it without compromising the host’s security.
Example 2: Exporting the Home Directory
Next up, let’s talk about exporting the /home directory. This time, the goal is to make user home directories stored on your host available to your client machines. The cool part? Admins on the clients will have just enough power to manage user files effectively without going overboard. This is super handy in multi-server environments where users log in from different systems but still need to access their personal files, no matter which machine they’re on.
The /home directory already exists on your Rocky Linux system, so no need to make a new one.
Don’t touch its permissions. Changing them could cause serious headaches for users who rely on their home folders being set up in a specific way.
By setting up both directories — the general-purpose one and the /home one — you’re building a solid foundation for understanding how nfs manages permissions and superuser behavior. The first setup shows you how to keep things locked down, while the second gives a bit more flexibility for trusted admins. Together, they show how nfs balances security and convenience on Rocky Linux systems that need to share files across networks.
Learn more about configuring NFS exports in Linux environments 10 Practical Examples to Export NFS Shares in Linux
Step 2 — Creating the Share Directories on the Host
Okay, so here’s the fun part of setting up your nfs environment on Rocky Linux. You’re going to make two different directories on your host machine, and each one shows a unique way to handle superuser permissions. Think of it as a little experiment to see how nfs deals with admin powers when files are being shared between systems.
Now, let’s talk about superusers — you know, the root users who basically have the keys to the entire system. They can do anything they want, whenever they want. But when you mount directories through nfs, there’s a twist. Those directories technically belong to another computer, so the nfs server gets a bit protective. For safety, it won’t let superuser commands from a client directly affect the host. That means even if you’re root on your client machine, you won’t be able to pull off root-level actions like creating files as root, changing who owns them, or tinkering with protected directories inside the mounted share.
But here’s the thing — sometimes you trust the admin on the client side. Maybe they’re responsible and just need a bit more access to do their job right. In that case, you can tweak your nfs server setup to allow those higher privileges. Just keep in mind that you’re opening a door that could, in theory, let a bad actor sneak in and get root access to your host system. So it’s a tradeoff between convenience and safety.
Example 1: Exporting a General-Purpose Mount
Alright, let’s start simple. In this first example, you’ll make a general-purpose nfs mount that sticks to the default nfs security rules. This setup keeps root users on the client from pulling any admin stunts on the host. It’s a great choice for shared spaces where lots of people are working together — like folders where teams upload project files or web apps dump their content, such as content management systems.
Start by creating the directory you want to share. Use the -p flag with mkdir just in case some parts of the path don’t exist yet — it’ll build them for you:
$ sudo mkdir /var/nfs/general -p
Since you ran this with sudo , the directory now belongs to the root user on your host system. You can double-check that by listing its details:
$ ls -dl /var/nfs/general
Output:
drwxr-xr-x 2 root root 4096 Apr 17 23:51 /var/nfs/general
Here’s what’s happening next. By default, nfs is smart — it automatically changes any root actions on the client into actions by a special “nobody” user. This stops anyone with root access on the client from messing with sensitive stuff on your host. To get this directory ready for sharing, you’ll just need to hand over ownership to that “nobody” user, which represents anonymous access in nfs.
$ sudo chown nobody /var/nfs/general
And that’s it! The directory is now ready to be shared safely. Once it’s exported, client machines can mount it and start using it without putting your host system at risk.
Example 2: Exporting the Home Directory
Next up, let’s take it up a notch. In this example, you’re going to configure your nfs server to share the /home directory. The idea here is to let users on client machines access their home folders stored on the host — pretty handy when users log into different servers but still need the same files everywhere they go. This setup also gives admins on client systems enough freedom to manage user files easily.
Since /home already exists on your Rocky Linux host, you don’t need to make a new one.
Don’t touch the permissions on this folder. Changing them could create serious issues for users who rely on their home directories working correctly.
Keeping the permissions as they are ensures that everyone can still access their own files without breaking anything.
So now you’ve got two directories — a general-purpose share and a home directory share. Together, they’ll help you see how nfs handles permissions and superuser behavior between client and host machines. The first example shows you the standard, safe setup, while the second one gives you a look at a more flexible configuration that allows client-side admin access when it’s needed. Both setups are super useful depending on your environment and trust level between systems.
Read more about configuring firewall settings for NFS on Rocky Linux Configuring firewalld for NFS Connections on Linux
Step 5 — Creating Mount Points and Mounting Directories on the Client
Now that your host server is all set up and sharing its nfs directories, it’s time to prepare the client machine. This step is where your Rocky Linux client learns how to reach out and actually use those shared folders. Think of it like connecting your computer to a shared drive so you can read, write, and manage files as if they were sitting right there on your own system.
To make the shared folders accessible, you’ll need to mount them from the host onto the client machine. Basically, you’re attaching remote directories to local ones so they appear as part of your file system. But here’s a key detail — always make sure you’re mounting onto empty directories. Otherwise, anything already inside those folders gets hidden once the nfs mount takes over.
If there are already files or folders inside your mount point, those items will seem to disappear after the mount operation because the shared nfs directory will sit right on top of it. Don’t panic — they’re not deleted, just hidden. To avoid confusion or unintentional data loss, double-check that your mount directories are empty before you start.
Let’s create the mount points. You’ll need two directories on your client machine — one for each share you created earlier on the host. The -p flag makes sure the entire folder path is created if it doesn’t already exist:
$ sudo mkdir -p /nfs/general
$ sudo mkdir -p /nfs/home
These two directories will act as the landing spots for your nfs shares. The /nfs/general directory connects to your general-purpose share, and /nfs/home links to the shared home directories from the host.
Once those directories are in place, and you’ve verified your firewall rules are allowing traffic between the host and the client, it’s time to mount the shared folders. To do that, use your host server’s IP address along with the paths of the exported directories:
$ sudo mount host_ip:/var/nfs/general /nfs/general
$ sudo mount host_ip:/home /nfs/home
What these commands do is pretty cool — they form a bridge between your client and host systems, so the host’s shared directories are now available right inside your client’s file system.
Now, let’s make sure everything worked. You can check your mounted file systems using mount or findmnt , but a friendlier way to see what’s going on is by using df -h . It shows disk usage in a nice, easy-to-read format:
$ df -h
Output:
Filesystem Size Used Avail Use% Mounted on
devtmpfs 370M 0 370M 0% /dev
tmpfs 405M 0 405M 0% /dev/shm
tmpfs 405M 11M 394M 3% /run
tmpfs 405M 0 405M 0% /sys/fs/cgroup
/dev/vda1 25G 1.5G 24G 6% /
tmpfs 81M 0 81M 0% /run/user/0
host_ip:/var/nfs/general 25G 1.6G 24G 7% /nfs/general
host_ip:/home 25G 1.6G 24G 7% /nfs/home
If you look toward the bottom, you’ll see both of your nfs shares successfully mounted under /nfs/general and /nfs/home . You’ll also notice that their sizes and usage are the same — that’s because they both come from the same file system on the host.
And just like that, your Rocky Linux client is now fully connected to the nfs server’s shared directories. You can browse, read, or write to those folders as if they were on your local machine. It’s seamless file sharing made simple, all powered by nfs .
Read more about mounting NFS shares on Linux clients How to Mount an NFS Share in Linux
Step 6 — Testing NFS Access
Alright, now that your nfs shares are up and running, it’s time to make sure everything is working the way it should. This step is all about testing your setup on Rocky Linux to confirm that file permissions, ownership, and access behave correctly between your host and client machines. Basically, we’re going to play around a bit to see if the permissions are doing what we expect.
Example 1: The General Purpose Share
Let’s start by checking out the general-purpose nfs share. This one uses the default nfs behavior, which doesn’t let root users on the client do admin-level stuff on the host’s file system. So, here’s what you’ll do: create a new test file in the /nfs/general directory using sudo.
$ sudo touch /nfs/general/general.test
Now, take a look at who owns that file by running:
$ ls -l /nfs/general/general.test
Output
-rw-r–r–. 1 nobody nobody 0 Aug 8 18:24 /nfs/general/general.test
See what happened? The file belongs to the user and group “nobody.” That’s nfs doing its thing — whenever a root user on the client tries to act on the share, nfs automatically switches that to the “nobody” user for safety. This cool feature is called root squashing. It’s basically nfs’s way of saying, “Sorry, root, not today!”
Because of this, even if you’re the superuser on the client, you can’t pull off your usual admin tricks like changing file owners, making protected folders, or editing system-level stuff inside the share. This setup is perfect for shared spaces where multiple users work together, and you don’t want anyone with local admin powers to accidentally break things or mess with the host’s data.
Example 2: The Home Directory Share
Now let’s move on to the second one — the shared home directory. This one’s a bit different because it was set up with the no_root_squash option. What that means is that root users on the client actually keep their root powers when working inside this share.
Go ahead and try it by making another test file, this time in the /nfs/home directory.
$ sudo touch /nfs/home/home.test
Once that’s done, check who owns it:
$ ls -l /nfs/home/home.test
Output
-rw-r–r–. 1 root root 0 Aug 8 18:26 /nfs/home/home.test
Now that’s interesting, right? You used the same command as before, but this time, the file is owned by “root.” That’s because the no_root_squash setting lets the client’s root account act like root on the host file system too. It’s super handy for admins who need full control — like when you’re managing user files, fixing permissions, or moving home directories around between servers.
Be cautious when using no_root_squash since it grants full root privileges to the client machine — only enable it in trusted environments.
Just keep in mind, while this setup makes life easier for system administrators, it also comes with a bit of risk. Giving root-level access to clients means there’s more power — and as we all know, with great power comes great responsibility. So, use it wisely!
After you’ve run both tests, you’ll see that everything’s working exactly as intended. The general-purpose share
Read more about verifying NFS share accessibility and permissions How to Test if an NFS Server is Accessible (LinuxIntro)
Step 7 — Mounting the Remote NFS Directories at Boot
Sometimes it’s just nice when things take care of themselves, right? In this case, you can make your nfs shares on Rocky Linux mount automatically every time the client system boots. That way, you don’t have to manually remount them after every restart. It’s a simple tweak that saves time and keeps everything running smoothly for users or services that rely on those shared folders.
Here’s the plan — you’ll set things up so that your nfs mounts load automatically at startup. All you need to do is add them to the /etc/fstab configuration file on your client machine.
First, open the file with root privileges using your favorite text editor. I’ll use nano here because it’s simple and gets the job done:
$ sudo nano /etc/fstab
Once the file is open, scroll to the bottom and add a line for each of your nfs shares. Each line tells your system which remote directory to mount, where to mount it locally, and what options to use. Here’s what those entries should look like:
/etc/fstab
. . .
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
Each of these options plays a specific role, and together they make sure your mounts are both reliable and fast. Let’s break them down a bit:
- auto — Automatically mounts the nfs share when your system boots up.
- nofail — Keeps the boot process going even if the nfs share isn’t available yet, which is super handy for network setups.
- noatime — Speeds things up by skipping file access time updates.
- nolock — Turns off file locking when you don’t need it, which helps reduce possible delays.
- intr — Lets you interrupt nfs operations if the server ever becomes unresponsive.
- tcp — Makes sure nfs uses TCP for more stable data transfers.
- actimeo=1800 — Sets the cache timeout to 30 minutes (that’s 1800 seconds), giving you a nice balance between speed and keeping your data fresh.
Once you’ve added those lines, save the file and close it. From now on, every time your client starts, it’ll automatically mount the nfs shares for you.
When your system boots, it might take a few seconds before the NFS server connects. Don’t worry if things don’t appear instantly — your client just needs a moment to establish a network connection before mounting the shares.
And there you have it! You’ve now automated your nfs setup on Rocky Linux , so everything connects on its own. No more manual mounting after every reboot — just a seamless, hands-free experience every time your system starts up.
Read more about setting up automatic NFS mounts at boot on Linux Configuring a File System to Automatically Mount (Linux Instances)
Step 8 — Unmounting an NFS Remote Share
So, let’s say you’re done working with your nfs shares on Rocky Linux, and you don’t need those remote directories connected anymore. No problem — you can safely disconnect them, but first, make sure you’re not currently inside one of those mounted folders. It’s like trying to take out a USB drive while still browsing its files — it won’t end well.
So, switch to your home directory first and then use the umount command like this:
$ cd ~
$ sudo umount /nfs/home
$ sudo umount /nfs/general
Oh, and here’s a small but classic Linux quirk — the command is umount , not unmount . Yeah, it’s missing that “n.” Don’t worry, you’re not typing it wrong — that’s just how Linux rolls. The umount command disconnects your nfs shares from the client, cutting off access to those remote folders.
After unmounting, only your local drives will show up. To double-check that the nfs directories are really gone, use the df -h command to see your current mounted filesystems:
$ df -h
Output
Filesystem Size Used Avail Use% Mounted on
devtmpfs 370M 0 370M 0% /dev
tmpfs 405M 0 405M 0% /dev/shm
tmpfs 405M 11M 394M 3% /run
tmpfs 405M 0 405M 0% /sys/fs/cgroup
/dev/vda1 25G 1.5G 24G 6% /
tmpfs 81M 0 81M 0% /run/user/0
See? No /nfs/home or /nfs/general listed anymore — that means your nfs shares have been completely disconnected, leaving only your local storage visible.
Now, if you’d like to stop these directories from automatically remounting the next time you reboot, you can tweak the /etc/fstab file. Open it with elevated permissions using your favorite editor — here’s an example with nano :
$ sudo nano /etc/fstab
Inside the file, find the lines that reference your nfs shares and comment them out by adding a # at the start of each one, 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
If you don’t want to disable them completely but would rather mount them manually later, you can just remove the auto option instead. That way, the configuration stays, but nothing mounts automatically when you reboot — handy if you only need these connections occasionally.
By managing your nfs mounts this way, you stay in full control of when and how your remote directories are connected. It’s a great way to keep your Rocky Linux system clean, fast, and flexible while still being ready to reattach your shares whenever you need them.
Read more about safely disconnecting NFS shares from client systems Unmounting NFS Shares in Linux: A Comprehensive Guide
Conclusion
In conclusion, setting up NFS on Rocky Linux 9 is a straightforward yet powerful way to share directories between a server and client. By following this step-by-step guide, you can efficiently configure NFS, ensure secure access, and automate the mounting of directories, providing seamless network storage. From installing NFS utilities to testing access and managing firewall settings, this process ensures smooth and reliable file sharing across systems. As NFS continues to evolve, staying updated with the latest best practices for security and performance will further enhance your system’s file-sharing capabilities on Rocky Linux.
For further details on the process, explore more about setting up NFS on Rocky Linux 9 for optimized performance.
