MacOS
View all Worklets
MacOSmacOS

Disable NFS Service

Disable the macOS NFS daemon (com.apple.nfsd) through launchctl on endpoints that do not export file systems

Worklet Details

What the macOS NFS daemon disabler does

This Automox Worklet™ disables the com.apple.nfsd launchd service on macOS endpoints. The Worklet uses launchctl to inspect the system-level disabled list, and when nfsd is not already marked disabled, it calls launchctl disable system/com.apple.nfsd so launchd will refuse to load the NFS server going forward.

The Worklet treats the change as idempotent. Endpoints where nfsd is already disabled report "nfsd is already disabled. No actions taken." and exit cleanly, so the policy is safe to schedule on a recurring cadence across a mixed Mac fleet.

Why disable nfsd on Macs that do not export file systems

macOS ships with the NFS server (nfsd) installed but not actively running. launchd will start nfsd on demand when an exported file system is requested, which means an attacker or a misconfigured tool can trigger the daemon without an administrator ever having enabled it explicitly. Endpoints that have no documented file-sharing role gain nothing from leaving nfsd loadable and absorb the protocol's well-known weaknesses, including AUTH_SYS UID and GID spoofing on the local network segment.

Marking com.apple.nfsd disabled in the launchd system domain prevents on-demand activation. The Worklet captures the pre-change state and the post-change verification in the Automox activity log, which gives audit teams deterministic per-host evidence that the NFS server is no longer reachable rather than a spot check from a single workstation.

Scheduling the policy as a recurring guardrail catches the next administrator who re-enables nfsd for troubleshooting, a configuration management tool that re-asserts the service, or a major macOS upgrade that resets the disabled list. The next policy run finds nfsd allowed again and re-disables it without manual intervention.

How NFS daemon disablement works on macOS

  1. Evaluation phase: The Worklet runs /bin/launchctl print-disabled system and greps the output for "com.apple.nfsd" set to true. If the match is present, nfsd is already blocked and the script exits 0. If the match is absent, the script exits 1 to mark the endpoint non-compliant and queue remediation.

  2. Remediation phase: The Worklet runs /bin/launchctl disable system/com.apple.nfsd, then repeats the print-disabled check against com.apple.nfsd. If the recheck still does not show the service disabled, the script writes an ALERT message stating that the service still appears to be running and exits 1 so the failure surfaces in the Automox activity log. On success it exits 0.

macOS NFS disablement requirements

  • macOS endpoint with /bin/launchctl available (any supported macOS release)

  • Root privileges for the Automox agent so launchctl can write to the system domain disabled list (the default agent context already meets this)

  • Endpoints with a documented NFS server role (Mac file servers, build caches, shared home-directory hosts) must be excluded from the policy through Automox group scoping

  • NFS client functionality (mount_nfs and the nfs.client launchd jobs) is not affected; this Worklet only disables the com.apple.nfsd server job

Expected nfsd state after macOS remediation

After remediation, launchctl print-disabled system shows "com.apple.nfsd" => true, and launchd will refuse to load the NFS server on demand. The kernel nfsd threads are no longer started when an export is requested, so the endpoint stops responding on the NFS service ports it would otherwise open dynamically.

Any client that previously expected to mount file systems from this Mac receives an immediate connection refusal on its next access attempt. The /etc/exports file is left untouched, so an administrator can review the prior export configuration before deleting it; the Worklet does not modify exports because audit teams often want the file as evidence of the previous server role.

Subsequent Automox policy runs report the endpoint as compliant without re-applying remediation, because the evaluation phase finds com.apple.nfsd already in the disabled list. The disabled state survives reboots, and a recurring policy catches the next macOS upgrade or administrator action that would otherwise re-enable the daemon. Capture the output of launchctl print-disabled system alongside the policy run identifier as audit evidence.

View in app
evalutation image
remediation image

Consider Worklets your easy button

What's a Worklet?

A Worklet is an automation script, written in Bash or PowerShell, designed for seamless execution on endpoints – at scale – within the Automox platform. Worklets deploy named-CVE mitigations within hours of disclosure, perform configuration, remediation, and install or remove applications and settings across Windows, macOS, and Linux.

do more with worklets