How umask determines permissions
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 commandsudo 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 noteman chmod