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

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.

On macOS 26 Tahoe, I was experiencing the same issue while upgrading from beta 1 to beta 2.
There were two snapshots.

• com.apple.os.~
• com.apple.bless.~

I don't exactly know what bless is, but for me, I guess the bless snapshot was selected as bootable one since it was undeletable (minus button was disabled).
Just tagged the os snapshot as the next bootable one, and problem solved.

Excellent, thanks @jhaemin good to know this works with beta mess ups also 👍

@psymonryan Thank you for the instructions.