showmount & mount
showmount queries the NFS MOUNT service; mount attaches an exported directory to your local filesystem. NFSv3 commonly uses portmapper 111, NFS 2049 and additional RPC services. NFSv4 can work on 2049 without a MOUNT service, so an empty showmount result does not rule it out.
1. Discover exports and protocol versions
nmap -sV -p111,2049 10.10.10.5
nmap -p111 --script rpcinfo 10.10.10.5
showmount -e 10.10.10.5
nmap -p111,2049 --script nfs-ls,nfs-showmount,nfs-statfs 10.10.10.5
| Command | Interpretation |
|---|---|
showmount -e | Advertised export paths and client restrictions |
showmount -a | Client:path entries reported by mountd; can include stale records |
showmount -d | Directories reported as mounted, not a replacement for -e |
rpcinfo | Registered RPC programs and available transports |
2. Mount read-only and inspect owners
mkdir -p /tmp/nfs-review
sudo mount -t nfs -o ro,nosuid,nodev,noexec \
10.10.10.5:/profiles /tmp/nfs-review
# If negotiation fails and NFSv3 is available:
sudo mount -t nfs -o ro,nosuid,nodev,noexec,vers=3,nolock \
10.10.10.5:/profiles /tmp/nfs-review
findmnt /tmp/nfs-review
ls -lan /tmp/nfs-review
find /tmp/nfs-review -maxdepth 3 -type f -readable
Use one mount command, not both on top of each other. Numeric ownership from ls -n is important: a local username may map to a different UID than the server’s user. Identify promising files before copying a whole export.
For an NFSv4-only server, try the pseudo-root and inspect the visible paths:
sudo mount -t nfs -o ro,nosuid,nodev,noexec,vers=4 \
10.10.10.5:/ /tmp/nfs-review
access denied can mean an export restriction, security flavour mismatch or wrong pseudo-root path. A local root shell does not override the server’s rules.
3. Understand identity before testing it
With AUTH_SYS (sec=sys), the client supplies numeric UID/GID values. Local root may be able to act as another UID:
# GNU/Linux setpriv: test a specific observed UID without creating an account
sudo setpriv --reuid=1001 --regid=1001 --clear-groups \
cat /tmp/nfs-review/user/notes.txt
This does not bypass every NFS configuration:
| Server option | Meaning |
|---|---|
root_squash | Maps UID 0 to an anonymous identity; does not authenticate all other client UIDs |
no_root_squash | Preserves client root identity; dangerous on a writable export |
all_squash | Maps all supplied UIDs/GIDs to the anonymous identity |
sec=krb5/krb5i/krb5p | Uses Kerberos identity; simply changing a local UID is insufficient |
A writable no_root_squash export is a lead for escalation, but a SUID file helps only if the server can execute it from that path with SUID honoured. Export permissions, filesystem mount options and target-side access still matter.
Success, evidence and cleanup
Success: findmnt confirms the intended server/path and options, and a file can be read under the tested identity. Save the export response, numeric ownership and a small redacted example. showmount listing a path does not prove you can mount or read it.
sudo umount /tmp/nfs-review
findmnt /tmp/nfs-review
If unmount fails, leave the directory in another terminal and check which process holds it open. Read-only mounting avoids accidental remote writes; nosuid,nodev,noexec limits how remote content is treated locally.
Distinguish client mount options from server export policy
| Setting | Where it applies | What it establishes |
|---|---|---|
Client ro | Review machine’s mount | This client mounts read-only; server may still offer writes |
Client nosuid,nodev,noexec | Review machine’s mount | Limits local handling of remote files |
Server ro / rw | Export configuration | Server-side write policy |
Server root_squash | Identity mapping | Client root is mapped to an anonymous identity |
sec=krb5i / krb5p | Negotiated security flavour | Kerberos integrity / privacy protection |
Do not report a server export as read-only just because you chose -o ro. Likewise, noexec does not make reading a script into an interpreter impossible; it is a local mount constraint rather than a complete content-security boundary.
NFSv4 path and identity checks
findmnt -no SOURCE,FSTYPE,OPTIONS /tmp/nfs-review
nfsstat -m
ls -ldn /tmp/nfs-review /tmp/nfs-review/user
An NFSv4 export path can differ from the backing filesystem path. Resolve it through the server’s pseudo-root or documented export, not by assuming the NFSv3 path applies. Owners shown as nobody can reflect squashing or NFSv4 name/id-mapping problems; compare numeric ownership and the configured identity domain.
Collect one file with its context
umask 077
mkdir -p evidence/nfs
stat /tmp/nfs-review/user/notes.txt > evidence/nfs/notes-metadata.txt
cp /tmp/nfs-review/user/notes.txt evidence/nfs/notes.txt
sha256sum evidence/nfs/notes.txt > evidence/nfs/notes.sha256
Record server, export path and relative path as well as the digest. The local copy’s ownership is not the original server ACL. If the file changes during collection, obtain a consistent source copy rather than claiming the digest represents a stable snapshot.
Troubleshooting by layer
| Symptom | Next check |
|---|---|
showmount times out but 2049 is open | NFSv4-only deployment or mountd transport filtering |
| Mount hangs | Route plus all RPC services required by the selected NFS version |
access denied by server | Client allowlist, export path and security flavour |
| Mount succeeds, file access fails | Numeric UID/GID, squashing, mode bits and ACLs |
| Kerberos mount fails | Ticket principal, service name, client configuration and time |
| Unmount is busy | Current directories and processes holding files open |
Treat UID-based access and writable no_root_squash as different findings. The first concerns trusting client-supplied identities; the second can allow client root to create privileged server-side content when additional execution prerequisites are met.
See Also
Sources
- Nmap nfs-ls
- Nmap nfs-showmount
showmount(8),nfs(5),exports(5)andsetpriv(1)from the installed system manuals