# NFS

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/nfs

## Quick definition

NFS lets you share files between computers on a network. One computer, called the server, makes folders available. Other computers, called clients, can then open and work with those files as if they were stored locally on their own machine. This makes sharing data across different devices simple and efficient.

## Simple meaning

Imagine you work in an office with several coworkers. Each of you has your own desk and your own filing cabinet. But sometimes you all need to access the same customer records or the same project documents. Without NFS, you would have to email files back and forth, save copies to a USB drive, or print everything out. It would be slow, messy, and confusing. NFS is like having a shared filing cabinet in the middle of the office. Anyone can reach into it, grab a file, work on it, and put it back. The files live on one central computer, the NFS server, but everyone on the network can see and use them as if they were on their own computers. That central computer keeps all the files organized and makes sure only the right people have access. If someone changes a file, everyone else sees the updated version immediately. This saves time and prevents the confusion of having multiple versions of the same file floating around. In the IT world, NFS is especially common in environments where many computers need to share large amounts of data, like in a school computer lab, a corporate office, or a data center. It works across different operating systems, so a Windows computer can access files stored on a Linux server, and vice versa. The key idea is that NFS makes remote files feel local, which removes a lot of the friction from collaborative work and centralized data management.

## Technical definition

NFS (Network File System) is a distributed file system protocol originally developed by Sun Microsystems in 1984. It allows a client computer to access files over a network as if those files were stored on local storage. The protocol is built on a client-server architecture and uses Remote Procedure Calls (RPC) for communication. NFS operates at the application layer of the OSI model, typically running over TCP or UDP on port 2049. The current standard, NFS version 4 (NFSv4), introduced significant improvements over earlier versions, including stateful operations, integrated security mechanisms such as Kerberos, and support for compound operations that reduce network round trips. Earlier versions, NFSv2 and NFSv3, were stateless, meaning the server did not maintain any information about client-side file operations between requests, which simplified crash recovery but limited performance and security. NFSv4 consolidated file locking, mount protocols, and security into the main protocol, eliminating the need for separate auxiliary protocols like the Mount Protocol and Network Lock Manager (NLM). Under NFS, the server exports one or more directories, defined in the /etc/exports file on Linux systems. The client mounts these exports into its own file system tree, usually via the mount command. Once mounted, the client can perform standard file operations such as read, write, create, delete, and modify permissions. These operations are translated into RPC calls that the server executes on behalf of the client. NFS relies on the ONC RPC (Open Network Computing Remote Procedure Call) framework, which uses XDR (External Data Representation) to ensure data consistency across different machine architectures. Authentication in NFS has evolved from simple host-based trust (in NFSv2 and v3) to more robust identity-based security using RPCSEC_GSS (Generic Security Services), which supports Kerberos v5, LIPKEY, and SPKM-3. In practice, system administrators configure NFS by setting up the server with shared directories and appropriate permissions, then configuring clients to mount those shares, often automatically at boot time via entries in /etc/fstab. Performance tuning involves adjusting parameters like rsize, wsize, and transport protocol choices. NFS remains a staple in enterprise environments, particularly in Unix and Linux ecosystems, for centralizing user home directories, shared application data, and backup storage, as well as in virtualized infrastructures and high-performance computing clusters.

## Real-life example

Think about a family that shares a single digital photo album. Mom takes a picture with her phone. She uploads it to an online photo album service. Later, Dad opens the same album on his laptop to show the picture to Grandma. Then the kids view it on their tablet. Everyone sees the same picture, and anyone can add new photos. Nobody has to plug in cables or email files to one another. Now, imagine that same scenario but in a small business. The company uses a video editing workstation. The video editor works on a project file that is stored on a central server. When the editor saves the project, the graphic designer on a different computer can instantly open that same file to add titles. The NFS works like that always-connected online album, but without needing internet access. The files are stored on a server in the office closet. Every computer in the building talks to that server using NFS. When an employee clicks to open a document, their computer asks the server for it. The server sends the data over the network, and the employee's computer shows the file just like it was saved on its own hard drive. When they save changes, the new data goes back to the server. This way, everyone always uses the most recent version. No one has to email files back and forth or worry about which copy is correct. This is exactly how NFS works in an IT environment. It creates a shared space where files live once, but are accessible to many.

