RED HAT ENTERPRISE LINUX

NFS & Automounter

Accessing Network-Attached Storage

CIS238RH | RHEL System Administration 2
Mesa Community College

Welcome to this essential module on Network File System (NFS) and the automounter in Red Hat Enterprise Linux. NFS is the standard protocol for sharing filesystems across Unix and Linux systems. It allows you to access remote storage as if it were local - users and applications work with files without knowing they are on a different server. You will learn two approaches to mounting NFS shares: manual mounting, where you explicitly mount and unmount shares; and automounting, where the system automatically mounts shares on demand when accessed and unmounts them after a period of inactivity. Automounting is particularly useful for home directories, where users only connect when needed, reducing server load and improving reliability. These are fundamental RHCSA objectives and essential skills for enterprise Linux administration.

Learning Objectives

Understand NFS concepts

How NFS works, exports, clients, and versions

Mount NFS shares manually

Use mount command and /etc/fstab for persistent mounts

Configure the automounter (autofs)

Set up on-demand mounting with master and map files

Troubleshoot NFS access issues

Diagnose connectivity, permissions, and mount problems

We have four main learning objectives. First, you will understand NFS concepts - how the protocol works, what exports and clients are, and the differences between NFS versions. This foundation helps you troubleshoot and make good configuration decisions. Second, you will mount NFS shares manually using the mount command for immediate access and /etc/fstab for mounts that persist across reboots. This is the traditional approach used for always-needed storage. Third, you will configure the automounter using autofs. This service mounts shares on demand when users access them and unmounts after inactivity. It is the preferred method for home directories and optional shares. Fourth, you will troubleshoot NFS access issues - working through connectivity problems, permission errors, and mount failures systematically.

What is NFS?

Network File System (NFS) is a distributed filesystem protocol that allows clients to access files over a network as if they were on local storage. Developed by Sun Microsystems, it is the standard for Unix/Linux file sharing.

NFS Server
Exports /shared

↔

Network
NFS Protocol

↔

NFS Client
Mounts to /mnt/data

Server (Exports)

Shares directories for remote access. Controls who can connect and what permissions they have.

Client (Mounts)

Connects to server exports and mounts them locally. Users access files transparently.

NFS - Network File System - is the standard way to share filesystems across Unix and Linux networks. It has been around since the 1980s and remains the go-to solution for Linux-to-Linux file sharing. The model is simple: a server exports directories, making them available on the network. Clients mount those exports, attaching them to their local filesystem. Once mounted, applications and users access files normally - they do not need to know the files are remote. NFS is transparent to applications. A program opening /mnt/data/file.txt does not know whether that is local storage or an NFS mount. This transparency is powerful - you can move storage to a server without changing how applications work. The server controls access through exports, specifying which clients can connect and what permissions they get (read-only or read-write). The client then mounts the export to a local directory, making the remote files accessible.

NFS Versions

Version	Features	Status
NFSv3	Stateless, UDP/TCP, widely compatible	Legacy, still supported
NFSv4	Stateful, TCP only, single port (2049), built-in security	Current default in RHEL
NFSv4.1	Parallel NFS (pNFS), session trunking	Supported, enterprise features
NFSv4.2	Server-side copy, sparse files, space reservation	Latest, RHEL 8/9 default

# Check which NFS version is being used
[root@client ~]# nfsstat -m
/mnt/data from server:/export
 Flags: rw,relatime,vers=4.2,rsize=1048576,wsize=1048576...

# Force specific version when mounting
[root@client ~]# mount -t nfs -o vers=4.2 server:/export /mnt/data
[root@client ~]# mount -t nfs -o nfsvers=3 server:/export /mnt/legacy

RHEL default: NFSv4.2 is the default in RHEL 8 and 9. It uses only TCP port 2049, simplifying firewall configuration compared to NFSv3.

