Create a new folder inside your Documents folder, and inspect its permissions in the Finder’s Get Info dialog. You should see that you, as the owner of that folder, have Read & Write privileges, your group staff can only read it, as can everyone. Have you ever wondered how that new folder, or any new file, gets its permissions set in that way? This article explains how, and how you can control that.

Although it might appear to be of little use, there are circumstances when it becomes really important, for example when you create folders and files in shared locations. What if you were to use a sharepoint on a NAS that you shared with several others, and created folders and files there, with those same permissions? Although your colleagues would be able to read that folder and documents, they wouldn’t be able to write to them. Instead, you’d want those to give both Read & Write privileges to everyone in your group, and that’s something you can set with your umask.

Your Mac has at least two umasks, stored in /private/var/db/com.apple.xpc.launchd/config. One for all your user processes, including the Finder and apps that you run, the other for system processes, stored in the same place. If you want to override the default umasks, then you do so using the launchctl command in Terminal. Before you can do that, you need to know how to specify those umasks using octal numbers.

Octal permissions

The most compact and convenient way to express permissions isn’t in hexadecimal, but octal, and that’s standard across all Unix-based systems. Open a file or folder in my free utility Precize, for instance, and it reports its Posix permissions as three octal digits, together with the names and ID numbers of the owner and group.

A complete set of permissions actually consists of four octal digits, but the first is used for special bits (setuid, setgid and sticky), which don’t concern us here. The next and most important three digits give the permission settings for the owner, group, and everyone else, in that order.

Each digit is the sum of up to three numbers:

• 4 means that reading is allowed
• 2 means that writing is allowed
• 1 means that a file can be executed, or a directory searched.

So the standard permissions set on that new folder you created work out thus:

• the owner has Read & Write access, and search = 4 + 2 + 1 = 7
• the group has Read only access, and search = 4 + 1 = 5
• everyone has Read only access, and search = 4 + 1 = 5

and the octal permissions of that folder are given as 755. For a shared folder where all in the group need both read and write access, you might want octal permissions of 775 instead.

Octal permissions are used in many places in Unix, hence in command tools like chmod, used to set and change permissions. They’re also used if you want to set your own umask.

Set the umask

Having mastered octal permissions, you now need to understand how a umask is applied to them. It would be far too simple for you to simply specify the umask as the octal permissions, so, as the name suggests, the number you set as a umask is subtracted from the default octal permissions. Default permissions are almost invariably 666 for files, and 777 for folders, the latter to allow for search. Thus the default user umask is 022:

• for a file, default permissions are then 666 – 022 = 644
• for a folder, default permissions are then 777 – 022 = 755, as we saw with the folder above.

To return to my example of someone who is sharing folders with colleagues in their group, and all of them need both read and write access to those shared folders and files, a simple way to accomplish this is for each to change their user umask to 002 from the default of 022. To do that as an admin user, enter the command
sudo launchctl config user umask 002
But before you use that, check there’s a folder at /private/var/db/com.apple.xpc.launchd/config. If there isn’t, that command will result in an error that you can correct by creating that folder.

This applies to all files and folders created by the processes run by a user, no matter where they are created, so extends beyond their shared folders.

Setting a system umask should be exceedingly rare, as that alters the permissions of folders and files created by macOS background services and whole lot more, and could cause utter chaos or security problems. If you really need to, use the same command but with system instead of user in the command line.

Whenever you have changed either the user or system umask, you need to restart your Mac to ensure the new setting is enforced.

Exceptions

Setting a umask doesn’t guarantee that every new folder and file will be created with those permissions, though, as processes with root privileges can set their own umask and are also able to set custom permissions where they wish. If you find a third-party app not respecting the user umask, when there’s no good reason to do different, contact its developer and complain. Good behaviour is essential for apps that work in shared environments.

References

Apple’s detailed support note
man chmod

A cynic might summarise the history of Mac OS in four eras:

