NFS Mounts from serverb

mount.nfs - a hands-on Linux lab on a real virtual machine.

Mount an NFS export from a provided server, the client side of the EX200 file-systems objective. Discover exports with showmount -e SERVER, mount now with mount -t nfs SERVER:/export /mnt/nfs, verify with findmnt (the type resolves to nfs4), read a file straight over the wire, and write the persistent fstab line SERVER:/export /mnt/nfs nfs defaults 0 0. On RHEL 10 the old _netdev option is no longer needed, but after editing /etc/fstab you must run systemctl daemon-reload then mount -a to test the line before rebooting. On the exam the server is content.lab.example.net or serverb; you never configure the server, only the client.

The exam hands you a task that sounds impossible at first: mount a directory that is not on your machine at all. It lives on a server across the network, content.lab.example.net, and you are told to make its files show up on YOUR system at /mnt/nfs, both right now and again after a reboot. You cannot touch the server. It is already set up. Everything you do happens on the client, and the clock is running.

This is an NFS task, and there is at least one on every exam. NFS, the Network File System, lets a remote directory appear as an ordinary folder on your machine. You cd into it, ls it, cat a file, and the bytes travel over the network without you thinking about it. This lesson teaches the client side end to end. You discover what the server offers, mount it now, read a file across the wire, and write the one fstab line that makes the mount survive a reboot.

The black boxes below are a practice terminal: a safe sandbox that checks the one command each step teaches. The outputs are from a real RHEL 10 machine (AlmaLinux 10.2). To capture true NFS output without a second host, the export was served on the same machine over a loopback, so you will see localhost in the discovery and mount lines. On the exam the server is named, usually content.lab.example.net or serverb, and you type that name in place of localhost. The SHAPE is identical either way.

A server chooses directories to share and publishes them; each shared directory is called an export. Your machine, the client, attaches an export to a local mount point, an empty directory you pick, such as /mnt/nfs. After the mount, that empty directory is a window onto the server's files.

Think of it like plugging in a network drive. The files physically live on the server. Your system treats them as if they were sitting on a local disk. Three moves make it work: find the export, mount it, and (for the exam) pin it in /etc/fstab so it comes back after a reboot. On the exam the server is already exporting; you never configure the server, only the client.

Red Hat splits the work deliberately. Standing up an NFS server is a separate discipline; the RHCSA tests whether you can be handed a working server and consume it correctly under time pressure. So the objective reads "mount and unmount network file systems using NFS," and every piece of it happens on your machine.

One tool must be present for any of this: the nfs-utils package, which provides the mount.nfs helper and showmount. On an exam machine it is normally already installed, but if a mount fails with a missing-helper error, dnf install -y nfs-utils is the fix. With that in place, the first real move is discovery.

Before you can mount anything, you need to know what the server offers. showmount -e SERVER asks the server for its export list: every directory it shares and who is allowed to mount it. This is how you learn the exact export path to hand to mount.

Before you run it, decide what you expect: a list, one line per export, each showing a path and the clients allowed to reach it. Point it at the server:

showmount -e localhost

prompt: [root@servera ~]# answer: showmount -e localhost output: Export list for localhost: /srv/nfsshare * hint: The tool is showmount with the -e flag and the server name: showmount -e localhost

The server exports /srv/nfsshare, and the * means any client may mount it. That export path is the exact string you feed to mount. On the exam you run showmount -e content.lab.example.net and read its list the same way. If showmount instead hangs or errors, the usual causes are a firewall on the server or a wrong server name, but on the RHCSA the server is provided and reachable, so a clean list like this is what you get.

Here the server reads localhost because the export was served on the same machine to capture real output. On the exam you substitute the given server name, usually content.lab.example.net or serverb, and the export path (/srv/nfsshare here) will be whatever that server publishes. Read the path off showmount; never assume it.

You have the export path. Now attach it to a local mount point. First make the mount point if it does not exist (mkdir -p /mnt/nfs), then mount the export onto it. The command names the filesystem type with -t nfs, then SERVER:/export, then the local directory:

mount -t nfs localhost:/srv/nfsshare /mnt/nfs

prompt: [root@servera ~]# answer: mount -t nfs localhost:/srv/nfsshare /mnt/nfs output: hint: Name the type with -t nfs, then server:export, then the mount point: mount -t nfs localhost:/srv/nfsshare /mnt/nfs

No output, which is success: the export is now mounted at /mnt/nfs. The syntax to burn in is SERVER:/export, a colon joining the server name to the export path, with no space. This mount is live but temporary. It vanishes at the next reboot, exactly like a bare mount of a local disk. Proving it works comes next, and making it survive a reboot comes after that.

A mount that returns no error still deserves a check. findmnt reads the live mount table and shows a mount's target, its source, and its filesystem type. Hand it the mount point and read the type field closely.

findmnt /mnt/nfs

prompt: [root@servera ~]# answer: findmnt /mnt/nfs output: /mnt/nfs localhost:/srv/nfsshare nfs4 hint: findmnt takes the mount point as its argument: findmnt /mnt/nfs