NFS has evolved through several versions, each adding features and improving security. NFSv3 is the legacy version. It is stateless, meaning the server does not track client connections. It can use UDP or TCP and requires multiple ports including portmapper, making firewall configuration complex. It is still supported for compatibility. NFSv4 is the modern version and the RHEL default. It is stateful - the server tracks client sessions. It uses only TCP port 2049, dramatically simplifying firewalls. It has built-in security features and better performance. NFSv4.1 added parallel NFS for high-performance storage systems. NFSv4.2 added server-side copy (efficient file copies without transferring data through the client) and other optimizations. Use nfsstat -m to see what version a mounted share is using. You can force a specific version with the vers= or nfsvers= mount option. Generally, use the default NFSv4.2 unless you have compatibility requirements.

Discovering Exports

Before mounting, you need to know what the server exports. Use showmount to query available exports from an NFS server.

# List exports from an NFS server
[root@client ~]# showmount -e nfsserver.example.com
Export list for nfsserver.example.com:
/export/data    192.168.1.0/24
/export/home    *.example.com
/export/public  *

# Install nfs-utils if showmount not found
[root@client ~]# dnf install nfs-utils

# Show clients currently mounting from a server
[root@client ~]# showmount -a nfsserver.example.com
All mount points on nfsserver.example.com:
192.168.1.100:/export/data
192.168.1.101:/export/home

# NFSv4 note: showmount may not work with NFSv4-only servers
# NFSv4 uses different discovery mechanism

NFSv4 note: showmount uses NFSv3 protocol. Pure NFSv4 servers may not respond. Try mounting the root export (server:/) and browsing.

Before you can mount an NFS share, you need to know what the server exports. The showmount command queries an NFS server for its export list. showmount -e SERVER shows what directories the server exports and who can access them. The access specifications vary - they might be IP ranges, hostnames, wildcards, or asterisks for everyone. showmount -a shows which clients are currently mounting from the server - useful for server administrators. The nfs-utils package provides showmount and other NFS client tools. Install it if the commands are not available. Important caveat: showmount uses the NFSv3 mount protocol. If a server is configured for NFSv4 only, showmount may not work. In that case, try mounting the server root (server:/) and list directories to see what is available, or ask the server administrator for export information. For exam and production purposes, always verify you can reach the server before spending time troubleshooting mount issues.

Manual Mounting

Use the mount command to immediately attach an NFS export to your filesystem. This is temporary - the mount is lost on reboot.

mount -t nfs [options] server:/export /mountpoint

# Basic NFS mount
[root@client ~]# mount -t nfs server:/export/data /mnt/data

# Create mount point if it does not exist
[root@client ~]# mkdir -p /mnt/data
[root@client ~]# mount -t nfs server:/export/data /mnt/data

# Verify the mount
[root@client ~]# mount | grep nfs
server:/export/data on /mnt/data type nfs4 (rw,relatime,vers=4.2...)

[root@client ~]# df -h /mnt/data
Filesystem           Size  Used Avail Use% Mounted on
server:/export/data   50G   10G   40G  20% /mnt/data

# Access files
[root@client ~]# ls /mnt/data
file1.txt  file2.txt  project/

Manual mounting with the mount command is the most direct way to access NFS shares. The syntax is mount -t nfs server:/export /mountpoint. The -t nfs specifies the filesystem type, though mount can often detect this automatically. The server:/export part specifies the NFS server hostname or IP and the exported path. The mountpoint is where you want to access the files locally. The mountpoint directory must exist before mounting. Create it with mkdir if needed. After mounting, verify with mount | grep nfs or df -h. You should see the remote filesystem with its size and usage. Files are now accessible at the mountpoint just like local files. This mount is temporary - it will not survive a reboot or unmount command. For persistent mounts, you need to add an entry to /etc/fstab, which we will cover next.

Mount Options

# Read-write mount (default)
[root@client ~]# mount -t nfs -o rw server:/export /mnt/data

# Read-only mount
[root@client ~]# mount -t nfs -o ro server:/export /mnt/readonly

