Yes, Mac has many enhancements to Unix in the area of files. Ignoring the whole resource fork thing which is not used much anymore, there are:
- the standard Unix permissions
rwx and so on. Normal Unix tools apply.
- ACL's, viewable with
ls -le and changeable with
chmod [ -a | +a | =a ].
- file flags viewable with
ls -lO (Capital oh, not zero) and changeable with
- extended attributes, viewable with
ls -l@ (attribute keys only) and viewable and changeable with
xattr -h for help if
man xattr does not give you anything.)
- Starting with OS X 10.11 "El Capitan", System Integrity Protection (SIP) further protects some files from changes from ordinary processes, even when using
sudo to run as
root. Files protected by SIP will be listed by
ls -lO as having the
restricted flag and/or be listed by
ls -l@ as having the
You can be denied operations on a file because of Unix permissions, ACLs, file flags, or SIP. To fully unlock a file:
sudo chmod -N file # Remove ACLs from file
sudo chmod ugo+rw file # Give everyone read-write permission to file
sudo chflags nouchg file # Clear the user immutable flag from file
sudo chflags norestricted file # Remove the SIP protection from file
sudo xattr -d com.apple.rootless file # Remove SIP protection from file
If System Integrity Protection (SIP) is enabled,
sudo chflags norestricted and
sudo xattr -d com.apple.rootless will also return an "Operation not permitted" error. To clear the flag and/or attribute you need to boot into macOS Recovery and either run the commands from Terminal (you may have to first use Disk Utility to unlock and mount your boot drive, then remember your files will be under
/Volumes/Macintosh HD or whatever your boot drive is named) or disable SIP altogether and then reboot and the commands should then work. Be aware, however, that future OS updates will likely restore the
restricted flag and
com.apple.rootless attribute to any files you removed it from.
Disabling SIP is not recommended as it removes lots of protection against malware and accidental damage, plus it is not necessary when you can simply remove the protection on a per-file basis. If you do disable SIP, re-enable it when you are done making changes.
Note that if
ls -lO shows the
schg flag is set, you have to get into single-user mode to unset it. I'm not going to get into that here as there are bigger questions about why the file has that flag set and why you are trying to mess with it and what the consequences will be.