MacOS permissions issue

Binary folder permission issue

Installing and running UPDD software requires that ownership and permissions on certain system folders are set appropriate.

The specific folders are:


For installation root account should have read, write and execute permissions.

For the software to run the user account should have read and execute permissions.

This is a list of the folders and permissions from a typical system with the correct permissons set as seen in a Terminal window running the 'ls -ltr' command:

If these permissions are not set appropriately various issues will be reported as shown below.

Fixing the folder permissions is described below.

Software installation

The installation will fail and the UPDD install log will contain similar entries as per this example :

2020-06-04 02:38:30-07 MacBooks-MacBook-Pro-2 shove[1514]: [source=file] failed _RelinkFile(/var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/C/PKInstallSandboxManager/5B31BBDE-BFE9-4851-8728-683A1312BA2C.activeSandbox/Root/usr/local/bin/qt.conf, /usr/local/bin/qt.conf): Operation not permitted
2020-06-04 02:38:30-07 MacBooks-MacBook-Pro-2 shove[1514]: dstParentPath = /usr/local/bin NSFileOwnerAccountID=502 NSFileSystemFileNumber=8598607120 NSFileExtensionHidden=0 NSFileSystemNumber=16777220 NSFileSize=5152 NSFileGroupOwnerAccountID=80 NSFilePosixPermissions=511 NSFileCreationDate=2019-03-13 18:30:33 +0000 NSFileExtendedAttributes={

In this example the permissions are reported in the log as "511" which means no write access.

Preventing UPDD commands running

A few users reported that the command was not found i.e. in a terminal it would be seen as 'upddutils: command not found'

Another variation of this issue is UPDD commands failing to open, showing various error when invoked from a Terminal window, as in this example invoking UPDD Test program:


Preventing UPDD Commander running

UPDD Commander will report an UPDD API error:

Fixing the folder permissions

The required permissions can be set by executing the following command in Terminal (found in the Utilities folder) for each folder that needs the permissions set:

sudo chmod -R 755 [folder path] as per this example to set the permissions on the /use/local/bin folder

Repeat this command for any folder as required.

For any folders not set to the root account you will also need to run the command sudo chown root [folder]

In one instance is was also discovered that the /usr/local/bin folder was owned by a non-existent user account and could not be accessed by regular user accounts: We suspect some other software made this folder change.

We set this back to the root account using the command 'chown root lib' as per the example below along with the correct permissions (this example uses permissions value 777 but 755 is more correct)

Disabling System Integrity Protection

One user struggled to overcome permission issues (they were using 10.13.6) so they temporarily disabled the system's System Integrity Protection, installed and then reenabled the protection:

Restart system, Command+R, Select Language, (on the navigation bar) Utilities<Terminal< run "csrutil disable", Restart.

Remember to re-enable System Integrity Protectionby repeating steps above, so the system isn't left vulnerable.