I wanted to make a thread just to raise general awareness about the dangers and caveats of modifying system files in Big Sur, since I feel this doesn't really get highlighted enough.
In many tutorials regarding modification of system files in Big Sur (eg: customizing icons for Apple's built-in apps), steps similar to the following are suggested, granted that the older and simpler method used in Catalina, "sudo mount -uw /", is no longer valid.
What does "csrutil authenticated-root-disable" do?
Usually, most CLI commands like "csrutil" have a "man" page that explain their usage. If you run "man csrutil", you'll quickly discover Apple actually does a poor job documenting the command and what various flags do. In addition, the man page in Big Sur is very outdated, dating back to 2017. In any case, what the "authenticated-root disable" option does is set a PRAM flag to disable SSV (Sealed System Volume) checks at boot for the root volume. Any time you modify system files and commit the changes as in step 3 above, you are effectively "breaking the seal" on the volume, meaning it no longer matches Apple's signature of what an unmodified system volume should look like, and therefore the drive will no longer normally be bootable. ElectricLight.co has this page and this page that have a more complete explanation of how SSV works in Big Sur.
What are the caveats of modifying system files / breaking the seal of the root volume?
Fortunately, all you need to do is boot into recovery mode, which should still work since it's separate from the root volume. You can just reinstall macOS, and this will in turn overwrite all system files, setting them back to default and undoing any customizations, and thus making the root volume pass any cryptographic signature checks again with SSV. All non-system files should remain intact (eg: User folder, 3rd party applications, etc.) as those reside on a separate "Data" volume. You can also make a bootable USB installer and try that if Recovery Mode doesn't work.
The bottom line:
Don't mess with system files in macOS Big Sur unless you know what you're doing and are willing to run your Mac with SSV disabled via "csrutil authenticated-root disable" set forever. You'll need to remember that if your drive suddenly fails to boot one day with no explicit errors, it could be that SSV somehow got re-enabled (you can check via Disk Utility via "csrutil authenticated-root status" from Recovery Mode). You'll need to remember that if your drive is portable, you also need to disable SSV on each and every Mac you plug it into or it'll fail to boot, again with no explicit errors.
In many tutorials regarding modification of system files in Big Sur (eg: customizing icons for Apple's built-in apps), steps similar to the following are suggested, granted that the older and simpler method used in Catalina, "sudo mount -uw /", is no longer valid.
- Disable FileVault if enabled, boot into the Recovery Mode, launch Terminal, and issue the following (this is also known as "disabling SSV"):
Code:csrutil disable csrutil authenticated-root disable reboot
- Boot back into macOS and issue the following:
Code:
mount
Code:mkdir ~/Desktop/mount sudo mount -o nobrowse -t apfs /dev/diskXsY ~/Desktop/mount
- Navigate to the "mount" folder and make desired changes to system files (requires "sudo" privileges), then commit the changes via:
Code:sudo bless --folder ~/Desktop/mount/System/Library/CoreServices --bootefi --create-snapshot sudo reboot
What does "csrutil authenticated-root-disable" do?
Usually, most CLI commands like "csrutil" have a "man" page that explain their usage. If you run "man csrutil", you'll quickly discover Apple actually does a poor job documenting the command and what various flags do. In addition, the man page in Big Sur is very outdated, dating back to 2017. In any case, what the "authenticated-root disable" option does is set a PRAM flag to disable SSV (Sealed System Volume) checks at boot for the root volume. Any time you modify system files and commit the changes as in step 3 above, you are effectively "breaking the seal" on the volume, meaning it no longer matches Apple's signature of what an unmodified system volume should look like, and therefore the drive will no longer normally be bootable. ElectricLight.co has this page and this page that have a more complete explanation of how SSV works in Big Sur.
What are the caveats of modifying system files / breaking the seal of the root volume?
- Obviously, you need to take general precautions when modifying any system file, as it can break your installation (as has been true for as long as macOS itself has existed). But beyond that, if something were to go wrong in step 3 when you bless the folder and create a snapshot, you could also end up with an non-bootable system.
- You'll need to keep SSV disabled (via "csrutil authenticated-root disable") forever if your root volume has been modified. This in turn means that:
- If you modified system files on a portable installation of macOS (ie: on an external drive) via this method, any host computer you plug it into will fail to boot the drive if SSV is enabled on the host. If the host machine natively has Catalina or older installed to its internal disk, its native Recovery Mode will not support the "csrutil authenticated-root" flag in Terminal. Therefore, you'll need to force it to boot into the external drive's Recovery Mode by holding "option" at boot, selecting the external disk that has Big Sur, and then immediately hitting "command + r" in just the right timing to load Big Sur's Recovery Mode. This can take several attempts.
- If you zap the PRAM of a computer and clear its flags, you'd need to boot into Recovery Mode and repeat step 1 to disable SSV again, as it gets re-enabled by default.
- Every time you need to re-disable SSV, you need to temporarily turn off FileVault each time. If your Mac has a corporate/school/etc. enrollment profile that requires FileVault being enabled at all times, this can lead to even more of a headache.
- When you boot a Mac that has SSV enabled, there's really no explicit error seen during a signature failure, at least in a normal GUI boot (ie: boot screen that has an Apple logo and progress bar). The progress bar will make it maybe 5%, followed by the computer suddenly ramping up its fans and shutting itself down. Unless you remember this caveat regarding SSV, this can lead to some very confusing situations to the untrained eye that can make it seem like the drive or macOS install is corrupted. In addition, if you boot into Recovery Mode and run Disk Utility, all checks will technically pass for the physical disk and its container, although you'll see a warning when checking the container stating:
Code:
warning: snapshot fsroot/file key rolling tree corruptions are not repaired; they'll go away once the snapshot is deleted
Fortunately, all you need to do is boot into recovery mode, which should still work since it's separate from the root volume. You can just reinstall macOS, and this will in turn overwrite all system files, setting them back to default and undoing any customizations, and thus making the root volume pass any cryptographic signature checks again with SSV. All non-system files should remain intact (eg: User folder, 3rd party applications, etc.) as those reside on a separate "Data" volume. You can also make a bootable USB installer and try that if Recovery Mode doesn't work.
The bottom line:
Don't mess with system files in macOS Big Sur unless you know what you're doing and are willing to run your Mac with SSV disabled via "csrutil authenticated-root disable" set forever. You'll need to remember that if your drive suddenly fails to boot one day with no explicit errors, it could be that SSV somehow got re-enabled (you can check via Disk Utility via "csrutil authenticated-root status" from Recovery Mode). You'll need to remember that if your drive is portable, you also need to disable SSV on each and every Mac you plug it into or it'll fail to boot, again with no explicit errors.
Last edited: