Currently Running: macOS Catalina 10.15.1

Issue: Ever since I upgraded to Catalina, macOS is not allowing me to change read and write permissions on system protected files, hence, I am not able to tweak the system as per my likes and dislikes.

Steps Tried To Solve The Issue: SIP, always remains disabled on my boot drive. So, no question arises regarding any conflict with system integrity protection.

I have also tried to force change the permissions on the system files I want to edit using certain brute force commands, which I can't recall the name of, right now. But, I have tried.

As of now, I am still unable to change read and write permissions on system protected files and resources.

  • Which files are you trying to change? Catalina stores most system files on a separate read-only volume; this overlaps with SIP's protection, but it's actually independent of SIP and disabling SIP doesn't make the volume read-write. See the Ars Technica review of Catalina for more details. – Gordon Davisson Nov 20 '19 at 6:04
  • @GordonDavisson I am trying to edit system core services – Sayan Nov 20 '19 at 6:24

Catalina introduced a new feature that overlaps and reinforces the filesystem protections that SIP provides. What it does is split the files between two volumes: a system volume containing Apple-provided system files, and a "data" volume containing all non-Apple and modifiable files. The system volume is mounted read-only as / (the root filesystem), and the data volume is mounted with read-write access as /System/Volumes/Data. There are also "firmlinks" that merge the content from the data volume in where it "belongs" (e.g. /System/Volumes/Data/Users shows up in /Users). If you change something in a firmlinked directory, the changes are stored on the data volume. If you try to change something in a non-firmlinked directory, it'll fail because it's on a read-only volume (even if SIP is completely disabled).

For more details, see the Ars Technica review of Catalina, the WWDC2019 sesson "What's New in Apple File Systems", and a filesystem map from the Eclectic Light Company.

If you really need to make changes in the content on the read-only system volume, it is possible, but I'd recommend against it if there's an alternative. Most of the things you normally want to change/add/etc can be done from modifiable parts of the filesystem (e.g. using /usr/local instead of /usr). So the rest of this comes with a warning.

Warning: I have not tested this much, and make no promises at all about what the consequences will be (including both immediate consequences, and what happens the next time an OS update changes things). Do you have any important files on this Mac? Do you have a good backup? Do you feel lucky?

To make changes to the normally-read-only volume, you need to both disable SIP's filesystem protection and also re-mount the volume with read access:

  1. Restart in Recovery mode (Command-R at startup), open Terminal (from the Utilities menu), and disable SIP filesystem protection with:

    csrutil enable --without fs
  2. Restart normally, open Terminal, and remount the root volume for read access:

    sudo mount -uw /

At this point, you should be able to make changes everywhere (subject to normal filesystem protections) up until the next restart. Disabling SIP's filesystem protection survives restarts, but remounting with write access does not. If you want everything to be writable after restarting, you'll have to repeat the sudo mount command after each restart. What I'd recommend, though, is locking everything back down as soon as you've made the necessary changes. To do this, restart in Recovery mode, run csrutil enable, then restart again normally.

  • does SIP in any away affects the performance of one's OS? – Sayan Nov 20 '19 at 8:56
  • @Sayan Not that I'm aware of, although I haven't seen anyone test it specifically. I'd expect that if there is any impact, it'd be minimal. – Gordon Davisson Nov 20 '19 at 16:52

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .