MacOS Monterey authorize startup disk

Hi 

Couple of clarification questions: 

Is this an M1 device? Is the user that is logged on/starting the update the volume owner?
How are you trying to deploy the update? Scripted? From System Preferences? 

Yes, this is an m1 device. The update fails on both scripted and manually going in and installing it.

I believe that they are the volume owner since they were setup on the volume with their user through DEP

I am getting the same thing on a M1.  Only 1 start up disk and its selected but I still get the issue.  I ran the update through System Preferences.  Mine is set up through Apple Kerberos SSO and it doesnt work with my account but I log into the admin account and it works.

That is the exact same behavior we are seeing. I elevated a user account to admin privileges and the install works. We don't want to make our users admin though so we are looking for a way around this.

Interesting. We have seen similar behaviour on our M1s. 

If running the update from system preferences, we have found logging in with the first account that was used after DEP completed has been sufficient to authorise the update even as a standard user. One hitch was mobile accounts being on. This causes other issues which we did have a work around for. Will need to find the notes we had on what we did to fix that. 

Thinking about it, we also don't have file vault on, not sure if that is also true for you?

 
Our scripted update has been having some issues and we were looking at modifying our script for M1 to match up with the recommended switches mentioned in this years JNUC session for deploying Monterey. Annoying thing is script works fine for all our other devices. 

Will be following this post.   

Do you have a link to the recommended switches for deploying Monterey?

We do have file vault on which I am going to enroll a Mac now without FileVault to see if the behavior is any different

Sorry I somehow missed this reply. 
I don't have a link but the switches were covered in the deploying Monterey JNUC session:

Deploying macOS Monterey (1297)  

Did you ever figure this out? I’m running into this issue with our M1s as well.

not yet. We have a ticket open with apple.

Any Update on this?

