Skip to main content

LaunchAgent or LaunchDaemon does not load on macOS 27: check quarantine metadata

A Fileset can install successfully even when macOS refuses to load a LaunchAgent or LaunchDaemon installed by that Fileset's scripts or a third-party installer. On macOS 27, check whether the affected launchd property list (.plist) has the com.apple.quarantine extended attribute.

Apple's macOS 27 release notes state that launchd no longer supports loading property list files with the quarantine extended attribute. This is a macOS loading restriction, not by itself evidence that FileWave failed to deliver the Fileset.

When to check

Use this check when an expected background service does not load after deployment and its plist exists at the intended location, such as /Library/LaunchDaemons or /Library/LaunchAgents. Quarantine is one possible cause; the same symptom can result from invalid plist syntax, incorrect ownership or permissions, an unavailable executable, or the wrong launchd domain.

FileWave's normal Fileset file-transfer path does not preserve the quarantine attribute. A script that downloads or extracts content on the Mac, an installer script, or a manual file-copy operation can introduce or preserve it separately. Inspect the final installed plist rather than assuming its attributes match the original source.

Check the affected plist

Replace the example filename with the exact plist for the affected service. Run this read-only check in Terminal on an affected Mac:

/usr/bin/xattr -p com.apple.quarantine "/Library/LaunchDaemons/com.example.daemon.plist"
  • A returned value confirms that the attribute is present on that file.
  • No such xattr: com.apple.quarantine means that attribute is absent; continue investigating other causes rather than adding it.
  • A missing-file or permission error does not establish whether the attribute is present. Confirm the path and access first.

For a LaunchAgent, inspect its actual plist path instead. Capture the loading error and relevant macOS logs as well; this check does not identify every reason a service can fail.

Correct a trusted plist

Only remove quarantine after verifying that the plist and the executable or script it launches are trusted and approved for your environment. Prefer a corrected vendor installer when one is available.

Removing an attribute does not validate the software or resolve code-signing, notarization, ownership or permission problems.

For an approved plist in the system-wide Library, an administrator can remove only the affected attribute:

sudo /usr/bin/xattr -d com.apple.quarantine "/Library/LaunchDaemons/com.example.daemon.plist"

Repeat the read-only check and confirm it reports that the attribute is absent. Do not clear all extended attributes recursively or modify Apple's protected /System/Library content.

Then retry the service's documented registration/loading procedure in the correct context: LaunchDaemons use the system domain; LaunchAgents use the intended user session. Do not apply a system-domain loading command to every kind of job. Loading or starting a service can execute its configured program, so test on an appropriate device first.

Verify the intended function, not merely the existence of the plist or a successful Fileset status. A continuously running daemon should exhibit its expected runtime behavior; a scheduled or on-demand job may legitimately have no persistent process.

Prevent recurrence

Check the attributes of the final installed plist after any download, archive extraction or copy operation. Do not assume changing the download or copy utility guarantees that quarantine will be absent.

Where an approved deployment script must correct a trusted plist, perform the targeted check/removal after the file is placed and before the first attempt to register or load it. A Fileset Postflight script is too late if a package's installation script already tried to load the service. Fix the responsible installation step or obtain a corrected package rather than adding a blanket attribute-removal script to every Fileset.

Keep useful diagnostic output and exit codes in deployment scripts. See Fileset Script Logging on macOS and Windows and Fileset Scripts Overview.

References

No comments to display