## Why it matters

NFS is foundational in networked computing because it solves the practical problem of file sharing across multiple machines. In any organization with more than a handful of computers, coordinating files manually becomes a nightmare. NFS provides a standard, efficient way to centralize data so that users and applications can access it from any authorized device. This matters for several reasons. First, it simplifies administration. Instead of installing software or saving files on every individual computer, an IT team can store everything on one or a few NFS servers. Updates, backups, and security controls all happen centrally. Second, it enables collaboration. Multiple users can read and write to the same shared directory, which is essential for team projects, shared databases, and development environments. Third, NFS is platform-independent, meaning it works across Linux, Unix, and macOS, and with third-party clients on Windows. This flexibility allows heterogeneous networks to function smoothly. Fourth, NFS is mature and well-documented. It has been in use for decades, and system administrators have deep knowledge of its behavior, performance characteristics, and security considerations. NFS is also critical in virtualized environments where virtual machines need access to shared storage for live migration, high availability, and centralized management. For IT professionals, understanding NFS is not optional. It appears in server administration, storage management, and networking roles. Knowing how to configure an NFS export, set permissions, troubleshoot mount failures, and secure the protocol is a core competency for anyone working with Linux servers or enterprise storage solutions. Without NFS, many modern data center workflows would be far more complex and less efficient.

## Why it matters in exams

NFS appears in several major IT certification exams, although it is not always the main focus. In CompTIA A+, NFS is mentioned in the context of network file sharing and troubleshooting connectivity between devices on a local network. You might see a question about which protocol is used to share files on a Linux network. In CompTIA Network+, NFS is covered as a network service that operates at the application layer. Exam objectives include understanding the purpose of protocols like NFS, SMB, and AFP, and knowing the ports they use (NFS uses TCP and UDP port 2049). Questions may ask which protocol to use when sharing files between Unix systems. In CompTIA Linux+, NFS is much more prominent. You are expected to know how to configure the /etc/exports file, start and manage the NFS server service (nfs-server), use the exportfs command, and mount NFS shares on clients. Exam scenarios often involve troubleshooting permissions, firewall rules, or mount failures. For Red Hat Certified System Administrator (RHCSA), NFS is a key objective. Candidates must demonstrate the ability to configure an NFS server to share directories with specific options (like ro, rw, sync, no_root_squash) and configure clients to mount those shares persistently via /etc/fstab. Troubleshooting autofs configurations is also common. In Cisco CCNA, NFS is less central but still appears as an example of a network application that uses TCP/IP. You might see a question about which OSI layer NFS operates at or which transport protocol it relies on. For the AWS Certified Solutions Architect, NFS appears in storage discussions, particularly around Amazon EFS, which is a cloud-native implementation of NFS. Knowing the differences between NFS versions and when to use NFS over SMB can appear in scenario questions. In all these exams, NFS questions test your understanding of the protocol's role, configuration syntax, and troubleshooting approaches. You should memorize the port number (2049), the file used for exports (/etc/exports), and the basic mount command syntax.

## How it appears in exam questions

