Permissions should be simple, but every once in a while they turn into a nightmare. Take the example of someone who ended up with an extra admin account on their previous Mac. To deal with this, they deleted the first admin account. After that, everything worked fine until they tried moving some of that user’s files to a new Mac via an external drive. The admin user on that new Mac couldn’t access some of those files, apparently because of permission problems. How come?

The reason goes deep down inside the Unix heart of macOS, to the way that it identifies users. Your Mac has long user names, short user names, Bonjour names, and plenty of others, but its Unix heart just knows each user as a number, their UniqueID. The primary admin user is always given the UniqueID of 501.

Every folder and file on your Mac then has an owner and a group in its permissions. Browse permissions using Finder’s Get Info and you’ll see these expressed as names. So the preference file, from /Library/Preferences, shown above is owned by me, only to the code that operates the permissions system, that isn’t Howard Oakley, or even hoakley, but the user with the UniqueID of 501.

Let’s suppose that, a few months after you set your Mac up, you create a second admin user account, and want to remove the primary account. The UniqueID for that second account could be anything upwards of 502: on this Mac, that second admin account would be given a UniqueID of 505. Suppose you go ahead, log on using the 505 account, exercise your admin privileges, and remove the 501 account.

As an admin user, 505 can still move and remove the great majority of the files and folders that were owned by account 501, if necessary by authenticating with their password. But every single folder and file that was owned by the 501 account has now been orphaned: its owner UniqueID no longer exists.

There are ways of ameliorating this problem. The command line wizard might write a script to whizz through folders and files and change those owned by 501 to the remaining admin user, 505. But sooner or later, something somewhere inside macOS will look for user 501, and when it can’t find it, will cause you grief.

This is the sort of problem that Migration Assistant is used to coping with, and if you were to migrate files owned by the 505 account to a new Mac where the primary admin user is 501, they should end up on your new Mac with the correct ownership. But if you move those files over on an external drive, sooner or later you may well hit a problem.

This is where another little-known feature of macOS comes in. Select a volume in the Finder and Get Info on it. At the foot of its Sharing & Permissions section is a checkbox reading Ignore ownership on this volume. Tick that, and macOS should pretend that the permissions there never happened. If a file is owned by 501 or 505, or anything else, then it should give you full access to it regardless of the UniqueID of your user account. It’s the Get Out of Jail card for permissions, and ideal for drives that you move between different Macs, some of which could have users with different UniqueIDs.

If you really do want to remove the primary admin user, it’s probably worth investing the time to re-install macOS from scratch, and migrating other accounts, so the new primary admin user will have the UniqueID of 501, and life will still be beer and skittles, rather than 501 orphans and troubled permissions.

Congratulations to Simon, who only realised he had a 501 orphan problem after solving it using the Ignore ownership trick.