It seems no matter how I try to run this it always tells me the user I am using is not administrator when it clearly is. I have not been able to figure out why after weeks of trying. Any ideas?

I get "Requested user is not administrator. Allow the user to administer this computer is system preferences to continue." But in system preferences it is admin already.

@mattmcchesney The only other thing is the admin account needs to have the SecureToken enabled.

@luke.michelson which I just checked at is says secure token is enabled for this user. I did the fetch installer got the install right from Apple and it still says I'm not administrator. Happens for multiple users I have created. I had this all working pre M1 with no issues.

ok well I did a recovery restore and didn't have it enroll in Jamf and the admin user created at login works on this one. Now to figure out what strange combo of settings stops it from working.

I seem to have figured out my issue with this. I had some kernel extensions configuration profiles still applying to this M1 Mac and when they applied it crashed the OS. This also seemed to do something strange to all admin accounts created after that. Didn't think about the two being linked and the intel Macs didn't have this issue. But after removing all the KEXT policy which we have System Extensions for anyway it all seems to be working great now.

Hi @mattmcchesney
I also have the same problem..current user is admin and secure token already enable for the user..when I use --stdinpass , then error: user is not admin..when I use --passprompt , it is successfully erased and install big sur..not sure what wrong.. I have some kext profile as well, but I don't see it is related to startosinstall command.

I'm still not able to get this working. I've even included a script to run make the logged in user an admin, then proceed with the erase and install. Upgrading works, but the policy sits at "Running" for ~45 minutes, then goes to "Executing"...its been 20 minutes on that portion right now.

OMG...I ran in Terminal, and the drive wiped and macOS reinstalled, and took me back to the set up screen; so I assumed I was good to go. Powered off the machine, then decided to run remote management, and when I boot up now the machine goes to recovery and says there's no users on the volume to recover. This is...frustrating. Running on an M1 MacBook Air

@Jason33 Here's some of the messages we're trying to work through. Have you found what is causing your message? We're still trying to figure out what are causing these.

@Jason33

I think that is Apple "known/bug" issue I have seen that a few times when restoring an M1 air.. with a normal internet recovery and there is this Apple doc..

https://support.apple.com/en-us/HT211983

C

Also dealing with upgrade issues with Big Sur. We tried to leave it off, but due to hardware stock being low, we had not choice.
I was also getting that error:
could not get authorization...
Here's the syntax that has worked via a script within a policy for mac mini's that have a blank password (they are info displays(that needed auto login(setup before my time))). These mac mini's also don't have file-vault enabled as they are considered Non-Human macs.
As long as the mac is enrolled via DEP(not self enrolled via the site) you won't see any prompts for privacy, dark/light mode, stuff.

#Just snippet of the code, without checks and logging. 

#Add Secure token to our desktop admin account (I know dumb)

user="desktopAccount"

pass="desktopPass"

currentUser="loggedInUser"

sysadminctl -secureTokenOn "$user" -password "$pass" -adminUser "$currentUser" -adminPassword ""

#After OS install file is cached in Applications folder 

echo $pass | /Applications/Install macOS Big Sur.app/Contents/Resources/startosinstall --nointeraction --agreetolicense --forcequitapps  --user $user --stdinpass &

Has anyone gotten this to work with M1's? Works just fine on an Intel machine running these commands via Policy:
/Applications/Install macOS Big Sur.app/Contents/Resources/startosinstall --agreetolicense --forcequitapps --nointeraction --eraseinstall --newvolumename "Macintosh HD"

@Jason33 M1's have extra security which requires admin credentials added to the command parameters. Look at the post above yours... specifically the --user and --stdinpass parameters.

Sorry, copied my command from the wrong policy. In my policy, I have a script that runs that promotes the currently logged in user to an admin. The user also have securetoken. With the --passprompt flag, shouldnt I receive a pop up asking for the password, in order to proceed?

/Applications/Install macOS Big Sur.app/Contents/Resources/startosinstall --passprompt --agreetolicense --forcequitapps --eraseinstall --newvolumename "Macintosh HD"