# Specify NFS version
[root@client ~]# mount -t nfs -o vers=4.2 server:/export /mnt/data

# Soft mount with timeout (returns error if server unavailable)
[root@client ~]# mount -t nfs -o soft,timeo=30 server:/export /mnt/data

# Hard mount (default - keeps retrying forever)
[root@client ~]# mount -t nfs -o hard server:/export /mnt/data

# Background mount (useful in fstab - does not block boot)
[root@client ~]# mount -t nfs -o bg server:/export /mnt/data

# Combined options
[root@client ~]# mount -t nfs -o rw,vers=4.2,soft,timeo=30 server:/export /mnt/data

Option	Description
rw / ro	Read-write or read-only access
hard / soft	Retry forever (hard) or return error (soft) if server down
bg	Background retry if initial mount fails
timeo=N	Timeout in tenths of seconds
vers=N	NFS version (3, 4, 4.1, 4.2)
sec=MODE	Security mode (sys, krb5, krb5i, krb5p)

Mount options control how NFS behaves. Let me explain the important ones. rw and ro control read-write versus read-only access. Even if the server allows read-write, you can mount read-only for safety. hard versus soft is important for availability. Hard mounts (the default) keep retrying if the server becomes unavailable. Processes hang until the server returns. Soft mounts return an error after timeout - processes get an error but do not hang. For critical data, hard is safer. For less critical data where you prefer errors over hangs, use soft. bg (background) is useful for fstab entries. If the server is unavailable at boot, bg lets the boot continue and retries in the background. Without this, a missing NFS server can hang your boot. timeo sets the timeout for soft mounts in tenths of seconds. vers forces a specific NFS version. sec specifies security - sys is standard Unix permissions, krb5 variants use Kerberos for authentication and encryption. Multiple options are comma-separated. Common combinations are rw,bg,soft,timeo=30 for user data or rw,hard for critical application data.

Persistent Mounts: /etc/fstab

Add entries to /etc/fstab for NFS mounts that should persist across reboots. The system mounts these automatically during boot.

# /etc/fstab format:
# device              mountpoint    type  options         dump pass

# Basic NFS mount in fstab
server:/export/data   /mnt/data     nfs   defaults        0    0

# With recommended options
server:/export/data   /mnt/data     nfs   rw,bg,soft      0    0

# Read-only mount
server:/export/docs   /mnt/docs     nfs   ro,bg           0    0

# Home directories with specific version
nfs.example.com:/home /home         nfs   rw,bg,vers=4.2  0    0

# Test fstab entry without rebooting
[root@client ~]# mount /mnt/data
# Or mount all fstab entries
[root@client ~]# mount -a

Always test! After editing fstab, run mount -a to test. A bad fstab entry can prevent the system from booting properly.

For mounts that should survive reboots, add entries to /etc/fstab. This file tells the system what to mount at boot time. The fstab format has six fields: device (server:/export for NFS), mount point, filesystem type (nfs), options, dump (0 for NFS), and pass (0 for NFS - no fsck needed). For NFS in fstab, always include the bg option. This prevents boot hangs if the NFS server is unavailable - the mount retries in background while boot continues. The soft option with timeout also helps - failed mounts return errors rather than hanging forever. Set dump and pass to 0 for NFS. These are for local filesystem backup and fsck ordering, which do not apply to network mounts. After editing fstab, always test before rebooting. Run mount /mountpoint to mount just that entry, or mount -a to mount all fstab entries. If there are errors, fix them before rebooting. A broken fstab entry can drop your system to emergency mode or hang the boot process.

Unmounting NFS

# Unmount an NFS share
[root@client ~]# umount /mnt/data

# If busy, find what is using it
[root@client ~]# umount /mnt/data
umount: /mnt/data: target is busy.

[root@client ~]# fuser -mv /mnt/data
                     USER        PID ACCESS COMMAND