In certification exams, NFS questions typically fall into several patterns. The first type is direct knowledge recall. For example, 'Which port does NFS use by default?' or 'Which protocol is used for file sharing in Linux environments?' The answer choices might include SMB, AFP, FTP, and NFS. You need to know that NFS uses port 2049 and that it is the native solution for Linux-to-Linux file sharing. The second type is configuration-based. You might be given a server's /etc/exports file and asked which directory is shared, to which clients, and with what options. For example, the line '/data 192.168.1.0/24(rw,sync,no_subtree_check)' appears. A question could ask, 'What does the rw option allow?' Or 'Which clients can mount this export?' You need to read that line and understand CIDR notation and export options. The third type is troubleshooting. A common scenario: A client cannot mount an NFS share. The server is running, the network is up, but the client gets 'mount.nfs: access denied by server'. The question then asks what the most likely cause is. The correct answer often relates to an incorrect entry in /etc/exports, a firewall blocking port 2049, or a missing exportfs -a command after modifying exports. The fourth type is comparison questions. You might be asked to choose between NFS and SMB for a given scenario. For example, 'Which file sharing protocol should you use in a mixed Windows and Linux environment?' The answer would be SMB, since NFS is native to Unix/Linux. The fifth type is security. Questions about root_squash, no_root_squash, and the use of Kerberos with NFSv4 appear in Linux+ and RHCSA exams. A question might ask, 'What is the effect of the root_squash export option?' The answer is that it maps requests from the root user on the client to the anonymous user (nobody) on the server, preventing superuser access. The sixth type is performance-related. Questions might ask about the difference between sync and async export options, or how rsize/wsize values affect throughput. Being comfortable with these question patterns and practicing with exam-style simulations will help you handle NFS questions confidently.

## Example scenario

You are a system administrator for a university computer lab with 30 workstations all running Linux. The lab instructor needs all students to be able to access a shared folder called /course_materials that contains lecture slides, assignments, and sample code. The materials must be readable by everyone, but only the instructor should be able to modify them. Each student should have their own personal storage folder that only they can access. You decide to use NFS to solve this. On a central server named lab-server, you create two directories: /exports/course_materials and /exports/student_homes. You set permissions on /exports/course_materials to 755, owned by the instructor. You set /exports/student_homes to 755, but inside it, you create subfolders for each student, each owned by the respective student with 700 permissions. Next, you edit the /etc/exports file on lab-server. For the course materials, you add the line: /exports/course_materials 192.168.1.0/24(ro,sync,no_subtree_check). This makes the folder read-only for all clients on the lab subnet. For the student homes, you add: /exports/student_homes 192.168.1.0/24(rw,sync,no_subtree_check). This allows students to read and write to their own folders. After running exportfs -a to apply the exports, you configure each workstation to mount these shares. In /etc/fstab on each client, you add: lab-server:/exports/course_materials /mnt/course_materials nfs defaults 0 0, and lab-server:/exports/student_homes /mnt/student_homes nfs defaults 0 0. After running mount -a, the students reboot their workstations and find the course materials available under /mnt/course_materials. They can copy files, open them, and work. Each student can also save files to their personal folder under /mnt/student_homes/student_username. The instructor later needs to update the course materials. She logs into lab-server, copies the new files to /exports/course_materials, and the changes are immediately visible to all students when they next access the share. This scenario demonstrates the core value of NFS: centralized management with flexible access controls.

## Common mistakes

- **Mistake:** Thinking NFS is only for Linux and cannot be used on Windows.
  - Why it is wrong: While NFS originated on Unix, Microsoft provides an NFS client and server with Windows Server and some editions of Windows Pro. It is fully functional for file sharing between Windows and Linux.
  - Fix: Remember that NFS is platform-agnostic. When you see a scenario asking for cross-platform file sharing, consider both NFS and SMB, depending on the dominant OS.
- **Mistake:** Confusing NFS with SMB/CIFS and using the wrong protocol in certification questions.
  - Why it is wrong: They are both file sharing protocols, but they are not interchangeable. NFS is native to Unix/Linux, while SMB is native to Windows. Using NFS in a mixed environment without careful configuration can cause compatibility issues.
  - Fix: In an exam, if the scenario involves primarily Linux clients and servers, choose NFS. If it involves Windows clients and servers, choose SMB. For mixed environments, SMB is more common because of better Windows integration.
- **Mistake:** Forgetting to run exportfs -a after modifying /etc/exports.
  - Why it is wrong: Editing the /etc/exports file does not automatically apply the changes. The NFS server continues using the old export list until it is refreshed. Clients will still see the old shares or permissions.
  - Fix: After any change to /etc/exports, always run sudo exportfs -a (for all exports) or sudo exportfs -r (to re-export all directories) to apply the new configuration immediately.