I like to have an M1 set-ups without Local Admins (except for the jamfadmin of course, but that one shouldn't have a secure token) and also be able to have users initiate any minor- AND major system updates (without the need for a mass action command).

Hi Everybody,

I'm also having issues with Monterey when it comes to M1's. The only solution I've found is to log in with an admin account and then have the user log back in once the update is done. Has anybody found a solution to this so users can update themselves without an admin?

Thanks, 

I ended up using erase-install, it works great. https://github.com/grahampugh/erase-install/wiki

Is there an update to this? We just started seeing this behavior on some (not all) of our M1's.  Not even logging in as an admin is working, the credential window just loops and the install never continues.

Macs with Apple Sillicon have now a new security measure called 'volume ownership'. It is explained in this article:

https://support.apple.com/en-bw/guide/deployment/dep24dbdcf9e/web

Depending on your prestage set ups it is indeed possible to have local admin accounts and/or standard accounts present on the system that do not have the right ownership to install/update/upgrade the macOS.

In such case the https://github.com/grahampugh/erase-install/wiki as mentioned above provides you the solution!

I suggest you re-view your prestage enrollments to acommodate for the Apple Silicon macs in order to get the end result as you want it.

Do you know what to look for in the pre-stage enrollment settings to prevent this?

FYI on my Mac, I followed the commands from Apple and I am indeed a volume owner, yet I still get the error when trying to upgrade to Monterey. If I simply elevate my user account to be an administrator, the install will work. This isn't a solution of course in an enterprise. This has to be some kind of bug, I just can't pinpoint it.

You need to be a Volume owner AND admin to do major upgrades.

If you don't want your end users to have admin rights, then you'll need to use the erase-install tool.

I have it installed so it gets triggered by a button push in Self Service. The end user needs to fill in their local password, and the script behind the tool will take care of the rest. It uses the jamfadmin to elevate the privs.

I believe that you should be able to force the updates remotely too if you have the macs enrolled via ADE (automated device enrollment). But I'm not quite sure how and if that would work when a user without admin privs is currently logged in as I've not tested this scenario. We need our users to control the moment of updating/upgrading themselves.

I have a script that will elevate them to admin install the OS helper pkg which will open up System Preferences to the Update and start the download process of Monterey. Also have one for Big Sur.  then after the update happens I have a smart group for unauthorized admins that will demote the account back to a standard user.  This is so users can either update or upgrade their own computer.

Clever!

We are now able to complete the update without admin rights by leveraging fileVault. I'll post the script here when we finish testing but we don't have to erase-install since we thought that was a unnecessary hassle

Hello All, where does this script go in this type of workflow....I'm using Nudge and it pulls down the installer for me and then I execute, getting the Volume Owner Error with M1's, where does this script fit in to this?

Same question here. We are using kc9wwh's github macOSUpgrade script. Where might the above script come into play for M1s?

Thanks!

It's an interesting script, and I wonder how it would work because it looks like it only ever uses the FVpassword and I don't see anything about elevating an Admin password. I could be wrong about it all tho cause i'm no script master. I still perfer to use Graham's Erase-install app/script https://github.com/grahampugh/erase-install , because it is interactive and presents a 'progress' status so that the user actually understands what is going on AND (of course) it solves the initial problem.

However, to answer @scottlep and @jamf-experian s question.

I think you need to add this script to your Jamf Instance, then create a Policy that executes the the script by a button press in Self-Service. I recommend creating a smart group that has macs not on monterey and scope it out to those. Then when the user pressed it, it will be asked to type in the FVpassword (which should be the same as their login password in most cases) and then it will start installing Monterey.

But this script does require the Monterey installer present in the Applications folder otherwise it won't work. (You might as well add that to your smartgroup to avoid confusion).

Does that make sense?

We are trying to upgrade our devices to 12.3.1 and they all get stuck about 30% through the progress screen, after reboot. Restarting them at the points brings up FileVault and entering the password resumes but having it hold at 30% is causing problems with pushing the updates. I know it has been a few months since the last post, has anyone found a working solution? I tried the above script but it still halted on reboot.

this script will deploy full fetch installer - in this case, every single update users needs to download more than 12GB update packages. I am using the following script. The script gives the user a temporary admin right. Admin rights are automatically deleted after 30 minutes with the launch daemon. Then, the user writes password with the OSAS script and only the update package is downloaded and installed with this password.

#!/bin/bash

##macOS Update Policy

currentuser=$(who | awk '/console/{print $1}')

#Make Admin Current USer

sudo defaults write /Library/LaunchDaemons/removeAdmin.plist Label -string "removeAdmin"

sudo defaults write /Library/LaunchDaemons/removeAdmin.plist ProgramArguments -array -string /bin/sh -string "/Library/Application Support/JAMF/removeAdminRights.sh"

sudo defaults write /Library/LaunchDaemons/removeAdmin.plist StartInterval -integer 1800

sudo defaults write /Library/LaunchDaemons/removeAdmin.plist RunAtLoad -boolean yes

sudo chown root:wheel /Library/LaunchDaemons/removeAdmin.plist

sudo chmod 644 /Library/LaunchDaemons/removeAdmin.plist

launchctl load /Library/LaunchDaemons/removeAdmin.plist

sleep 10

if [ ! -d /private/var/userToRemove ]; then

mkdir /private/var/userToRemove

echo $currentuser >> /private/var/userToRemove/user

else

echo $currentuser >> /private/var/userToRemove/user

fi

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

cat << 'EOF' > /Library/Application\\ Support/JAMF/removeAdminRights.sh

if [[ -f /private/var/userToRemove/user ]]; then

userToRemove=$(cat /private/var/userToRemove/user)

echo "Removing $userToRemove's admin privileges"

/usr/sbin/dseditgroup -o edit -d $userToRemove -t user admin

rm -f /private/var/userToRemove/user

launchctl unload /Library/LaunchDaemons/removeAdmin.plist

rm /Library/LaunchDaemons/removeAdmin.plist

log collect --last 30m --output /private/var/userToRemove/$userToRemove.logarchive

fi

EOF

#Request Password

CurrentPassword=$(osascript << EOF

text returned of (display dialog "Enter your password" default answer "" buttons {"OK"} default button 1)

EOF

)

echo $CurrentPassword | sudo softwareupdate -iaR