NFS Fundamentals for Mixed Environments

Sooner or later, every Windows-centric administrator inherits NFS. A Linux application server appears in the rack, a NAS appliance offers it as the "Unix sharing" checkbox, a hypervisor wants a datastore, or a vendor appliance insists on it. The concepts rhyme with the SMB shares you already run — one copy on a server, clients mount it, everyone reads and writes in place — but the vocabulary, the security model, and the failure symptoms are different enough to burn an afternoon if nobody explains them.

This is that explanation. You will learn what NFS is and how it maps onto what you know from SMB, which protocol versions matter and how each handles authentication, the export and mount options that actually change behavior, and the two ideas that cause the most confusion in mixed shops: root squash and identity mapping. It closes with the honest placement question — where NFS belongs alongside SMB and transfer flows. It is part of our Shares vs Transfer series, and it stays evergreen: concepts and options, not release notes.

What NFS Is, in SMB Speak

NFS (Network File System) is the Unix world's native share protocol — the counterpart of SMB. A server exports a directory (SMB would say "shares a folder"); a client mounts that export onto a path in its own filesystem tree (SMB would say "maps a drive"). From then on, applications on the client use the files as if they were local, and the protocol carries every open, read, and write across the network to the single real copy. Everything in shares vs transfers about live access, one-copy semantics, and trust applies to NFS exactly as it applies to SMB — including the round-trips-times-latency arithmetic that makes any mounted filesystem crawl over WAN links.

Three cultural differences from SMB matter immediately:

• Permissions are numeric. Unix filesystems store ownership as numbers — a UID (user ID) and GID (group ID) — not names. NFS inherits this: whether "user 1004" on the client is the same human as "user 1004" on the server is your problem, not the protocol's.
• Machine trust, not user login. Classic NFS access control asks "is this client machine allowed to mount this export?" rather than "did this user type a password?" There is no session logon in the SMB sense unless you add Kerberos.
• Configuration lives in text files. Exports are lines in /etc/exports (or the equivalent screen on a NAS), applied with a command, verifiable with another. No wizard, which turns out to be a feature: the whole configuration fits on one screen.

The Versions That Matter — and Their Auth Models

You will meet two version families in the wild. (An earlier one, NFSv2, is a museum piece; if a device offers only that, treat replacement as the fix.)

NFSv3 is the long-serving workhorse, still the default on many appliances. Its server core is nearly stateless — the server keeps no memory of which clients have which files open, which makes crash recovery simple and is why v3 survives server reboots so gracefully. The cost of that simplicity is a crowd of sidecar protocols: a separate mount service, a separate lock manager, a separate status daemon, all coordinated through the portmapper service on port 111, each potentially on its own port. Firewalling v3 properly means pinning several services to fixed ports first — genuinely annoying.

NFSv4 is the consolidation. Everything — mounting, locking, the file operations themselves — travels over one TCP connection to port 2049, which makes firewall rules trivial. The server is stateful: it tracks opens and locks as first-class protocol objects, and clients batch several operations into one round trip with compound requests, which helps on slower links. Version 4 also introduces a richer ACL model and expresses identities as names (alice@corp.example.com) rather than raw numbers, with a mapping service translating at each end.

Authentication is where the versions genuinely diverge:

Practical guidance: prefer v4 wherever both ends speak it — one port, better locking, batched round trips — and keep v3 for the appliances and legacy clients that require it. Nothing about that advice will expire.

AUTH_SYS: The Trust Model You Must Actually Understand

The default authentication in most real deployments, on both versions, is AUTH_SYS (historically called AUTH_UNIX), and its mechanism deserves to be stated bluntly: the client tells the server who it is, and the server believes it. Each request carries "this is UID 1004, groups 1004 and 50," asserted by the client's kernel with no password, no ticket, no proof. The server checks file permissions against those asserted numbers and answers.

Inside one administrative domain, this is less crazy than it sounds — the same trust you place in your own managed machines generally. But follow the logic one step: anyone who is root on any machine allowed to mount the export can impersonate any UID, because root can run processes under arbitrary IDs. Under AUTH_SYS, your export's real security is therefore the mount permission itself — the list of client machines — plus the network's protection against strangers joining it. That is why export lists should name specific hosts or tight subnets, and why NFS with AUTH_SYS must never be reachable from networks you do not control.