/mnt/data:           root     kernel mount /mnt/data
                     alice      1234 ..c.. bash
                     alice      1235 ..c.. vim

# Options when busy:
# 1. Close applications using the mount
# 2. Change directory away from mount
# 3. Lazy unmount (detach now, cleanup when idle)
[root@client ~]# umount -l /mnt/data

# 4. Force unmount (may cause data loss!)
[root@client ~]# umount -f /mnt/data

# Show all NFS mounts
[root@client ~]# mount -t nfs,nfs4

Caution: Force unmount (-f) can cause data loss if there are pending writes. Use only when necessary.

Unmounting NFS shares uses the standard umount command. Simply run umount /mountpoint. If the mount is busy - processes have files open or working directories in the mount - umount fails with target is busy. Use fuser -mv to see what processes are using the mount. The output shows users, PIDs, and commands. Common causes are shells with current directory in the mount, open files, or running programs. To unmount a busy filesystem, you have options. Best practice is to close the applications and change directories away. If that is not possible, lazy unmount (umount -l) detaches the filesystem from the directory tree immediately but waits for actual cleanup until all references are gone. Processes already using it can continue until they close files. Force unmount (umount -f) is the nuclear option. It forces immediate unmount even with open files. This can cause data loss if writes were pending and should only be used when the server is unreachable and lazy unmount is not working. To see all current NFS mounts, use mount -t nfs,nfs4.

The Automounter

autofs (automounter) mounts NFS shares on-demand when accessed and unmounts them after a period of inactivity. This reduces server load and improves reliability.

Manual/fstab Mounts

Always connected
Uses server resources continuously
Boot fails if server unavailable
Good for always-needed storage

Automounter (autofs)

Mounts on access
Unmounts after idle timeout
Boot succeeds without server
Good for home dirs, optional shares

# Install autofs
[root@client ~]# dnf install autofs

# Enable and start the service
[root@client ~]# systemctl enable --now autofs

The automounter, implemented by the autofs service, provides on-demand mounting. Instead of mounting everything at boot and keeping it mounted, autofs waits until someone actually accesses the mount point. Then it mounts the share. After a period of inactivity (default 5 minutes), it unmounts automatically. This has several advantages. Server resources are conserved - if nobody is using the share, there is no connection. Boot reliability improves - if an NFS server is down, boot succeeds and mounts happen later when accessed. It scales better - a server with 1000 potential clients but only 50 active users maintains 50 connections, not 1000. Automounting is particularly good for home directories. Users get their home directories mounted when they log in and unmounted when idle. It is also good for optional shares that are not always needed. Install autofs from the autofs package. Enable and start the autofs service with systemctl. The configuration uses map files that tell autofs what to mount and where.

Autofs Architecture

/etc/auto.master
Master map

→

/etc/auto.misc
Map file

→

Mount on access

# Master map: /etc/auto.master (or /etc/auto.master.d/*.autofs)
# Format: mountpoint    map-file    [options]
/misc    /etc/auto.misc
/home    /etc/auto.home

# Map file: /etc/auto.misc
# Format: key    [options]    server:/export
data     -rw,soft    server:/export/data
docs     -ro         server:/export/docs

# Result: accessing /misc/data triggers mount of server:/export/data

How it works: The master map defines base directories and points to map files. Map files define what gets mounted under each base directory. Access triggers mount.

Autofs uses a two-level configuration: the master map and individual map files. The master map (/etc/auto.master) defines base mount points and which map file controls them. Each line has a mount point and a map file path. Optionally, you can add default options. Map files (like /etc/auto.misc) define the actual mounts. Each line has a key (subdirectory name), options, and the NFS server:/export to mount. When you access a path like /misc/data, autofs looks in the master map, finds /misc points to /etc/auto.misc, then looks in that map file for data, and mounts server:/export/data to /misc/data. The key insight is that autofs creates directories on-demand. You do not need to create /misc/data manually - autofs creates it when mounting and removes it when unmounting. The base directory (/misc) must be managed by autofs - do not manually create subdirectories there.

