My love for Apple and especially MacOS does not run deep. Actually, it is essentially nonexistent. I was recently reminded of the myriad reasons why I don’t like MacOS, and one of them is that the OS should never stand in the way of what the operator wants to do. In this case, I found that even the root account couldn’t write to certain directories that MacOS deemed special. That “feature” is known System Integrity Protection. I’m not going to rant about how absurd it is to disallow the root account the ability to write, but instead I’d like to present the method of disabling System Integrity Protection.
First of all, one needs to get into the Recovery Mode of MacOS. Typically, this wouldn’t be all that difficult when following the instructions provided by Apple. Essentially, to get into Recovery Mode, one just has to hold Command+R when booting up the system. That’s all fine and dandy if it is a physical host and one has an Apple keyboard. However, my situation called for Recovery Mode from a virtual machine and using a non-Apple keyboard (so no Command key). Yes, yes, I know that MacOS offers the ability to set different key combinations, but then those would still have to be trapped by VMWare Fusion during boot. Instead, I figured that there had to be a way to do it from the MacOS terminal.
After digging through documentation and man pages (I’ll spare you the trials and tribulations of trying to find answers 😛 ), I finally found that, yes, one CAN reboot MacOS into Recovery Mode without the command key. To do so, open up the Terminal and type the following commands:
nvram "recovery-boot-mode=unused"
reboot recovery
The Apple host will reboot and the Recover Mode screen will be presented:
Click to enlarge
Now, in the main window, there are plenty of tasks that can be launched. However, I needed a terminal, and it might not be readily apparent, but to get it, you click on the “Utilities” menu in the top menu bar (see the screenshot above), and then select “Terminal”. Thereafter, it is fairly simple to disable System Integrity Protection via the following command:
csrutil disable
All that’s left is to reboot by going to the Apple Menu and clicking on “Restart”.
Though the procedures of getting to the MacOS Recovery menu without using the Command key and disabling System Integrity Protection are not all that difficult, they were a pain to figure out. Furthermore, I’m not sure why SIP disallows root’s write permissions anyway. That seems absurd, especially in light of Apple’s most recent glaring security hole of allowing root access without a password. 😳
Cheers,
Zach
10 comments
Skip to comment form
Omw I have apple 2009 old baby and I am so happy with her so I play all my games from 100 years ago on her. Then I upgraded her to Yosemite and she was happy then the new upgrade come f..k nut El capitan and all my crap start .
Been struggling 3 days to reset her, please help meeeee
Author
Hello Yacub,
I do not offer individual support. You can either contact Apple, or try searching for information regarding a full factory reset.
Cheers,
Zach
I love this method and find it really useful – I just wanted to add this: On a new T2 Mac that is powered down, you *do not* need to hit the power button then guess the timing for CMD-R. Just press CMD-R instead and the machine will start. Hold CMD-R until you see the progress bar under the apple and then you can release. Voila – manual recovery mode is easier than it used to be!
Author
Thanks for the added information, Chris!
Cheers,
Zach
Hi I managed to enter in terminal mode
But when submit
csrutil disable
it says csrutil: command not found
Where it can be found?
Author
Hello Hakan,
I personally don’t use MacOS, and without knowing the version that you’re using or more about the environment, it’s really difficult to say why you ran into that problem. You may want to look at the developer resources provided by Apple:
https://developer.apple.com/library/archive/documentation/Security/Conceptual/System_Integrity_Protection_Guide/ConfiguringSystemIntegrityProtection/ConfiguringSystemIntegrityProtection.html
Cheers,
Zach
If I may ask 2 short questions:
1) Does it* still work with latest Mojave? (*it = reboot from terminal into recovery)
2) How to reset nvram argument afterwards, or is it only valid for one session?
Gotta be cautious nowadays, I’d rather ask before act.
Thanks
Author
Hello Joe,
I can’t confirm that the command is the same to reboot into recovery for Mojave, but you can still do so via these instructions:
https://www.macworld.co.uk/how-to/mac-software/mac-recovery-mode-3674052/
You don’t need to worry about resetting the NVRAM arguments after the fact.
Cheers,
Zach
OMG, thank you!
This was driving me insane, and Googling for it was useless. What the hell is going on with Apple? Being able to get into recover (or select an alternate boot volume) used to not only work with Macs, but also be easy. Wait for the chime, press your keys.
Then, they removed the chime, because they apparently hate us, and it started to get tricky to time it. Try, fail, repeat. Great fun. Now, FFS, they don’t even connect the keyboard until AFTER the whole boot sequence is completed. WTF Apple c**ts?!?!?
Every update to macOS since Mavericks has made everything worse. The hardware is getting worse as well. F**K YOU APPLE.
But thank you! And also, you might wanna update the commands to include the necessary `sudo` prefix. Also, I accidentally wrote `sudo reboot recoveryt` (because the new Apple keyboards are shit), and tapped enter before correcting it, and it still booted to recovery. Not sure if that’s because the argument isn’t needed, or because it falls back to recovery for unknown values there.
Cheers!
Author
Hello Daniel,
You’re welcome; I’m glad that you found the article helpful. Apple is notorious for making simple tasks exponentially more difficult than they need to be. I find that their OS reflects a mentality of their users being incapable of understanding basic functionality, and so they want to “shield” everyone from these types of tasks. The `sudo` prefix is only necessary if your login user is not an administrator.
Cheers,
Zach