1. rebuilding the Desktop (Classic Mac OS)
2. repairing system permissions (Mac OS X to OS X 10.10)
3. resetting Home permissions (OS X 10.11 to macOS 10.15)
4. cursing privacy protection (macOS 11 onwards).

There is slight overlap between the last two, in macOS 10.14 and 10.15.

Rebuilding the Desktop

Classic Mac OS built its Desktop illusion using hidden databases that associated types of document with icons set by the apps that created them. This was based on two four-character codes in every file to specify the file’s type and creator. Periodically, those databases became damaged and this association stopped working, with the result that all documents were displayed with the same generic icon.

Rebuilding those Desktop databases was initiated by restarting the Mac while holding the Command and Option keys until the dialog was shown. Mac OS then checked through all installed apps to reconstruct their associations with document types.

This had to be repeated for each volume in turn as it was mounted by Mac OS. If there wasn’t sufficient free space on a volume, the process failed. The price of some utilities like TechTool Pro was often justified by the tools they provided for assisting in this process.

Mac OS X ended that reliance on Desktop databases, leaving this to die with Classic Mac OS.

Repairing system permissions

Since its first beta-release, Mac OS X suffered from ill-defined and pervasive problems thought to result from corruption of files used by the system. Until the introduction of System Integrity Protection (SIP) in 10.11 El Capitan, those generally resulted from files within the system acquiring incorrect permissions. Various reasons were proposed for this, including installer scripts that overstepped their bounds.

To address this, Disk Utility had a feature whereby it could check and repair permissions of all major parts of the system, based on information contained in BoM files for system updates and installations. Repairing permissions in this way became one of the main panaceas in older versions of Mac OS X and OS X, and was an important feature in Disk Utility.

Although chiefly intended to provide better security protection, one of the benefits of SIP was that it largely prevented system files from gaining incorrect permissions, and the feature to repair them was removed from Disk Utility. In any case, because of SIP it was no longer possible for Disk Utility to change the permissions of files protected by SIP.

Resetting Home permissions

When macOS 10.12 Sierra was released, a different problem appeared, in which permissions apparently became set incorrectly not in system files generally, but in the user’s Home folder, and specifically in ~/Library/Preferences. To address this Apple added a new verb to the already complex command tool diskutil, resetUserPermissions, and described how to use this in a support note. It’s perhaps no coincidence that this new problem appeared at about the same time that cfprefsd took on the management of those preference files.

At that time, the following problems were attributed by Apple to incorrect permissions in ~/Library/Preferences:

• changes to preference settings, particularly those for System Preferences, do not ‘stick’;
• changes made to the Dock do not ‘stick’;
• you are asked to authenticate when trying to move or alter some folders in your Home folder;
• when trying to save, you are told that the file is locked, or that you don’t have permission;
• Preview, TextEdit, and App Store apps (which are sandboxed) may crash when opened;
• alerts appear warning that the startup disk has no more space available for app memory;
• Safari or SafariDAVClient use large amounts of resources (memory);
• the Mac runs very slowly;
• iTunes cannot sync a device;
• there are problems with Photos or iPhoto libraries, including inability to import into the library, or forgetting the library each time the app is opened.

Most if not all of those could be attributable to problems arising from bugs in cfprefsd.

Apple later changed its recommendations to include running a new tool repairHomePermissions in Recovery mode, then re-installing macOS. Shortly afterwards, in June 2020 when Big Sur was in beta, Apple withdrew that support note and all reference to repairing permissions, although the tool is still available in Recovery mode even on Apple silicon Macs.

Cursing privacy protection

Prior to macOS 10.14 Mojave, privacy protection had been limited and largely unobtrusive. We then began to discover that our favourite apps were being locked out of accessing files in many of our working folders.

Thus the era of adding apps to the Full Disk Access list started, and we came to curse the blessing of privacy protection.

Even better, Apple later added extended attributes that could prevent apps perfectly capable of editing documents from being able to save them just when we needed that most. And protected the extended attribute using SIP.

Maybe rebuilding the Desktop databases every couple of months wasn’t so bad after all?