The source is localhost:/srv/nfsshare, the target is /mnt/nfs, and the type reads nfs4, not plain nfs. That is expected: you asked for -t nfs and RHEL 10 negotiated NFS version 4, the modern default, so the kernel reports the resolved type nfs4. Seeing nfs4 here is the sign the mount succeeded over a real NFSv4 connection. You write nfs in commands and fstab; the system resolves it to nfs4 under the hood.

The whole point is that remote files behave like local ones. With the export mounted, reading a file inside /mnt/nfs fetches it from the server transparently. There is a sentinel file in this share; read it with plain cat:

cat /mnt/nfs/hello.txt

prompt: [root@servera ~]# answer: cat /mnt/nfs/hello.txt output: shared file from the server hint: Just cat the file inside the mount point: cat /mnt/nfs/hello.txt

shared file from the server. That text lives on the server, not on your disk, yet cat read it with no special syntax at all. That is NFS doing its job: once mounted, the remote directory is just another folder. Anything you would do to a local file, ls, cat, cp, and (if the export allows it) writing, works the same inside /mnt/nfs.

The filename hello.txt and its contents are this capture's. On the exam the export will hold whatever files the server publishes; use ls /mnt/nfs to see them, then read the one the task points you at. What is stable is the move: once mounted, ordinary file commands work straight against the mount point.

A live mount is worth zero points after the reboot that grades your work. To make it persistent you add one line to /etc/fstab. The six fields are the same as any mount, but the device field is SERVER:/export and the type is nfs. For the exam server the line reads:

content.lab.example.net:/exports /mnt/nfs nfs defaults 0 0

prompt: [root@servera ~]# answer: echo "content.lab.example.net:/exports /mnt/nfs nfs defaults 0 0" >> /etc/fstab output: hint: Echo the six-field NFS line and append it with >> to /etc/fstab: echo "content.lab.example.net:/exports /mnt/nfs nfs defaults 0 0" >> /etc/fstab

The device field content.lab.example.net:/exports is the server-and-export pair, the type is nfs (the system still resolves it to nfs4 at mount time), and defaults covers the options. Note what is NOT here: on RHEL 10 you no longer need the old _netdev option that earlier releases required to delay the mount until the network was up. RHEL 10 handles NFS ordering for you, so defaults is enough. Writing the line is not the same as it working, though. Two steps stand between this and a safe reboot.

On RHEL 10, after editing /etc/fstab you must run systemctl daemon-reload so the systemd generator re-reads the file, then mount -a to test the new line while the system is still up. If mount -a prints nothing, the line is good; if it errors, fix it NOW, not after a reboot. Skipping the test is how a bad NFS line drops the machine into emergency mode. This same daemon-reload rule applies to every fstab edit on RHEL 10.

Scaffolding off. No command is printed this time. You have every piece you need.

You just ran mount -t nfs against the export and it returned without an error, but a silent return is not proof. You want to read the live mount table for the mount point /mnt/nfs and see its source and its resolved filesystem type in one line, so you can confirm the NFS mount really took. Which single command shows that?

prompt: [root@servera ~]# answer: findmnt /mnt/nfs output: /mnt/nfs localhost:/srv/nfsshare nfs4 hint: It is the mount-table reader from earlier, given the mount point. The tool is findmnt.

findmnt /mnt/nfs prints the target, the SERVER:/export source, and the type nfs4, all in one line. That resolved nfs4 is your confirmation the mount is live over real NFSv4. It is the fastest honest check that a network mount took: not "the command returned," but "the kernel shows it mounted, and here is the type."

You earned this cheat sheet. Every row is a form you just ran or built:

The two things to burn in for the exam: the mount syntax is SERVER:/export joined by a colon, and after adding the fstab line on RHEL 10 you run systemctl daemon-reload then mount -a BEFORE you trust it. RHEL 10 dropped the _netdev requirement, so a plain defaults line is correct.

Read the export path off showmount -e SERVER rather than guessing it; the server publishes the exact string, and mismatched paths are the most common NFS mount failure. If a share is non-critical and you would rather the machine boot even when the server is unreachable, add nofail to the options field so a missing export cannot strand the boot.

The practice terminal has walked you through the full NFS client loop: showmount -e to discover the export, mount -t nfs SERVER:/export /mnt/nfs to attach it, findmnt to confirm the type resolved to nfs4, cat to read a file straight off the server, and the six-field fstab line (no _netdev on RHEL 10) that makes it persist. Every one of those you typed yourself.

The file-systems module mission is where you run these against a real RHEL 10 machine with a provided NFS server. A full VM boots for you, the server is already exporting, and the mission hands you objectives that use exactly what you practiced here: discover an export, mount it, read from it, and pin it in fstab so it survives a reboot. One difference from this lesson: the mission shows no commands. You read the objective, recall the SERVER:/export syntax and the daemon-reload then mount -a ritual, and type it. That recall is what makes it stick on exam day.

Finish the other file-systems lessons, then go mount a real server's export and make it outlive a reboot.

Practice NFS Mounts from serverb in a real Linux terminal at The Linux Camp. Progress is verified automatically as you type commands on the machine.