Update error: A snapshot is currently set to boot that is not the currently booted snapshot [solved]

macos_snapshot_fix.md

Fix for "A snapshot is currently set to boot that is not the currently booted snapshot" issue

I spent a while figuring this one out. Here is what I did to render it [Solved] on my Dad's new Sonoma iMac. (BTW: I caused this problem in the first place by enabling his nfsd service, then adding and tagging the snapshot as bootable)

1. Boot into recovery mode, open the terminal and disable SIP

   csrutil disable

2. Reboot at this point back into Recovery mode and this time open up DiskUtil

   You should now be able to see the system snapshot that is causing the issue, however you will not be able to delete it (since it is the active boot snapshot) So, instead, take careful note of the previous snapshot - it might have a name like:

   com.apple.os.update-5E4DF785AD9E60757D57924284549E29EECDBFE5942B5587D41DEAD049A903BE

3. Now exit DiskUtil and go back into Terminal, then mount the booting hard disk as rw:

   mount -uw /Volumes/Macintosh\ HD

4. Now 'tag' the official snapshot as the next bootable one:

   /System/Library/Filesystems/apfs.fs/Contents/Resources/apfs_systemsnapshot -r "SnapshotName" -v /Volumes/Macintosh\ HD

   (replace SnapshotName with the name of your snaphot. (like the one I showed)

5. Now exit the terminal and go back into DiskUtil

   Now you can view the snapshot and should be able to delete the offending one if you want to. (select it and click the minus sign at the bottom left)

6. Exit DiskUtil and go back to the terminal (last time I promise) and re-enable SIP:

   csrutil enable

7. Reboot back into MacOS and your apple sanctioned update should proceed without any errors

Hey! Can I message you in telegram or some other messenger? Need your help running the command.
It can not find .../apfs_systemsnapshot for me

Sure, just add your contact email to your github profile and I can email you my signal contact.
Or just go to my profile and use the email I'm publishing to send me yours.

Does changing snapshot mess up the with the data current one I have on mac ?

Thanks for the fix it worked.

No problems, glad it helped!

Does changing snapshot mess up the with the data current one I have on mac ?

The snapshot is only for the MacOS system image, this wont affect your user data.

Eg: if you (or some software) does a change to the system image and then creates a snapshot. If you remove that snapshot using this method, then the only data lost is the changes made to the system. (eg: a config file change)

Thanks for the fix it worked.

Can you share the fix please ?
It can not find .../apfs_systemsnapshot for me to

It should be there, but it is a long path and its easy to typo when you can't paste into the console.
Other people have also had this issue where they can't find it, but were able to locate it with the following trick:

I would suggest using 'Tab Completion' as you type the path, ie: type just the first few letters of each path component, then press tab once or twice to automatically complete the path component (it it just beeps, then press tab again to see the options available and then type some more letters to narrow it down and press tab again)

I hope this helps. (You probably know this trick already, but good luck)

hi -

I found your solution for this problem, but can’t seem to get it to work, I’m not sure why! I’m on Sonoma 14.4.1 and trying to update to 14.6.1.

I figured out that the path is slightly different for the file, mine is Filesystems, like so:

/System/Library/Filesystems/apfs.fs/Contents/Resources/apfs_systemsnapshot

then what you noted, but yet still can’t seem to ‘tag’ the old snapshot as the next bootable one. When I run the command in terminal it just gives me information about command and the usage

EDIT: I was able to get it working after giving it one more try. It turns out that for some reason whenever I rebooted into Recovery mode after disabling SIP it re-enabled SIP, I didn't realize this. This time I did not reboot after disabling SIP, but just continued on with tagging the prior snapshot. That worked, thanks!!

I figured out that the path is slightly different for the file, mine is Filesystems, like so:

/System/Library/Filesystems/apfs.fs/Contents/Resources/apfs_systemsnapshot

Thanks, you found a typo and I have corrected the original Gist
Good to hear that you got it working and very interesting to hear that the SIP disable didn't persist past a reboot.

Hi,

Thanks for all this. I get this problem trying to upgrade from Sequoia 15.2 to 15.3.

I can report that SIP disable, for me, does persist after a reboot.

In disk utility, it is also possible to copy the snapshot name then paste it into the terminal for tagging. All you have to do is delete the file information (timestamp etc.) that is copied along with the com.apple. . . name.

However, I cannot solve my problem. Following the method here, I get the message that the snapshot cannot be found (I'm using .../Filesystems/...).

On another forum, it was also suggested to reset the NVRAM—this I have also tried without success.

Any further ideas?

EDIT: A little further update on this. I have made some progress. Unlike the previous poster, rebooting back to recovery mode after setting csrutil disable seemed to be required to produce a result in that, issuing the tagging command, I got the message 'Attempting tagging . . .' then back to the prompt without any indication of success or not. However, in disk utility, I still cannot select the snapshot and delete it— the '-' is disabled.

I can report that SIP disable, for me, does persist after a reboot.

Interesting we see different behaviour on different machines.

In disk utility, it is also possible to copy the snapshot name then paste it into the terminal for tagging. All you have to do is delete the file information (timestamp etc.) that is copied along with the com.apple. . . name.

Ok thats good to know, but from what you describe it sounds like the tagging didnt work and the snapshot is still the active one, and is therefore greyed out.

EDIT: A little further update on this. I have made some progress. Unlike the previous poster, rebooting back to recovery mode after setting csrutil disable seemed to be required to produce a result in that, issuing the tagging command, I got the message 'Attempting tagging . . .' then back to the prompt without any indication of success or not. However, in disk utility, I still cannot select the snapshot and delete it— the '-' is disabled.

Hmm, I think try again and once you have run the command try 'echo $?' and see if you get a '0' indicating success.
Any other number indicates an error.

Unfortunately it seems apfs_systemsnapshot is not very verbose and may have silently failed on you.

Many thanks for the quick response. I tried again and used the echo $? on both the mounting and the apfs_systemsnapshot commands—both gave 0. Although it seems the tagging has indeed worked, the '-' is still greyed out.

EDIT 1: Amazing! Coming back to here to report on my latest attempts, I forgot to go into the recovery console to re-enable SIP. I thought I'd give the update one last try before rebooting and re-enabling SIP. And . . . I'm now about halfway through downloading about 2GB of OS update! Previously, the update had quit after about 5 seconds. I will report back here later on final success (or not).

Perhaps it's having SIP disabled (and then attempting the update), Perhaps it's having SIP disabled and the tagging (apparently) done. Certainly previous attempts to update following tagging when I had re-enabled SIP have all failed.

EDIT 2: Success! I'm now a happy Sequoia 15.3 user. Thanks for the help!

Excellent, great news, enjoy!

Have you heard of this issue for Sequoia 15.3.1? Any Sequoia system? I seem to have the version of the narrative with the grayed out minus button. Anyway, thanks!

@loshlee I think the issue is popping up for all versions using this. I would suggest to try aggressively re-enabling SIP for each step, perhaps it will help you also (as it did for @sirfragalot , and please report back here either way. Cheers!

Thanks. I use Carbon Copy Cloner (latest version, 7.0.4) rather than Time Machine for my incremental backups, so I also reached out to Bombich.com for help. I was told:
"As a way to secure the OS, the macOS now runs from an encrypted snapshot, leaving the actual volume untouched.

This system snapshot can not be removed.

CCC will show any removable snapshots in the volume information for that volume. Select the volume name from the list on the left side of the screen."

I didn't see any "removable" snapshots.

When I asked why the system snapshot had just appeared in Disk Utility about 3 days ago, and why the Finder is displaying about 45 G less available space than before that snapshot appeared in Disk Utility, I was told that they didn't have an answer because they could only view my Carbon Copy Cloner logs. Now I'm wondering whether my issue is different from the one for which you found a solution. Do you have a way to know whether the issue you've described differs from mine? Thanks again.

I've just updated from 15.3 to 15.3.1—having solved the issues I had updating to 15.3 (see above), the update to 15.3.1 proceeded without a hitch.

@sirfragalot, thanks, this is good to know.

@loshlee it sounds like CCC created the snapshot, and it also sounds like the one it created is the currently active one (and hence greyed out since you can't delete a snapshot if you have just booted from it)

If CCC created, then it should say this to the RHS of the snapshot list (under the 'Kind' column heading) if you were using time machine, then it would say "Time Machine Snapshot", if this field is blank, then maybe something else created it?
It does seem strange though as CCC and Time Machine do not normally create snapshots over the system snapshot.

If you can get to step 4 in my instructions and then reboot, in theory the snapshot should be no longer active and you should be able to delete it.

It wasn’t Time Machine, but it was current, apparently, because attempting to delete it in Recovery mode using Disk Utility resulted in “read-only file system” error and renaming it caused Recovery's restart to require an overlay (in-place) installation of macOS Sequoia (15.3.1). The vexing issue is still that Finder began showing 45G less available space and Disk Utility began revealing the apfs snapshot in question at the same time and only a few days ago. Thanks.

Ahh ok, that explains it. Thanks for the update.

diskutil apfs listSnapshots /disk3s1

can directly get the snapshot's name from the terminal.

You can execute

diskutil list 

to know how many disk you have in the computer.