Granting Volume Owner status on Apple Silicon Macs
macOS on Apple Silicon Macs includes a concept known as volume ownership. You must be a volume owner to perform the following tasks on an Apple Silicon Mac:
- Make changes to startup security policy for a specific install of macOS.*
- Be able to authorize the installation of macOS software updates or macOS upgrades.
- Authorize running Erase All Contents and Settings.
* There may be multiple installations of macOS on one Apple Silicon Mac; each macOS install would have their own startup security policy.
For more information on volume ownership, please see Apple’s Platform Deployment article linked below:
https://support.apple.com/guide/deployment/use-secure-and-bootstrap-tokens-dep24dbdcf9e/web (see the Volume ownership section.)
How do you get volume ownership though? It turns out that Apple has this currently set up on macOS as a two-fer deal: If an account account has Secure Token, it is also granted volume ownership. For more details, please see below the jump.
To see which users on the Mac have Secure Token, run the following command:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
/usr/sbin/diskutil apfs listCryptoUsers / |
The user accounts with Secure Token assigned should appear listed with the following information:
- Type: Local Open Directory User
- Volume Owner: Yes
In place of the account’s username, the account’s assigned UUID identifier (also referred to as a GeneratedUID) is listed. To get the account username, run the following command with the UUID identifier in the appropriate place:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
/usr/bin/dscl . -search /Users GeneratedUID UUID_goes_here | awk '{print $1}' | head -n 1 |
If the account you want to be a Volume Owner isn’t listed, you can check the account’s Secure Token status by running the following command:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
/usr/sbin/sysadminctl -secureTokenStatus username_goes_here |
If the account does not have Secure Token assigned, the output of the command should tell you this.
To assign Secure Token (and Volume Owner) to the desired account, run the following command:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
/usr/sbin/sysadminctl -secureTokenOn username_goes_here -password password_goes_here -adminUser user_with_secure_token_goes_here -adminPassword admin_password_goes_here |
If you want to be prompted for passwords in place of including them as part of the command in plaintext, enter a dash ( – ) where you would otherwise enter the relevant account’s password when running the following command:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
/usr/sbin/sysadminctl -secureTokenOn username_goes_here -password – -adminUser user_with_secure_token_goes_here -adminPassword – |
Once this has been done, you can verify that Secure Token has been assigned to the desired account by running the following command:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
/usr/sbin/sysadminctl -secureTokenStatus username_goes_here |
The output should now tell you that Secure Token has been assigned to the account.
To verify that the desired account is now also a Volume Owner, run the following command:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
/usr/sbin/diskutil apfs listCryptoUsers / |
You should see a new entry listed with the following information:
- Type: Local Open Directory User
- Volume Owner: Yes
To get the account username, run the following command with the UUID identifier in the appropriate place:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
/usr/bin/dscl . -search /Users GeneratedUID UUID_goes_here | awk '{print $1}' | head -n 1 |
The desired account’s username should appear in the output.
Thank you for documenting this, it got us out of trouble with a new M2 MBA which assigned the Secure Token to a Time Machine-recovered account (an old MacPorts account inherited and not noticed from ages ago). One further thing I needed to do in order to transfer the Secure Token to the correct account was to temporarily grant the accidentally created account admin privileges:
udo dscl . -append /Groups/admin GroupMembership macports
One Monterey update later, the account could be deleted and forgotten.
Wondering if this is able to be scripted in a way to push out from Jamf if for some reason a user isnt granted the bootstrap or volume ownership. I have a smart group created already with the extension attribute finding users on Apple Silicone machines without Volume Ownership. Just wondering if we use a local admin if we can program this out to just apply to that smart group.
Were you ever able to push this out as a script using Jamf? We have a few hundred M2 MacBooks that are affected by this issue.
Thank you very much for your post.
In my case a Macbook Pro M2 was joined to the company’s domain and the domain user (with admin privileges on the computer) was not able to install any updates.
Thank you for sharing! Some of our M2 MacBooks had administrator accounts that were not allowed to install macOS updates. This was a simple fix.