Direct vs Indirect Maps

Indirect Maps

Mount point is base directory + key

# auto.master
/data   /etc/auto.data

# auto.data
projects  server:/export/proj
archive   server:/export/archive

# Results in:
# /data/projects
# /data/archive

Direct Maps

Mount point is the full path (key)

# auto.master
/-      /etc/auto.direct

# auto.direct
/mnt/data     server:/export/data
/opt/shared   server:/export/shared

# Results in:
# /mnt/data
# /opt/shared

When to use: Indirect maps for organizing multiple mounts under one directory (home dirs, project shares). Direct maps for specific paths that cannot be reorganized.

Autofs supports two types of maps: indirect and direct. Indirect maps are the most common. The master map specifies a base directory, and map file keys become subdirectories. If /data points to auto.data and auto.data has projects, the mount appears at /data/projects. Indirect maps are great for organizing related mounts - all project shares under /projects, all home directories under /home. Direct maps use /- as the master map entry, meaning there is no base directory. The keys in the map file are full absolute paths. Each key becomes an independent mount point. Direct maps are useful when you need mounts at specific locations that cannot be reorganized - perhaps /mnt/data or /opt/shared where applications expect specific paths. The trade-off: indirect maps are simpler and keep related mounts organized. Direct maps are more flexible but require full paths for each mount. For home directories and typical file server access, indirect maps are preferred.

Configuring Indirect Maps

# Step 1: Edit master map - add entry for /shares base directory
[root@client ~]# vi /etc/auto.master.d/shares.autofs
/shares    /etc/auto.shares

# Step 2: Create the map file
[root@client ~]# vi /etc/auto.shares
data       -rw,soft,timeo=30    nfsserver:/export/data
documents  -ro                   nfsserver:/export/docs
projects   -rw                   nfsserver:/export/projects

# Step 3: Reload autofs to pick up changes
[root@client ~]# systemctl reload autofs

# Step 4: Test - just access the directory!
[root@client ~]# ls /shares/data
file1.txt  file2.txt  subdir/

# Check that it mounted
[root@client ~]# mount | grep shares
nfsserver:/export/data on /shares/data type nfs4 ...

# After 5 minutes idle, it auto-unmounts

Let me walk through configuring an indirect map step by step. Step 1: Add a master map entry. Rather than editing auto.master directly, create a file in /etc/auto.master.d/ with .autofs extension. This is cleaner and survives package updates. The entry specifies /shares as the base directory and /etc/auto.shares as the map file. Step 2: Create the map file. Each line has: key (subdirectory name), options (prefixed with dash), and server:/export. The key data means access via /shares/data. Options -rw,soft,timeo=30 set read-write, soft mount with 30 decisecond timeout. Step 3: Reload autofs to read the new configuration. Use systemctl reload autofs - no need for full restart. Step 4: Test by simply accessing the directory. Run ls /shares/data. Autofs detects the access, mounts the share, and returns the listing. Check with mount command to verify. After the idle timeout (default 300 seconds / 5 minutes), autofs automatically unmounts. Access it again and it remounts transparently.

Configuring Direct Maps

# Step 1: Create direct map entry in master map
[root@client ~]# vi /etc/auto.master.d/direct.autofs
/-    /etc/auto.direct

# Step 2: Create direct map file with full paths
[root@client ~]# vi /etc/auto.direct
/mnt/nfsdata       -rw,soft    nfsserver:/export/data
/opt/shared        -ro         nfsserver:/export/shared
/var/log/remote    -ro         logserver:/logs

# Step 3: Create the mount point directories
[root@client ~]# mkdir -p /mnt/nfsdata /opt/shared /var/log/remote

# Step 4: Reload autofs
[root@client ~]# systemctl reload autofs

# Step 5: Test
[root@client ~]# ls /mnt/nfsdata
file1.txt  file2.txt

[root@client ~]# ls /var/log/remote
server1.log  server2.log