The upgrade path is Kerberos, the same ticket-based authentication behind Active Directory logons, applied to NFS via RPCSEC_GSS. Three levels exist: krb5 (each user proves identity with a ticket), krb5i (adds integrity checking — tampered packets are detected), and krb5p (adds privacy — traffic is encrypted). Kerberized NFS changes the question from "which machines do I trust?" to "which authenticated users do I trust?", at the cost of joining Linux clients to a Kerberos realm and managing keys. Worth it for sensitive data on shared networks; overkill for a lab subnet.

Exports: The Server Side

On a Linux server, exports are lines in /etc/exports: a path, then one or more client specifications, each with options in parentheses. A working, commented example:

# /etc/exports  —  path   client(options)
# project data: one app subnet, read-write, safest defaults
/srv/projects   192.168.10.0/24(rw,sync,root_squash,no_subtree_check)

# software repo: read-only for everyone on the LAN, all users squashed
/srv/software   192.168.0.0/16(ro,all_squash,no_subtree_check)

# finance extracts: one named host, Kerberos with encryption required
/srv/finance    app01.corp.example.com(rw,sync,sec=krb5p,root_squash,no_subtree_check)

# apply the file and show what the kernel is really exporting
exportfs -ra
exportfs -v

The options that actually matter, with the honest tradeoffs:

• rw / ro — write access or read-only. Export read-only wherever the use case allows; it removes whole categories of accidents.
• sync / async — with sync, the server confirms a write only after it reaches stable storage; with async it confirms from memory. Async benchmarks beautifully and can silently lose the last seconds of writes when the server crashes. Keep sync for anything you would mind losing.
• root_squash / no_root_squash / all_squash — the squash family, explained fully in the next section.
• no_subtree_check — skips a legacy verification that caused more trouble (especially with renamed files) than it prevented; it is the recommended modern default, and current server tools warn if you omit an explicit choice.
• sec= — the accepted authentication flavors, e.g. sec=sys or sec=krb5p. Omit it and AUTH_SYS is what you are running.
• Client field — a hostname, IP, subnet, or wildcard. Every widening of this field widens who can assert UIDs at your server; * means "anyone who can route a packet here," which should make you flinch.

Clients can list what a server offers with showmount -e filer01 (a v3-era helper; a v4-only server may answer only to an actual mount). Remember that attackers can run showmount too — an export list is not a secret.

Root Squash and Identity Mapping: The Two Confusions

Two NFS behaviors generate most of the "why is it doing that?" tickets in mixed shops. Both are identity problems.

Root squash. If client machines can assert any UID, then root on a client (UID 0) would arrive as root on the server's files — meaning anyone with a Linux laptop and an export mount could read and overwrite everything. Root squash is the server-side defense, on by default nearly everywhere: requests claiming UID 0 are remapped ("squashed") to an unprivileged anonymous account, traditionally nobody (tunable with anonuid/anongid). The visible symptom surprises newcomers: logged in as root on the client, you cannot read a protected file on the mount that an ordinary user can. That is the feature working. Its cousin all_squash maps every user to the anonymous account — useful for public read-only exports where individual identity is irrelevant.

Identity mapping. Under AUTH_SYS, the server compares asserted numeric IDs against the numeric owners stored on disk. If alice is UID 1004 on one machine and 1371 on another, the protocol neither knows nor cares — she simply gets the wrong permissions, or none. The fix is boring discipline: keep UIDs consistent across machines, either by convention on small fleets or, properly, with a central directory (LDAP, or Active Directory doing double duty) so every host resolves the same names to the same numbers. NFSv4's name-based identities add a wrinkle: both ends run an ID-mapping service configured with a shared domain string, and when the domains don't match, listings show files owned by nobody — the classic v4 symptom, fixed by aligning the domain setting, not by chmod. And a subtlety worth knowing: with sec=sys, v4 permission checks still ride on the numeric IDs; the name mapping mainly governs how ownership is displayed. Matched numbers remain the working rule until Kerberos replaces assertion with proof.

