I have disabled SIP, I have read/write permissions with terminal, but not with Finder. What causes this?

Question

System: macOS Catalina 10.15.2

Background: I've been a *nix user for many years. I use a remote Linux server where the root directory is used (i.e. there are folders where users can r/w such as /data and /analyses ), and I've used macOS in the same way until now. I got a new MacBook from my workplace this year. I administer the machine, so I am able to change anything that root can.

In the interest of continuing to use the file organization system on our remote server, I have disabled SIP and I'm mounting / with read/write on each boot (similarly to how it is done here). I can work in the /data and /analyses folders using the Terminal with no issues, but when it comes to using Finder, this is not the case. Creating and deleting folders and files is not possible with Finder. This is not the case with other GUI apps (for example, I'm able to use a text editor such as Sublime to edit plain text files in these folders, or create and save new ones into the directory of my choosing).

Issue: When I use Finder to move or modify these files (for example, dragging a file to Trash) I get a warning message: "file" can't be modified or deleted because it's required by macOS. I can delete or modify these files with other apps, including Terminal, but for convenience sake I'd like some help finding a solution to this issue with Finder (for example, is there something I could change w/r/t Finder's permissions, or with the permissions set by macOS for the directories I'm working in).

What I've already tried: changing the file and folder permissions/ownership with chmod and chown, with no effect on Finder's behavior

p.s. Unless you are certain it will directly help to solve this issue with Finder, thank you in advance for leaving out any lectures about why I should re-enable SIP, I've already heard them all. :)

Answer 1

If you need to create directories off the root, the best option is to use firmlinks, which can be configured using /etc/synthetic.conf. From the manual page:

...
synthetic.conf is intended to be used for creating mount points at / 
(e.g. for use as NFS mount points in enterprise deployments) and symbolic
links (e.g. for creating a package manager root without modifying the
system volume).  synthetic.conf is read by apfs.util(8) during early sys-
tem boot.
...

If you create /data and /analyses elsewhere and then have the links managed by synthetic.conf, you should be able to avoid disabling SIP and be able to access those directories from Finder.

Answer 2

I use a remote Linux server where the root directory is used (i.e. there are folders where users can r/w such as /data and /analyses )... In the interest of continuing to use the file organization system on our remote server, I have disabled SIP and I'm mounting / with read/write on each boot

This is not a good strategy and should be avoided.

The first and most important thing to realize is that macOS ≠ Linux. What Linux lets you "get away with" is not always a best practice for system administration. When we reduce everything down, what you're essentially asking is about placement of two folders and the root directory is actually not the best place for them, thus the issues you're running into.

Disabling SIP, you remove one of the key protections that make macOS one of the safest operating systems on the market today. Doing so to get around the security architecture so that you can create folders/mount volumes that reside in the root directory is counterproductive. Instead of fighting against the OS, it's best to work with it.

• Is /dev protected by SIP?
• Other than user error, what types of attacks would SIP prevent?
• How to repair macOS permissions after running “sudo chown -R _www /”? (A cautionary tale)

Unless you are certain it will directly help to solve this issue with Finder...

It's not an issue with Finder. SIP's been around a long time; since El Capitan (10.11) was released in 2015. This is not anything new. However, the new APFS container structure of having two volumes, one writable and one not (with - Data appended to the volume name) is new. While some of the security changes Apple has implemented causes more headaches than necessary, this isn't one of them.

This is actually something that system admins should be doing - hardening the system and limiting what and where the user can write to by "containerizing" (sandboxing) the directories/volumes with appropriate read/write/execute permissions.

Mount user accessible directories in the proper location

Again, the root directory is not really an appropriate place for shared data whether it be macOS or Linux. Whether these directories are local to the Mac (the Mac is the network share), or you're mounting them from a remote file server, they should be placed in a protected volume like in /Users/Shared or mounted in /Volumes. The reasoning behind this is that you can set the "parent" rights and apply it to all of the child folders whereas if you were to modify the rights of something in the root directory, you could potentially apply the wrong permissions across the whole system.

Even my Synology NAS (Linux based) doesn't allow me to create shares on the root folder. It forces me to mount them in a sub volume with permissions I (with root access) cannot modify.

TL;DR

You're going against the current here; work with the OS and not against it. If you're finding that you need to disable all of the protections that the system came with, you're likely not following an industry best practice. Don't try to force macOS and Finder to behave a certain way because you can "do it in Linux;" follow it's lead and you'll have a secure, available, and most importantly a reliable system that your users can depend on.