Note: For direct maps, the mount point directories must exist. autofs does not create them automatically like it does for indirect maps.

Direct maps work differently from indirect maps. The master map entry uses /- instead of a base directory, telling autofs this is a direct map. The map file contains full absolute paths as keys, not just subdirectory names. Each entry specifies exactly where the mount should appear. An important difference: with direct maps, you must create the mount point directories yourself. Autofs manages what gets mounted there, but the directories need to exist. With indirect maps, autofs creates and removes subdirectories automatically. Direct maps are useful when you need mounts at specific locations - /mnt/data because scripts expect it there, /opt/shared because an application looks for it there. You cannot reorganize these under a common base directory. After creating the master map entry, map file, and directories, reload autofs and test by accessing the paths. Each mount happens independently when accessed. The advantage of direct maps is flexibility in mount locations. The disadvantage is more configuration and manual directory management.

Automounting Home Directories

Automounting home directories is a common use case. Users get their home mounted when they log in, unmounted when idle. The wildcard * handles any username.

# Master map entry for home directories
[root@client ~]# vi /etc/auto.master.d/home.autofs
/home    /etc/auto.home

# Map file using wildcard for any user
[root@client ~]# vi /etc/auto.home
*    -rw    nfsserver:/home/&

# The * matches any username
# The & substitutes the matched key (username)
# /home/alice -> nfsserver:/home/alice
# /home/bob   -> nfsserver:/home/bob

# Reload and test
[root@client ~]# systemctl reload autofs
[root@client ~]# su - alice
[alice@client ~]$ pwd
/home/alice

Wildcard: The * matches any key. The & in the source substitutes that matched value. Together they handle unlimited users with one line.

Automounting home directories is one of the most valuable uses of autofs. In an enterprise environment, user home directories are stored on a central NFS server. When users log into any client, their home is automatically mounted. The configuration uses wildcards. The asterisk in the map file matches any subdirectory name - any username. The ampersand in the server path substitutes whatever was matched. So when alice logs in, accessing /home/alice triggers autofs. The asterisk matches alice, the ampersand becomes alice, and nfsserver:/home/alice is mounted to /home/alice. This single line handles every user. When alice logs out and her home is idle for the timeout period, it unmounts. When she logs in again, it remounts. This scales beautifully - thousands of users, one line of configuration. Note that /home must be managed entirely by autofs when using this configuration. Do not mix local home directories with autofs - either all homes are autofs or none are.

Autofs Options

# Default timeout is 300 seconds (5 minutes)
# Change in /etc/autofs.conf or /etc/sysconfig/autofs
[root@client ~]# vi /etc/autofs.conf
timeout = 600    # 10 minutes

# Or set per-mount timeout in map file
data    -rw,soft,--timeout=120    server:/export/data

# Browse mode - show directories before mounting
# In auto.master:
/shares    /etc/auto.shares    --browse

# Now ls /shares shows entries without mounting them
[root@client ~]# ls /shares
data  documents  projects

# Check autofs status and mounts
[root@client ~]# systemctl status autofs
[root@client ~]# automount -m    # Show configured maps

Browse mode: The --browse option creates ghost directories so ls shows available mounts without triggering them. Actual mount happens on access.

Autofs behavior can be tuned with various options. The timeout controls how long after last access before unmounting. Default is 300 seconds (5 minutes). Increase for frequently used but intermittently accessed shares. The global timeout is set in /etc/autofs.conf. Per-mount timeout uses --timeout=SECONDS in the map file options. Browse mode is useful for discoverability. Normally, ls on the base directory does not show the possible mounts - they do not exist until accessed. With --browse in the master map, autofs creates ghost directories. ls shows what could be mounted, but actual mounting happens only on real access (like reading files). The automount -m command shows all configured maps and their entries - useful for verifying configuration. Other useful options include logging verbosity for troubleshooting and map source types for LDAP-based maps in larger environments.

Troubleshooting NFS

# Check if NFS server is reachable
[root@client ~]# ping nfsserver
[root@client ~]# showmount -e nfsserver

# Check NFS client services
[root@client ~]# systemctl status nfs-client.target

# Test mount manually first
[root@client ~]# mount -t nfs nfsserver:/export/data /mnt/test
# If this fails, autofs will fail too

# Check firewall (client needs outbound to 2049)
[root@client ~]# firewall-cmd --list-all
# Server needs to allow port 2049/tcp inbound

# Verbose mount for debugging
[root@client ~]# mount -t nfs -v nfsserver:/export/data /mnt/test

# Check RPC services
[root@client ~]# rpcinfo -p nfsserver

# SELinux - check for denials
[root@client ~]# ausearch -m avc -ts recent | grep nfs

When NFS mounts fail, troubleshoot systematically. First, verify basic connectivity. Can you ping the server? Can showmount see the exports? If showmount fails, the problem is connectivity, DNS, or the server. Check that NFS client services are active. nfs-client.target should be enabled for NFS functionality. Test with a manual mount command before blaming autofs. If manual mount fails, fix that first. Add -v for verbose output showing what mount is attempting. Check firewalls on both sides. NFSv4 needs TCP port 2049. The client needs outbound access, the server needs inbound. NFSv3 needs additional ports. rpcinfo -p shows what RPC services the server is offering. If NFS is not listed, the server has a configuration problem. SELinux can block NFS in certain scenarios. Check for AVC denials with ausearch. Common issues: wrong server name, export does not exist, client not in export access list, firewall blocking, server not running NFS services.

Troubleshooting Autofs

# Check autofs service status
[root@client ~]# systemctl status autofs
● autofs.service - Automounts filesystems on demand
     Active: active (running)

# View autofs logs
[root@client ~]# journalctl -u autofs

# Enable verbose logging
[root@client ~]# vi /etc/sysconfig/autofs
LOGGING="verbose"
[root@client ~]# systemctl restart autofs

# Check map configuration
[root@client ~]# automount -m
autofs dump map information
...
/shares:
  data | -rw,soft | nfsserver:/export/data

# Common issues:
# - Typo in map file syntax
# - Missing reload after config change
# - Base directory owned by wrong user
# - Underlying NFS issue (test with manual mount)

# Force expire (unmount) all autofs mounts
[root@client ~]# automount -f

When autofs specifically is not working, check these things. First, is the autofs service running? Check with systemctl status. If not running, start it and check for errors. View autofs logs with journalctl -u autofs. This shows mount attempts, successes, and failures. For more detail, enable verbose logging in /etc/sysconfig/autofs and restart. automount -m dumps the parsed map configuration. This shows exactly what autofs thinks the configuration is. Compare against your map files to spot typos or syntax errors. Common autofs issues include syntax errors in map files (wrong format, missing dashes before options), forgetting to reload after configuration changes, and permissions issues on base directories. The most important debugging step is testing the underlying NFS mount manually. Run mount -t nfs server:/export /mnt/test. If this fails, the problem is NFS, not autofs. Fix NFS first, then autofs will work.

Security Considerations

NFS traditionally relies on IP-based trust. Any root user on a trusted client appears as root on the NFS server unless precautions are taken.

# Server-side export options (on NFS server)
/export/data    192.168.1.0/24(rw,sync,root_squash)

# root_squash (default): remote root -> nobody user
# no_root_squash: remote root stays root (dangerous!)
# all_squash: all remote users -> nobody

# Client mount with Kerberos security
[root@client ~]# mount -t nfs -o sec=krb5p server:/export /mnt/secure

# sec options:
# sec=sys     - Standard Unix auth (default)
# sec=krb5    - Kerberos authentication
# sec=krb5i   - Kerberos with integrity checking
# sec=krb5p   - Kerberos with privacy (encryption)

Enterprise environments: Use NFSv4 with Kerberos (krb5p) for authenticated and encrypted NFS in security-sensitive environments.