Mounting: The Client Side

Mounting by hand, then permanently:

# one-off mount
mount -t nfs -o vers=4,hard,timeo=600,retrans=2 filer01:/srv/projects /mnt/projects

# /etc/fstab — permanent; _netdev = wait for the network at boot
filer01:/srv/projects  /mnt/projects  nfs  vers=4,hard,_netdev,nosuid,nodev  0  0

# verify what was actually negotiated (version, options, server)
nfsstat -m

The option that deserves a decision rather than a default is hard vs soft. With a hard mount, if the server stops answering, client processes touching the mount block — indefinitely — until it returns; no I/O error is ever invented. With a soft mount, the client gives up after the retry budget (timeo × retrans) and returns an error to the application. Soft sounds friendlier and is the dangerous one: many applications handle a surprise I/O error mid-write badly, and a soft-mounted write that times out can leave truncated or corrupt files. The working rule: hard for anything writable or important (accept that a dead server means hung processes — that honesty is the point); soft only for read-only convenience mounts where an error beats a hang.

Round out the client side with three habits: add nosuid,nodev (and often noexec) on mounts from servers you do not fully control, so the mount cannot smuggle privilege escalation onto the client; use _netdev in fstab so boot ordering waits for the network; and prefer an automounter for laptops and machines that roam, so a missing server delays a directory access instead of the whole boot.

Where NFS Fits Alongside SMB — and Where Neither Belongs

In a mixed environment the placement rule is happily simple: serve each client its native protocol. Windows users get SMB, with its domain logons, share ACLs, and Explorer integration — hardening covered in securing SMB. Linux fleets, hypervisor datastores, and appliances get NFS. Windows does ship an optional NFS client, and it works for reaching a Unix-only export in a pinch, but mapping Windows identities onto numeric UIDs is exactly the kind of glue that fails at upgrade time; treat it as a bridge, not an architecture. Many NAS devices will happily export the same directory over both protocols at once — convenient for shared project data, with one caveat: the two permission models (Windows ACLs vs Unix mode bits and IDs) do not translate cleanly, so keep multiprotocol trees simple, with permissions granted at the top rather than sculpted per file. One more expectation to set: NFS locking is real but advisory in the Unix tradition — applications that ask for locks get them, applications that never ask can trample each other — so don't assume SMB-style mandatory "file in use" behavior carries over.

And the boundary rule from shares vs transfers applies with extra force. NFS — especially with AUTH_SYS — is a same-trust-zone protocol: its security is the export list plus the network. Never expose it across the internet or to partner networks, and be skeptical even across WAN links you own (Kerberos with krb5p is the minimum bar there, and latency will still hurt). When a file must leave the trusted segment — a nightly extract to a partner, results to another site — that crossing is a job for a transfer flow: the Linux side can push with its standard sftp or scp tooling to a transfer endpoint such as Sysax Multi Server on the Windows side, where the delivery is authenticated, jailed, and logged; scheduled distribution in the other direction is what Sysax FTP Automation exists for. For bulk Linux-to-Linux mirroring across sites, delta copying is usually the better tool than a stretched mount — that is our rsync and delta transfer series.

The Working Summary

NFS is the Unix-native share protocol: exports instead of shares, mounts instead of mapped drives, numeric identity instead of session logons. Prefer version 4 for its single port and integrated locking; keep version 3 where appliances demand it. Understand AUTH_SYS for what it is — client-asserted identity — and let that shape tight export lists, default root squash, and honest network containment, with Kerberos as the upgrade when proof must replace trust. On clients, choose hard mounts for data you care about and add the no-privilege options for servers you don't fully trust. Then place it correctly: NFS and SMB for live in-place access inside the trust zone, each serving its native clients, and a logged transfer flow whenever files must cross a boundary. For the SMB half of that picture, continue with securing SMB; for the boundary-crossing half, our SFTP series covers the protocol those flows should ride on.

Frequently Asked Questions