From the startosinstall usage, here is what --passprompt says "collect a password for authorization with an interactive prompt"

@Jason33 You still need the --user parameter to specify the user for which you're tying in the password.

I was having this exact issue, the terminal command worked flawlessly with Intel and failed as yours on M1 so I opened a support request with Apple Enterprise and this is their response.

The behavior you described is expected on Apple silicon Macs and has been reproduced internally by Apple. Product Engineering is working on a fix that is expected to arrive in a later version of macOS 11.

With that, it seems no matter what we try to do while doing an --eraseinstall, we won't be able to get this going since it's an issue embedded into their OS.

I've been using version 11.4 for the full installer, perhaps using an older version will work instead.

i've read all the message above so if i want to use a one button erase on self service with a M1 mac, i have to put the admin password in clear on the script? There is no another way? My internal security do not want a thing like this

Sorry, but i don't understand a thing after reading all messages. It's not possible actually to do a one button erase in the self service, without putting the password in the script right? Because my internal security will not allow this.

@user-TUGybyjVPe Unfortunately, the two options are to prompt for the password or to have it provided with the command. We create a generic admin user specific for the startosinstall command, and then encrypt it in the script before decrypting it for the command. It's a pain, but it works for us. It at least keeps it from being in plain text in the script.

So here is the script that I put together for this process, but I'm still never prompted for the password. Am I missing something? when I run the policy the only thing that seems to work is elevating the user permissions. After that, the policy just spins and does not do anything further

#!/bin/bash



#get the logged in user



loggedInUser=$(stat -f %Su /dev/console)



osascript -e 'display dialog "Click the button to erase the drive and reinstall macOS Big Sur." buttons {"Erase and Install"} default button 1'



#give the loggedInUser admin privileges



/usr/sbin/dseditgroup -o edit -a $loggedInUser -t user admin



#start macOS Big Sur Installer to erase drive



/Applications/Install macOS Big Sur.app/Contents/Resources/startosinstall --passprompt --user $loggedInUser --agreetolicense --forcequitapps --eraseinstall --newvolumename "Macintosh HD"



exit 0

looks like it's fixed with 11.5

softwareupdate --fetch-full-installer --full-installer-version 11. 5 ; echo 'Pa$$' | '/Applications/Install macOS Big Sur.app/Contents/Resources/startosinstall' --agreetolicense --eraseinstall --newvolumename 'Macintosh HD' --nointeraction --forcequitapps --user admin --stdinpass

this worked for me now

I'll briefly offer (or add onto this jamboree) that running

from the Terminal as a Standard user was our undoing. It threw back an "Error: could not get authorization..."

The error followed an attempt to run the command from a Standard user account while invoking an administrative account in the Terminal with...

 It only worked after properly logging into the LOCAL_ADMIN_USERNAME from the macOS login prompt and then running the first command mentioned in this post. This was on an M1 MacBook Air running Big Sur 11.15.1. (Of course, as you all know, the above method worked for previous versions of macOS installer on Intel-chip MacBooks.)

@Jason33 Hi mate

I've tried running the above on an intel mac. When pushing it through Jamf under files and processes its's stating done but nothing is happening? Any advice?

@DBrowning 

The above examples are great but they do require knowing a secureToken username and password and being able to hard code that into a script (which may not be a good idea security wise).

In our case it's not possible since we let the majority of our users deploy the machines themselves and so THEY are the secureToken user. We do add an InfoTech Administrator account we script as a policy but it is not a secureToken account. As well, the password is unique so even if our InfoTech Administrator account was a secureToken account we wouldn't know the password necessarily (not for script purposes in any case).

So in order to make a Self Service item that works in M1s we do the following:

In the part of your script where you would usually just have the startosinstall command line you instead point it over to a .command file payload that will open the Terminal for the logged on user and will prompt for a secureToken credential (you can package up that .command file in a pkg as part of your Jamf policy and place it in a tmp folder):

open /private/tmp/macos-11-M1-eraseandinstall.command

Once again for those that want to have a Self Service item that works with any secureToken user account this should do it.

Still working to upgrade m1 to monterey, thanks a lot !