NFS security requires careful consideration. Traditional NFS trusts client systems - if your client machine says you are user alice (UID 1000), the server believes it. This means any root user on a client could potentially impersonate any user. root_squash is the default and critical protection. It maps remote root users to the nobody user, preventing remote root from having root access on the NFS server. Never use no_root_squash in production unless absolutely necessary. all_squash maps everyone to nobody - useful for public read-only exports. For stronger security, NFSv4 with Kerberos provides actual authentication. sec=krb5 authenticates users against Kerberos. sec=krb5i adds integrity checking to detect tampering. sec=krb5p adds encryption for full privacy. Setting up Kerberos NFS requires a working Kerberos infrastructure, which is beyond RHCSA scope but important for enterprise environments. At minimum, use NFSv4, restrict exports to specific networks, and keep root_squash enabled.

Best Practices

Do

Use autofs for home directories and optional shares
Use fstab with bg option for always-needed mounts
Test fstab entries with mount -a before reboot
Use NFSv4 unless legacy compatibility required
Verify exports with showmount before troubleshooting
Use soft mounts for non-critical data
Document NFS dependencies for applications
Monitor NFS performance in production

Do Not

Use hard mounts without bg in fstab (boot hangs)
Skip testing after configuration changes
Use no_root_squash in production
Mix autofs and manual management of same path
Forget to reload autofs after map changes
Force unmount unless absolutely necessary
Assume NFS works without testing connectivity
Ignore timeout tuning for your workload

Rule of thumb: Use autofs for user-facing shares (home dirs, project folders). Use fstab for system-level persistent storage that applications depend on.

Let me summarize best practices for NFS and automounting. Use autofs for anything user-facing - home directories, project shares, optional resources. Users get mounts when needed, resources are freed when idle, and boot does not depend on NFS servers. Use fstab for system-level storage that must always be available - application data directories, shared configurations. Always include bg option so boot continues if server is temporarily unavailable. Always test before rebooting. For fstab, run mount -a. For autofs, reload and access the paths. A configuration error discovered after reboot is painful to fix. Use NFSv4 for its simpler firewall requirements and better security. Fall back to NFSv3 only for legacy compatibility. Never disable root_squash on production exports. Never mix autofs management and manual management on the same path - pick one approach. Do not force unmount unless you understand the data loss risk. Monitor NFS in production - performance issues can cascade to applications.

Key Takeaways

NFS Basics: Server exports directories, clients mount them. Use showmount -e to discover exports.

Manual Mounting: mount -t nfs server:/export /mnt. Use /etc/fstab with bg option for persistent mounts.

Automounter: Configure in /etc/auto.master and map files. Use wildcards (* and &) for home directories.

Troubleshooting: Test NFS manually first. Check connectivity, firewall, and autofs logs. Reload autofs after changes.

Let me summarize the essential NFS and automounter skills. NFS fundamentals: servers export directories, clients mount them. The server controls access through export options. Use showmount -e to see what a server offers before attempting mounts. Manual mounting uses the mount command for immediate access and /etc/fstab for persistence. Always use the bg option in fstab to prevent boot hangs. Test with mount -a before rebooting. The automounter (autofs) provides on-demand mounting. Configure through auto.master and map files. Indirect maps organize mounts under a base directory. Direct maps specify exact paths. Wildcards with asterisk and ampersand handle unlimited entries like home directories. Troubleshooting starts with basics: can you ping the server? Can showmount see exports? Does manual mount work? Then check autofs configuration, reload, and check logs.

LAB EXERCISES

Mount an NFS share manually and verify access
Add persistent NFS mount to /etc/fstab with appropriate options
Configure autofs indirect map for shared directories
Set up autofs wildcard map for home directories
Configure autofs direct map for specific paths
Troubleshoot a failing NFS mount (connectivity, exports, autofs)

Next: Installing Red Hat Enterprise Linux