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. :)

  • 4
    The short answer is.. It is by design (or should I say, lack of design) and you cannot change it! Contact Apple at: Product Feedback Apr 15, 2020 at 20:06
  • @user3439894 i'd be happy to accept this as an answer if you write it as one, with a bit more detail explaining why this behaviour cannot be changed
    – ovon
    Apr 15, 2020 at 22:13
  • 1
    I'd have to go back and redo the research I did when macOS Catalina became available to be able to site more authoritative sources; however, the short answer on why the user can't change it is because it's hard coder in Finder's source code. Just like with changing the setting to allow hidden folders to show, Apple does not allow /dev to show in Finder or let you use ⇧⌘G (Go to Folder…) to take you there, and there was a time they used to, but now it's hard coded in source code so one can't. Apr 15, 2020 at 22:38
  • @user3439894 thanks, that's basically all i needed to know. whether or not it's possible and roughly why. appreciate your expertise!
    – ovon
    Apr 15, 2020 at 22:51
  • BTW There is a paid app named Path Finder, which has a free trial, and is file manager for macOS. You could give it a try and see if can do the things you want that Finder won't. (I'm not affiliated with the developer of this product.) Apr 15, 2020 at 23:50

2 Answers 2


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.

  • thanks, i appreciate that this addresses my question in different way than previous comments, and more directly than the other formal answer. i'm going to mark this as the accepted answer.
    – ovon
    May 5, 2020 at 8:46

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.

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.


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.

  • 3
    although i appreciate the detail, you are reading things into my post that aren't there, so I will make it more clear: there's no "share" or NAS involved here. these are directories that I created, not mount points. they're rsync-ed manually, when needed. the mac in question isn't network accessible, the remote linux machine is. I'm not concerned with what Apple or the "industry" considers best practices, so please don't waste your breath trying to convince me of the benefits of following along as they rip control of the computer from me.
    – ovon
    Apr 15, 2020 at 22:04
  • 2
    Whether these directories - the operative word being "whether" meaning it doesn't matter what you're using them for. Best practices are best practices for a reason (at least one important one); they mitigate risk. If you want to go your own route, that's cool; it's just means macOS isn't the tool for you, Linux is.
    – Allan
    Apr 15, 2020 at 22:16
  • 1
    RE: How to repair macOS permissions after running “sudo chown -R www /”? (A cautionary tale) -- This really does not belong in your list because the command he actually ran, sudo chown -R _WWW:_WWW /, as it's been edited since, is fully capable of messing up parts of the system without disabling SIP. In a clean built macOS Catalina 10.15.4 VM, that command just changed the _ownership and group on 54,700+ files/directories and totally messed the system up while SIP was enabled! Apr 16, 2020 at 22:50
  • Here's a link to a zip archive of the files that command touched: gofile.io/?c=rzjW7P Apr 16, 2020 at 22:50

You must log in to answer this question.

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