Disable NFS Service

What the NFS Service Disabler does

This Automox Worklet™ disables the NFS server daemon (nfsd) on macOS endpoints. NFS is a distributed file system protocol that allows file systems to be exported and mounted across a network. When enabled, the endpoint can serve files to NFS clients.

The Worklet uses launchctl to disable the com.apple.nfsd service at the system level, preventing the NFS daemon from starting automatically and stopping any currently running instance.

Why disable the NFS service

Network File System (NFS) provides file sharing capabilities that create security risks in environments where file sharing is not required. NFS has a history of security vulnerabilities including information disclosure, privilege escalation, and denial-of-service flaws. Leaving NFS running on endpoints that do not need file sharing expands your attack surface unnecessarily.

Many Linux distributions install and enable NFS services by default, even when the system will never act as an NFS server. These unnecessary services consume system resources, create listening network ports, and provide attack vectors for network-based exploits. Security hardening practices require disabling unnecessary services to reduce attack surface.

NFS authentication relies on client IP addresses and UID/GID matching, which are easily spoofed in many network environments. Attackers who gain network access can often mount NFS shares and access files without password authentication. In modern zero-trust security models, NFS's weak authentication model is incompatible with security requirements.

Compliance frameworks including CIS Benchmarks for Linux, STIG requirements, and PCI-DSS controls require disabling unnecessary network services. Security audits specifically check for running NFS services on endpoints that do not have documented business needs for file sharing capabilities.

How NFS service management works

1. Evaluation phase: The Worklet runs launchctl print-disabled system and searches for com.apple.nfsd in the disabled services list. If the service is marked as true (disabled), the endpoint is compliant. If not found or marked as false, remediation is triggered.

2. Remediation phase: The Worklet executes launchctl disable system/com.apple.nfsd to disable the NFS daemon. It then performs a verification check to confirm the service now appears in the disabled list. If verification fails, the Worklet reports an alert.

NFS service management requirements

• macOS endpoint (workstation or server)

• Administrative privileges for modifying launchd services

• Endpoints functioning as NFS servers should be excluded from this policy

Expected NFS state after remediation

The NFS server service is stopped and disabled on the endpoint. The service no longer runs in the background and will not automatically start after system reboots. The endpoint no longer listens on TCP and UDP ports 2049 (NFS), 111 (portmap), and associated RPC ports.

Any NFS shares that were previously exported from this endpoint are no longer accessible to network clients. Remote systems that previously mounted file systems from this endpoint receive connection failures or timeout errors when attempting to access those mounts. This terminates file sharing capabilities provided by this endpoint.

You can verify the service status by running 'systemctl status nfs-server' or 'service nfs status' depending on your Linux distribution. The output shows the service as inactive (dead) and disabled, confirming that NFS is not running and will not start automatically.

The NFS client functionality remains available if your endpoint needs to mount file systems from other NFS servers. This Worklet only disables the NFS server component. Endpoints can still act as NFS clients and mount remote file systems if your environment requires that capability.

How to validate disable nfs service changes

1. Run this Worklet on a pilot Linux endpoint and review evaluation output for disable nfs service.

2. Confirm Automox activity logs show successful completion and exit code 0.

3. Verify endpoint state using checks aligned to evaluation script logic, such as else, exit.

4. Validate remediation effects from script operations such as else, /bin/launchctl, exit, then rerun evaluation for compliance.