Title: PackageKit install fails with PKInstallErrorDomain Code=120 and NSPOSIXErrorDomain Code=1 during _relinkFile operation Body: We are investigating an intermittent package installation failure on macOS Tahoe 26.5 and are trying to understand

Question

Created 1w

Replies 3

Boosts 0

Participants 2

We are investigating an intermittent package installation failure on macOS Tahoe 26.5 and are trying to understand the conditions under which PackageKit may return the following errors during an upgrade installation:

PKInstallErrorDomain Code=120
NSPOSIXErrorDomain Code=1 ("Operation not permitted")

The package successfully passes validation and authorization, and pre-install scripts complete successfully. The failure occurs during the final PackageKit commit phase when PackageKit attempts to move/relink content from the installer sandbox to the destination volume.

Relevant log snippets:

PackageKit: Shoving <sandbox>/Root to /

Error relinking file (primary): .../Contents/_CodeSignature/CodeResources

failed _relinkFile(...) Operation not permitted

PackageKit: Install Failed: Error Domain=PKInstallErrorDomain Code=120

NSUnderlyingError: Error Domain=NSPOSIXErrorDomain Code=1 "Operation not permitted"

The issue is intermittent and only affects a subset of systems. The same package installs successfully on many machines running the same macOS version.

Has anyone encountered similar _relinkFile / CodeResources failures during package upgrades?

In particular, we are interested in understanding:

Common causes of NSPOSIXErrorDomain Code=1 during PackageKit relink operations.
Whether existing signed application bundle metadata (CodeResources) can cause relink failures during upgrades.
Any Installer or PackageKit changes in recent Tahoe releases that could affect bundle replacement during package installation.

Any insights would be appreciated.

Answer 1

DTS Engineer OP

Apple

1w

So, error 120 in the PKInstallErrorDomain domains basically means ‘something went wrong trying to install a file’. The error 1 is EPERM, obviously. The _relinkFile bit is interesting. You can think of it a bit like a rename system call. It’s responsible for actually putting the file where it needs to be. So, it’s likely that this failure is happening because the installer went to move a file into position and got a EPERM back from the file system.

If a machine encounters this problem, does it happen every time? Or if, say, you retry the install, does it then works?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Answer 2

Hitesh_Reddy OP

5d

Thank you for the explanation.

Based on our observations so far, the behavior appears to be machine-specific rather than a one-time transient failure.The issue is not observed on all systems running the same macOS version.

However, on the subset of affected systems, repeated installation attempts result in the same failure signature during the file commit phase:

PKInstallErrorDomain Code=120

NSPOSIXErrorDomain Code=1 ("Operation not permitted")

with the failure occurring during the _relinkFile operation involving an existing CodeResources file.

I have also logged a FB - https://feedbackassistant.apple.com/feedback/22931581

Answer 3

DTS Engineer OP

Apple

2d

Thanks for filing FB22931581.

You should check whether the affected machines have an Endpoint Security client installed on them. That’s a common source mysterious EPERM errors like this. If so, ask the customer to (temporarily) disable the ES client and try again. If that resolves this issue, that gives you a new avenue to explore.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"