RHEL NFS and Samba File Services

Anil Jalela · Published Sep 3, 2026 · 7 min read

A network share combines storage, protocol, identity mapping, access policy, firewall, SELinux, name service, locking and client caching. A successful mount does not prove correct authorization, and root on a client does not automatically equal root on the server. Select NFS for Unix-oriented shared files and Samba when SMB interoperability and Windows identity behavior are required; do not run both over one tree without a deliberate locking and permission design.

Choose protocol and identity before configuration

NFSv4 uses a pseudo-filesystem and stateful protocol behavior; export options and identity mapping must match the trust model. Samba maps SMB identities and permissions through its security mode, passdb or directory integration and filesystem ACLs. Manage Samba through supported configuration files, validation commands and approved automation.

IP-based export restrictions do not authenticate a person. Kerberos-backed NFS or directory-integrated SMB may be required for stronger identity. Protect data in transit and at rest according to classification.

Build an evidence map

Operating sequence

1. Define clients, identities, data ownership, protocol and recovery expectations.
2. Prepare a dedicated filesystem path with least-privilege owner, group and ACL.
3. Assign the documented SELinux context/boolean for the intended service.
4. Create one source-scoped export or share and validate configuration.
5. Open only the named firewalld service for the approved zone/source.
6. Mount/connect from an intended client and test create/read/update/rename/lock.
7. Test an unapproved identity/source and a server restart or network interruption.

Commands and expected evidence

exportfs -v
exportfs -rav
showmount -e server.example 2>/dev/null
findmnt -t nfs,nfs4
nfsstat -m
smbd -b 2>/dev/null | head
testparm -s
smbclient -L //server.example -U labuser
smbstatus
getfacl -p /srv/share
ls -ldZ /srv/share
firewall-cmd --list-services

• showmount has protocol/version limits and is not a complete NFSv4 authorization test.
• Validate Samba configuration with testparm, then test the actual identity and share operation.
• Avoid empty Samba passwords and guest write access for business data.
• Use stable mount dependencies and automount where appropriate instead of hiding required-share failures.

Evidence and acceptance criteria

Worked operating scenario

An NFS client can mount a share but an application cannot write. The directory is group-writable, yet the client UID maps to another server identity and SELinux labels the custom path for unrelated content. Widening the mode would not correct either issue.

The team reconciles authoritative UID/GID mapping, assigns the service-specific persistent file context, restores labels and tests as the actual application account. An unapproved account remains denied.

Practical how-to cases

sudo dnf install -y nfs-utils
sudo install -d -m 2770 -o root -g shared /srv/nfs/project
printf '/srv/nfs/project 192.0.2.0/24(rw,sync,root_squash)\n' | sudo tee /etc/exports.d/project.exports
sudo exportfs -rav
sudo exportfs -v
sudo firewall-cmd --permanent --add-service=nfs

sudo mount -t nfs4 servera:/srv/nfs/project /mnt/project
findmnt /mnt/project
touch /mnt/project/client-test
printf 'servera:/srv/nfs/project /mnt/project nfs4 rw,_netdev,x-systemd.automount 0 0\n' | sudo tee -a /etc/fstab
sudo findmnt --verify

sudo dnf install -y samba samba-client
sudo testparm -s
sudo smbpasswd -a student
sudo semanage fcontext -a -t samba_share_t '/srv/samba/project(/.*)?'
sudo restorecon -RFv /srv/samba/project
sudo firewall-cmd --permanent --add-service=samba
sudo systemctl enable --now smb

testparm -s
smbclient -L //servera -U student
smbclient //servera/project -U student -c 'ls; put test.txt; ls'
namei -om /srv/samba/project
ls -ldZ /srv/samba/project

Independent practice tasks

1. Build an NFS read-only export and verify root squashing.
2. Configure autofs for an indirect NFS map.
3. Create a group-writable Samba share and test two users.
4. Diagnose a share that lists successfully but denies file creation.

For this lesson on RHEL NFS and Samba Services, complete each task without copying the worked command sequence. Record the initial state, exact change, verification, negative test and recovery command. A task is unfinished if it works now but does not survive a reboot where persistence is required.

Troubleshooting by symptom

Unsafe operations and recovery boundaries

• Unsafe: exporting / or broad writable trees expands compromise and deletion scope.
• Unsafe: no_root_squash lets client root act as server root on exported data and requires an exceptional trust design.
• Unsafe: combining NFS and SMB access to the same application data without tested locking/identity semantics risks corruption.

Rewritten knowledge checks

Guided lab and acceptance test

1. Create a dedicated lab data path and group.
2. Configure either one source-scoped NFS export or authenticated Samba share.
3. Apply correct SELinux and firewalld controls.
4. Connect from an approved client and test file lifecycle and locking.
5. Test denied identity/source and capture server logs.
6. Remove client mount, service configuration and lab data in dependency order.

Primary references

• RHEL 10 configuring and using network file services
• RHEL 10 documentation
• RHEL 9 documentation