- **Mistake:** Assuming that root on the client has root privileges on the NFS server by default.
  - Why it is wrong: By default, NFS uses root_squash, which maps the client's root user to the anonymous user (nobody) on the server. This is a security feature. Without it, any root user on a client could modify any file on the server.
  - Fix: When configuring exports, remember that root_squash is the default. If you need to allow root access from a specific client (rare in production), you must explicitly add no_root_squash. For most scenarios, root_squash is correct.
- **Mistake:** Misunderstanding the difference between sync and async export options.
  - Why it is wrong: Some learners think sync is always better because it sounds more reliable. But sync forces the server to write data to disk before replying to the client, which is slower. Async allows the server to reply immediately and write to disk later, which is faster but risks data loss on a crash.
  - Fix: Use sync for critical data that must not be lost. Use async only when performance is more important than data integrity, and you accept the risk. In exams, sync is usually the safer answer for production environments.
- **Mistake:** Believing that NFSv4 requires a separate portmapper or rpcbind service.
  - Why it is wrong: Older versions (NFSv2 and v3) required rpcbind to map RPC program numbers to network ports. NFSv4 consolidated everything onto a single port (2049) and eliminated the need for rpcbind for NFSv4 operations.
  - Fix: If a question asks about NFSv4, know that it uses only port 2049 and does not need rpcbind. For versions 2 and 3, rpcbind (port 111) is necessary. This is an important distinction for both configuration and firewall rules.

## Exam trap

{"trap":"An exam question describes a client that cannot mount an NFS share. The server is running, the network is fine, and the /etc/exports file looks correct. The trap answer is 'The NFS server is down' or 'The network is unreachable.'","why_learners_choose_it":"Learners often jump to the most obvious causes without checking the specific error. Since the client reports 'access denied,' they assume the server or network is at fault, but the server is running and the network is fine.","how_to_avoid_it":"Always read the error message in the scenario. 'Access denied' from an NFS client usually points to a permissions issue on the server: either the client's IP is not allowed in /etc/exports, the export options restrict access, or the exported directory's filesystem permissions are too restrictive. Check the export list first. The correct answer is often that the client's IP address is not in the allowed subnet or that the export option 'ro' is preventing writes when a write mount is attempted."}

## Commonly confused with

