NFS Ports Explained: Why 2049 Isn’t Always Enough

A firewall rule for TCP port 2049 is often enough to let an NFSv4 client reach a server. With NFSv3, it may not be: clients can also need rpcbind and other RPC services, some of which use ports assigned by the server.

The useful first question isn’t just “What port does NFS use?” It’s “Which NFS version and services are this client and server using?”

Start with the NFS version

Port 2049 is the standard NFS service port. For the common NFSv4-over-TCP setup, it’s usually the main port a client needs to reach on the server.

NFSv3 can use TCP or UDP, depending on the client and server configuration. It may also rely on separate RPC services:

• rpcbind, commonly on port 111, helps clients discover RPC service endpoints.
• mountd handles mount requests.
• statd and lockd can support status monitoring and file locking.

The auxiliary services aren’t guaranteed to use one universal set of ports. Some can be dynamically assigned, so don’t copy a port number from another server and assume it applies to yours.

Service	Common port or transport	What to keep in mind
NFSv4	TCP 2049	Usually the primary NFS port to allow
NFSv3 NFS service	TCP or UDP 2049	Depends on the server and client configuration
rpcbind	TCP and/or UDP 111	Often used by NFSv3 clients to discover RPC services
mountd, statd, lockd	RPC-assigned or configured ports	Check the server’s registrations and configuration

This is a diagnostic starting point, not a firewall recipe. The exact requirements depend on the NFS version, implementation, enabled services, and transport.

Inspect the server before changing firewall rules

On the NFS server, list the RPC programs registered with the local rpcbind service:

rpcinfo -p localhost

Look for entries such as nfs, mountd, nlockmgr, and status. The output shows registered ports and transports, but it doesn’t mean every listed service must be exposed to every client. Compare it with the NFS version and the server’s configuration.

You can also inspect listening sockets:

sudo ss -lntup

A service may be listening locally but blocked by a host firewall or a network firewall. For a deeper explanation of checking listening ports on Linux, keep in mind that a listener alone doesn’t prove outside clients can reach it.

Test reachability from the client

For a TCP check of port 2049, run this on a client machine:

nc -vz nfs-server.example.com 2049

Replace the hostname with your NFS server. A successful connection only tells you that the TCP port accepted a connection from that client. It does not confirm that the export path exists, that the client has permission to mount it, or that the NFS version is correct.

UDP tests need different interpretation: a lack of response from a UDP probe does not, by itself, prove the port is closed.

If you need to add a firewall rule, scope it to the intended client or private network rather than opening NFS broadly. For example, the general UFW rule syntax for allowing a port can be adapted for the common NFSv4-over-TCP case:

sudo ufw allow from 192.0.2.25 to any port 2049 proto tcp

Replace 192.0.2.25 with the trusted client address. This is not a complete NFSv3 rule set. Check the actual RPC services and configured ports before adding rules for an NFSv3 deployment.

A quick troubleshooting sequence

When a mount times out or fails to connect, work through the network path before changing export permissions:

1. Confirm the NFS version and transport. An NFSv3 client may need RPC services beyond port 2049.
2. Inspect registered RPC services on the server. Use rpcinfo -p localhost and note the ports and transports in use.
3. Check TCP 2049 from the client. If it fails, investigate the listening service, host firewall, route, and intervening network controls.
4. Check every firewall layer. A local firewall, cloud security group, network ACL, or another firewall can block traffic.
5. Separate connectivity from mount configuration. A reachable port doesn’t prove the export path or client access is valid.

For example, an NFSv4 mount attempt might look like this:

sudo mount -t nfs -o vers=4.1 nfs-server.example.com:/export/path /mnt/nfs

Use the export path and local mount point that apply to your setup. This tests an actual mount; it isn’t a port-only check. If the server is reachable but the mount reports a path or access error, check its export layout and permissions. NFSv4 export paths can differ from NFSv3 paths.

For NFSv3, if port 2049 is reachable but the mount still fails, check whether the client can discover or contact mountd and other required RPC services. Don’t treat broad firewall access as a substitute for identifying the ports in use.

Keep NFS access private

NFS shouldn’t be exposed to the public internet. Restrict NFS and related RPC traffic to the specific clients or private network ranges that need access. Export access controls and network segmentation provide additional protection; a firewall rule does not replace correct export permissions.

If NFSv3 is required, predictable auxiliary ports can make narrow firewall rules easier to manage. Configure them using instructions for your particular distribution or storage appliance, then allow only those configured ports from the clients that need them.

For many NFSv4 setups, TCP 2049 is the main rule to investigate. For NFSv3, inspect the server’s RPC registrations before deciding what else to allow.

I originally published a more detailed version of this guide on the SSHFlow blog.

I'm also building SSHFlow — an SSH client where every server gets its own workspace for terminals, SFTP, code, and databases.