Rocky 9 mounting NFS: the client view and root squash

Test scope

The server was an AlmaLinux 9.8 host (nfs-server exporting /srv/nfslab via /etc/exports.d/lab.exports); the client was a Rocky Linux 9.8 privileged container (host kernel 5.14.0-687.54.1.el9_8, --network host). Executed: mount -t nfs 127.0.0.1:/srv/nfslab, findmnt, reading a server-side file, creating a new file, ls -l, umount, and confirming the file on the server. Log: plans/content-expansion/evidence/logs/rocky-nfs-mount.log.

Client and server sit on the same machine (loopback), so cross-host firewalls and latency were not tested.

Mount: check which version is negotiated

sudo mkdir -p /mnt/nfslab
sudo mount -t nfs 127.0.0.1:/srv/nfslab /mnt/nfslab
findmnt -no SOURCE,FSTYPE,TARGET /mnt/nfslab

127.0.0.1:/srv/nfslab nfs4   /mnt/nfslab

Without a version, -t nfs negotiates nfs4. Pin it with -o vers=4.2 or vers=3; v3 also needs rpcbind/mountd ports open on the server.

Read: confirm server data is visible

cat /mnt/nfslab/from-server.txt

hello from server

Write: why the new file belongs to nobody

echo client-write > /mnt/nfslab/from-client.txt
ls -l /mnt/nfslab/

-rw-r--r-- 1 nobody nobody 13 Oct 19 16:01 from-client.txt
-rw-r--r-- 1 root   root   18 Oct 19 15:53 from-server.txt

The client process is root (root inside the container), but the export line has no no_root_squash, so the server maps the client’s root to nobody by default. The file therefore belongs to nobody — that is NFS security working, not a permissions bug.

Only add no_root_squash when the workload truly needs root preserved; the cost is that client root equals server root.

Confirm on the server

cat /srv/nfslab/from-client.txt

client-write

Seeing the client’s content on the server proves both the mount and write permissions; verifying on both sides beats trusting a successful mount.

Common traps

• Cross-host mount times out: the server has not allowed nfs (2049/tcp); v3 also needs mountd/rpc-bind. A loopback test cannot reveal this;
• Write fails with Permission denied: directory permissions or export options (ro, root mapping);
• Ignoring the negotiated version: -t nfs defaults to nfs4; an old server that only speaks v3 needs -o vers=3.

Practice: mount and verify read/write

sudo dnf install -y nfs-utils
sudo mkdir -p /mnt/nfslab
sudo mount -t nfs <server>:/srv/nfslab /mnt/nfslab
findmnt -no FSTYPE /mnt/nfslab           # expected nfs4
ls /mnt/nfslab
echo test > /mnt/nfslab/from-client.txt
sudo umount /mnt/nfslab

Checks:

1. findmnt shows nfs4
2. The server’s pre-placed file is readable
3. The new file appears on the server (owner may be nobody)
4. After unmounting, findmnt /mnt/nfslab prints nothing

FAQ

常见问题

Why are files created through the mount owned by nobody?

The export uses root_squash by default, mapping the client root to nobody. Add no_root_squash when root must be preserved, knowing it gives the client root authority on the server.

Loopback mount works but another host times out?

Loopback bypasses the firewall. Open nfs (2049/tcp) on the server, plus mountd/rpc-bind for v3; start with firewall-cmd --add-service=nfs.

How do I pin the NFS version?

Pass -o vers=4.2 or vers=3 explicitly. The default negotiates (usually 4.x); pinning helps troubleshooting but the server must support the version.

Next steps

• Growing storage: LVM growth
• XFS repair: Repairing a damaged XFS
• Post-install checks: 7 checks after install