- **NFS vs SMB:** SMB (Server Message Block) is the native file sharing protocol for Windows, while NFS is native to Unix/Linux. Both allow remote file access, but SMB uses different ports (445) and has tighter integration with Windows Active Directory, user authentication, and printer sharing. NFS is simpler in Linux environments and uses port 2049. (Example: If you need to share a folder with 50 Windows PCs in a domain, use SMB. If you need to share a folder with 50 Linux servers in a data center, use NFS.)
- **NFS vs FTP:** FTP (File Transfer Protocol) is designed for copying entire files from one system to another, not for direct access to remote files as if they were local. NFS lets you open, edit, and save a file in place over the network. FTP requires you to download the file, edit it, and upload it back. NFS also supports file locking and real-time updates, which FTP does not. (Example: FTP is like borrowing a book from a library and returning it after reading. NFS is like having the book on your desk but the original stays on the library's shelf and everyone sees your changes instantly.)
- **NFS vs AFP:** AFP (Apple Filing Protocol) is macOS's native file sharing protocol. NFS is cross-platform, but AFP offers better integration with macOS-specific features like Time Machine, Spotlight, and file permissions. Apple has deprecated AFP in favor of SMB, but NFS remains a valid option for macOS clients connecting to Linux servers. (Example: For a pure macOS network, AFP used to be the default. For a network with both macOS and Linux machines, NFS is a reliable choice, though SMB is now more common in Apple environments.)
- **NFS vs iSCSI:** iSCSI is a block-level protocol that presents remote storage as a local hard disk. NFS is a file-level protocol that presents remote directories as parts of the local file system. With iSCSI you can format the remote disk with your own filesystem. With NFS you access files directly. iSCSI is for raw storage access, while NFS is for file sharing. (Example: iSCSI is like attaching an external hard drive to your computer via a long cable. NFS is like having your friend's folder appear in your own folder list. Both are storage, but one is at the block level and the other at the file level.)

## Step-by-step breakdown

1. **Planning and Server Preparation** — The administrator decides which directories to share and with which clients. They ensure the NFS server software is installed (nfs-kernel-server on Debian/Ubuntu, nfs-utils on RHEL/CentOS). They also verify that the rpcbind service (for NFSv3) or the NFSv4 only setup is ready. This step is critical because a missing service or incorrect planning leads to failed mounts.
2. **Configuring the /etc/exports File** — The administrator edits the /etc/exports file on the NFS server. Each line specifies a directory to export, which client systems can access (by IP, subnet, or hostname), and the export options (ro, rw, sync, async, no_root_squash, etc.). This file controls all access permissions. A mistake here, like a typo in the subnet, will prevent clients from mounting.
3. **Applying the Exports** — After editing /etc/exports, the administrator runs the exportfs command. The command 'exportfs -a' exports all directories listed, 'exportfs -r' re-exports all directories (useful after changes), and 'exportfs -v' shows the current export list for verification. Applying exports is a mandatory step; without it, the server does not know about the new shares.
4. **Starting or Restarting NFS Services** — The administrator ensures the NFS server service is running. On most Linux distributions, this is done with 'systemctl start nfs-server' and 'systemctl enable nfs-server' to start at boot. For NFSv3, the rpcbind service must also be running. Restarting services after configuration changes ensures the new settings are loaded.
5. **Configuring Firewall Rules** — To allow NFS traffic, the firewall must permit port 2049 (for all NFS versions). For NFSv2 and v3, additional ports for rpcbind (111) and the mountd daemon (often a random high port, but can be fixed in configuration) must be opened. This step is often overlooked and a common source of troubleshooting scenarios in exams.
6. **Mounting the NFS Share on the Client** — On the client system, the administrator creates a mount point (e.g., /mnt/shared_data). Then they run the mount command: 'mount -t nfs server_ip:/exported_dir /mnt/shared_data'. For NFSv4, the command is similar but may not need the -t nfs4 option if the client handles it automatically. The mount command initiates the RPC connection and makes the remote files available.
7. **Automating the Mount at Boot** — To make the NFS share available after every reboot, the administrator adds an entry to /etc/fstab. The entry includes the server address, exported directory, local mount point, filesystem type (nfs), options (defaults, _netdev), and dump/pass values. The '_netdev' option tells the system to wait for the network before mounting. Without this, the system might fail to mount during boot.
8. **Verifying the Mount and Testing Access** — The final step is to verify that the mount succeeded using 'df -h' or 'mount'. The administrator then tries to access files inside the mounted directory, checking that read and write permissions are correct. They also simulate the error conditions from the exam, such as removing the network cable to see the client's behavior (often the mount becomes stale). This verification confirms the whole process worked.

## Practical mini-lesson

Configuring NFS in a real-world environment requires more than just copying commands. The key is understanding how permissions interact at two levels: the NFS export options in /etc/exports and the underlying filesystem permissions (Unix file modes and ACLs). The export options act as a gate. Even if the underlying file permissions allow a user to write, if the export option is 'ro', writes will be rejected at the NFS level. Conversely, if the export allows 'rw' but the file permissions are 444 (read-only for owner), the NFS client can attempt to write, but the server's filesystem will deny it. The effective permission is the most restrictive of the two. For example, if /etc/exports says 'rw' but the directory is owned by root with permissions 755, a normal user can read and traverse directories but cannot write to files they do not own. This dual-layer permission model is a common source of confusion and troubleshooting. Another practical concern is security. By default, NFSv3 trusts the client's user ID (UID). If two different users on different clients happen to have the same UID, they will have the same access to files, regardless of their actual usernames. This is why NFSv4 with Kerberos is recommended in environments that require strong authentication. In practice, administrators often use NFS in combination with LDAP or Active Directory (via SSSD or Winbind) to synchronize UIDs across all clients. Performance tuning is another practical topic. The rsize (read size) and wsize (write size) mount options determine how much data is transferred in each RPC call. The default values (usually 1048576 bytes in modern kernels) work well for most networks, but on high-latency links, larger values can improve throughput, while on slow or congested networks, smaller values reduce packet loss. The 'sync' and 'async' options also affect performance. Async is faster but risks data corruption if the server crashes before writing to disk. In production, 'sync' is preferred for critical data. Troubleshooting NFS is a skill every sysadmin needs. Common issues include: mount hanging (due to firewall or server down), 'access denied' (export list or permissions), 'stale file handle' (server rebooted or re-exported while clients were still mounted), and 'permission denied' (filesystem permissions). Tools like showmount -e server_ip list the exports available from a server. The nfsstat command shows NFS statistics. tcpdump can capture NFS RPC traffic for deep analysis. Finally, remember that NFS is stateless in versions 2 and 3, meaning the server does not track client file locks or open files. This makes crash recovery simple but limits features. NFSv4 is stateful, providing better locking and delegation, at the cost of requiring more server resources. Understanding these trade-offs is crucial for both exams and real-world decision-making.

## Memory tip

Remember NFS port with a phrase: 'NFS is on 2049, think NFS as 20 for 20th century, 49 for the year it is always handy.' Or simply: NFS = Network File System, port 2049.

## FAQ

**What port does NFS use?**

NFS uses TCP and UDP port 2049 by default. For NFSv2 and v3, additional ports are used for rpcbind (port 111) and the mount daemon. NFSv4 consolidates everything onto port 2049.

**Can I use NFS between Windows and Linux?**

Yes. Windows Server and some Windows Pro editions include an NFS client and server feature. You can enable it and mount NFS shares from a Linux server on a Windows machine, and vice versa. However, SMB is generally more seamless for mixed environments.

**What is the difference between NFSv3 and NFSv4?**

NFSv3 is stateless, meaning the server does not keep track of file locks or opened files. NFSv4 is stateful, with built-in locking, better security (Kerberos), and improved performance through compound operations that reduce network round trips.

**What does the root_squash option do?**

root_squash maps requests from the root user (UID 0) on the client to the anonymous user on the server (typically 'nobody' with UID 65534). This prevents the client's root user from having superuser access to the shared files, enhancing security.

**Why does my NFS mount show 'stale file handle'?**

A stale file handle occurs when the server has changed the exported directory (e.g., it was unmounted, deleted, or re-exported) while the client still has the old file handle. The solution is to unmount and remount the share on the client.

**What is the /etc/exports file?**

The /etc/exports file is the main configuration file for the NFS server on Linux. It lists the directories to be shared (exports), the clients allowed to access them, and the mount options (like rw, ro, sync, no_root_squash).

**Do I need a separate service for NFSv4?**

No. NFSv4 does not require the rpcbind service. It only needs the nfs-server service. However, if you also need to support NFSv2 or v3 clients, you must keep rpcbind running.

## Summary

NFS (Network File System) is a fundamental protocol for sharing files across a network, allowing clients to access remote directories as if they were local. Developed by Sun Microsystems, it has evolved through versions 2, 3, and 4, with NFSv4 being the modern standard that integrates security, performance, and stateful operations. Understanding NFS is essential for any IT professional working with Linux servers, storage systems, or enterprise networks. In certifications, NFS appears in CompTIA A+, Network+, Linux+, RHCSA, and vendor-specific exams like AWS Solutions Architect (via Amazon EFS). You need to know its port (2049), configuration file (/etc/exports), export options, mount command syntax, and common troubleshooting scenarios. The most frequent exam traps involve confusing NFS with SMB, forgetting to apply exports with exportfs, misunderstanding root_squash, and failing to open firewall ports. By mastering NFS, you gain a practical skill that directly applies to real-world system administration, from setting up a shared drive for a small team to orchestrating storage for a data center. Remember the three layers of access control: export options, filesystem permissions, and network firewalls. With careful attention to each, NFS is a reliable, efficient solution for network file sharing.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/nfs