Undeletable file

TidBITS Talk
21

All of the following is done as root after su admin and su root in terminal.

Ls -lO with pwd of /SharedSupport inside the package gives me

-rw-r–r-- 1 root wheel restricted 5544818527 Dec 12 2020 InstallESD.dmg

One directory up at SharedSupport gives me

drwxr-xr-x 3 root wheel - 96 Dec 12 2020 SharedSupport

And one more up at /Contents

drwxr-xr-x 3 root wheel - 96 Dec 12 2020 Contents

And one more up at /tmp

drwxr-xr-x 3 root wheel - 96 Dec 12 2020 Install macOS Mojave.app

Following tjluoma’s suggestion for using

sudo rm -fv InstallESD.dmg

And then continuing his suggestions again I still get Operation not permitted on the delete file command and ls -lO in the SharedSupport directory gives me

-rw-r–r-- 1 root wheel restricted 5544818527 Dec 12 2020 InstallESD.dmg

Storage that it shows restricted even as root…I’ll give Single User mode a try later on…shrug.

22

Ah! Hopefully “restricted” pinpoints the issue.

Apparently restricted from ls -lO may mean “System Integrity Protection (SIP) prevents changes”, according to (eg) this answer How do I disable System Integrity Protection (SIP) AKA "rootless" on macOs [OS X] - Ask Different.

Perhaps that answer, and other resources on SIP, give you what you need now. Personally though I have no experience meddling with SIP, so I’ll stop here - I don’t want to mislead you with this…

23

https://developer.apple.com/documentation/security/disabling_and_enabling_system_integrity_protection

24

Ashley…yeah, I would rather not muck around with SIP myself although turning it off temporarily and then back on would be ok if needed. However…Steven from yourmacexpert got it right on the nose.

Once I figured out the right way to get into Recovery mode as there have been several different methods over the years as googling how turned out…and once I figured out the correct Recovery Key for the drive (I keep those in a secure note in 1Password and had mistakenly carried over an old one to the current document but found the actual one in the older version of the current document)…I got into recovery and then used Disk Utility to mount both the read only OS volume and the - Data volume associated with it.

From there…it took me another little bit to figure out the correct way to input the drive name (my disk is named Brilliant 4) into terminal to get into the proper directory…turns out that cd /Brilliant4\ -\ /Data is the correct one there…then I was able to drill down into /tmp then the Install app and on down through Contents and SharedSupport to rm -r the .dmg file that was the culprit…then stepped back up through the directory with rmdir as I went up to kill all the other directories and finally the Install app package from /tmp. Then a quick reboot and the offending file is gone. Thanks for all who assisted…I guess Steven deserves the title.

5 Likes
25

Thanks for the info. After reading your message, I started looking for documentation for the various file system flags and so far, I have not been impressed by what I’ve found.,

The concept comes from BSD Unix. OpenBSD only documents a small number of flags (arch, nodump, sappnd, schg, uappnd, uchg): chflags(1) - OpenBSD manual pages.

On my Catalina system, typing man chflags shows what appears to be based on this same set, adding the opaque and hidden flags.

FreeBSD’s version of the command documents a few more flags (opaque, sunlink, uunlink): chflags - FreeBSD

Although Catalina’s man page doesn’t mention the two unlink flags, they are used by the system:

>ls -lO /
total 9
drwxrwxr-x+ 59 root  admin  sunlnk      1888 Aug 20 09:24 Applications/
drwxr-xr-x  75 root  wheel  sunlnk      2400 Jul 22 20:04 Library/
drwxr-xr-x@  8 root  wheel  restricted   256 Jul  9  2020 System/
drwxr-xr-x   9 root  admin  sunlnk       288 Jul  9  2020 Users/
drwxr-xr-x   4 root  wheel  hidden       128 Aug 25 15:01 Volumes/
...

I also found this macOS man page (don’t know what version it comes from), which appears to document all but the restricted flag: chflags Man Page - macOS - SS64.com

I haven’t found any formal documentation that mentions the restricted flag but, as we now know, it means the item is protected by SIP.

And for the curious, Linux does not support these file system flags, but does support a different set of attribute flags that can be set with the chattr command and viewed with lsattr. Some of the flags are functionally equivalent, and some are definitely not: chattr(1) - Linux manual page

1 Like
26

To quote C3PO: “Thank the Maker!”

Well done, @steven1 !

27

You will likely have to go to Recovery…then to Terminal and run csrutil disable to disable Security Protocols. Restart and then you will be able to delete the item. After that, restart and go to Recovery… then to Terminal and enter csrutil enable. Restart and the Security Protocols will be restored. Certain files like left over kexts, and the like, require this because the System will not let them be deleted despite the fact they are orphaned and useless clutter.

28

Thanks John…although that wasn’t necessary as it turned out…just booting into recovery released whatever the operation not permitted was.

29

Excellent!!! Just remember my suggestion for the future.

30

I have to disagree with your guidance to disable SIP when working a problem within Recovery is available. As Neil found, solving his problem was easily and much more quickly solved in Recovery without the necessity to disable and remember to then re-enable SIP.

31

The recommendation was good…and the poster may not have known that recovery had resolved the issue already from the post time stamps.

Still though…disabling and re-enacting SIP is a step that I wouldn’t take unless it was needed…but given the fact that one would be unlikely to forget to reenable it disagree might be a little harsh. Folks were trying to help resolve the issue…and continued after I would have been fine with stopping as once the file was in /tmp it was nothing I was going to worry about…but the technical challenge was still there.

1 Like
32

I know Apple’s documentation implies that a restart necessary after the csruril disable command, but that isn’t true.

As soon as you type csrutil disable (and press return), it’s disabled. Then you can delete the file, and use csrutil enable to turn it back on. No multiple reboots necessary.

1 Like