whiteweb.security / guides / NFS exposed
NFS :2049 High exposure ~6 min read

My NFS server is exposing directories to the public internet. What should I do?

An NFS export reachable from the internet — especially a “world” export with no host restrictions — lets anyone mount your shared directories and read, often write, the files inside. Combined with NFS’s trust-based permissions, that can mean full access to whatever you’ve shared. Here’s how to lock the exports down.

First: don’t panic — restrict the exports and firewall NFS.

NFS trusts the network it’s on, so exposing it to the internet removes its main safety assumption. Close the ports and tighten your exports to known hosts now, then check what was reachable.

// the 60-second version

  • Firewall port 2049 (and rpcbind/mountd) immediately.
  • Replace any world export with specific, trusted host/subnet rules.
  • Use root_squash and read-only where possible.
  • Treat exposed files as read; rotate any secrets among them.

01Understand what’s at risk

NFS was designed for trusted LANs. Exposed to the internet — especially with a permissive export — it offers:

  • File access — anyone can mount the share and read it; with write access they can modify or plant files.
  • A “world” export (*) places no restriction on who may mount — the worst case.
  • UID-based trust — without root_squash, a remote “root” is treated as your root on the files.
  • Recon & pivot — configs, keys or credentials in shared files open further doors.

NFS has no real user authentication of its own — it trusts client-supplied UIDs and the network. That’s fine on a private LAN and dangerous on the open internet; an exposed export should be treated as readable by anyone.

02Stop the bleeding — firewall NFS

Block the NFS ports from the internet. NFSv4 uses 2049; older setups also need rpcbind (111) and mountd.

deny NFS from the worldufw
ufw deny 2049
ufw deny 111

Keep NFS on a private network or VPN; it should never face the public internet.

03Tighten your exports

Edit /etc/exports to restrict every share to specific trusted hosts or subnets, drop world exports, and apply safe options:

restrict + harden an export/etc/exports
# bad:   /srv/share   *(rw,no_root_squash)
# good:
/srv/share   10.0.0.0/24(ro,root_squash,sync)

Apply with exportfs -ra.

  • Never use * as the host — name the hosts/subnets that need access.
  • Prefer ro (read-only) unless write is required; always keep root_squash on.
  • Consider NFSv4 with Kerberos (sec=krb5) for real authentication.

04Read the logs — who mounted?

Check for mount activity and connections from outside your network:

look for mountsbash
grep -iE "mount|rpc.mountd" /var/log/syslog
# current NFS clients
showmount -a localhost
  • Mounts from unknown IPs mean your files were reachable — assume read.
  • If write was allowed, inspect shared files for unexpected changes.

05Rotate exposed secrets & check files

  • If the share held configs, keys, backups or credentials, rotate those secrets.
  • Verify the integrity of important files against backups in case of tampering.

06Make sure it can’t happen again

  • Keep NFS on private networks/VPN only — never the public internet.
  • Restrict exports to named hosts; never *.
  • Read-only + root_squash by default; use Kerberos for auth where possible.
  • Firewall 2049/111/mountd and audit /etc/exports regularly.

Was this guide useful?

These playbooks are free to read and share. If a heads-up ever saved you a bad week, you can say thanks — or jump into the other guides.