Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

Takuro

macrumors 6502a
Original poster
Jun 15, 2009
584
274
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.
  1. 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
  2. Boot back into macOS and issue the following:
    Code:
    mount
    Note the "X" and "Y" values in "diskXsYsZ" on the first line, which should be "/" (the root mount), then run the following (dropping the "sZ" part) to mount it to a folder:
    Code:
    mkdir ~/Desktop/mount
    sudo mount -o nobrowse -t apfs /dev/diskXsY ~/Desktop/mount
  3. 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
However, be aware that the above comes with some risks, which are oftentimes not explicitly mentioned in such tutorials.

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
    However, that message is misleading, as no repairs will actually be done, granted you intentionally modified the root volume itself, and the Mac will continue to fail to boot the drive so long as SSV is enabled.
How do I undo these changes (allowing a drive to boot normally again with a Mac that has SSV enabled)?
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:

Takuro

macrumors 6502a
Original poster
Jun 15, 2009
584
274
I'd say: always have a bootable full backup ready ....
;JOOP!
Yep. Just be careful that some apps that automate macOS disk cloning and whatnot are not designed to handle the concept of SSV yet and will therefore not be bootable if SSV is enabled. Time Machine obviously works fine.

But realistically, so long as you keep calm and remember SSV exists, if re-disabling SSV checks via Recovery Mode doesn't make it bootable again and the root volume is truly screwed, reinstalling macOS will fix it but at the cost of losing any customized system files.
 
  • Like
Reactions: myfranco

myfranco

macrumors newbie
Nov 3, 2019
12
1
Istanbul
Yep. Just be careful that some apps that automate macOS disk cloning and whatnot are not designed to handle the concept of SSV yet and will therefore not be bootable if SSV is enabled. Time Machine obviously works fine.

But realistically, so long as you keep calm and remember SSV exists, if re-disabling SSV checks via Recovery Mode doesn't make it bootable again and the root volume is truly screwed, reinstalling macOS will fix it but at the cost of losing any customized system files.
Thanks for the explanation. I was looking a way to change com.apple.nfsd.plist to enable my shares on MAC to stream to my Xiaomi Mi Box 4S. That sucks. I'm stuck with SMBv1 now.
 

Kimberlyb47

macrumors newbie
Dec 13, 2022
5
0
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.
  1. 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
  2. Boot back into macOS and issue the following:
    Code:
    mount
    Note the "X" and "Y" values in "diskXsYsZ" on the first line, which should be "/" (the root mount), then run the following (dropping the "sZ" part) to mount it to a folder:
    Code:
    mkdir ~/Desktop/mount
    sudo mount -o nobrowse -t apfs /dev/diskXsY ~/Desktop/mount
  3. 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
However, be aware that the above comes with some risks, which are oftentimes not explicitly mentioned in such tutorials.

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
    However, that message is misleading, as no repairs will actually be done, granted you intentionally modified the root volume itself, and the Mac will continue to fail to boot the drive so long as SSV is enabled.
How do I undo these changes (allowing a drive to boot normally again with a Mac that has SSV enabled)?
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.
I followed steps in another thread that included the “csrutil disable” and “csrutil authenticated-root disable” commands and after I finished what I was doing, reenabling them caused a reboot loop of kernel panics. Disabling them fixes the problem but I don’t want to keep them disabled because I know it isn’t safe. I found my way to this thread and saw that you said reinstalling my os (Big Sur) would fix any customizations I may have done, but after reinstalling the OS, the “csrutil” and “csrutil authenticated-root” were both still disabled. Since this (aside from renaming and removing a thunderbolt kext file) is all I did, can I just re-enable them? Is it normal that they didn’t re-enable when I reinstalled the OS?

My initial problem is that unless I disable (or move) two thunderbolt files (changing them from .kext to .kext.BAK) I get constant shutdowns. This has worked for me for years but upgrading to Big Sur means there has to be a workaround and it appears people haven’t quite figured it out yet. So I upgraded to Big Sur and attempted to fix the shutdown issue. Within these new steps, they included the authenticated-root step which I have never used before. Well, upon finishing my steps, I was stuck in a reboot loop of kernel panics and had to get back into recovery mode. I then deleted (instead of just moving the thunderbolt file) and this time the steps didn’t tell me to re-enable like they usually do but I did what it said. I rebooted and the shut downs were fixed but then I went back into recovery mode to enable those things. That set me back to a reboot loop of kernel panics. 🤦🏻‍♀️

I tried a clean install and the file I removed was back but I checked the csrutil authenticated-root status and it was still disabled. I did the steps without “csrutil disable” and “csrutil authenticated-root disable” and it didn’t work. I tried again and just left out the second one but it’s still giving me kernel panics. So the only thing left is to just keep both disabled to get my computer to let me inside. But I really don’t want to leave it like that. This is so insane. I work from home full time on this thing so you can imagine the frustration!

Also, while following these steps I ended up making not just one extra snapshot but two. I don’t know if that’s ok.. I can’t even manage to get back into my machine at this point because apparently the shutdown fix didn’t work with leaving those steps out so I’m now reinstalling Big Sur for the third time tonight 😄 to start again from the beginning and then I will at least be able to get back into my computer without experiencing the shutdowns.

Does anyone have any idea how to fix this issue? I saw a couple people suggesting open core legacy patcher, but I’m concerned because I’ve never heard of it and I’m worried about signing into all of my important information once I have that running. Anyone know if it’s safe?
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.