Undeletable file

TidBITS Talk
13

OK, well now I’m both curious and annoyed at this file.

Try the following, replacing '/tmp/whatever/Contents/SharedSupport/' with whatever folder the InstallESD.dmg is in.


cd '/tmp/whatever/Contents/SharedSupport/'

sudo chflags noschg InstallESD.dmg 

sudo chmod u+w InstallESD.dmg 

sudo rm -fv InstallESD.dmg

If that doesn’t work, try the same commands on the /SharedSupport/ folder and maybe even on the /Contents/ folder, and then try it again.

Report back any output you get from any of those commands. If it works, only the last one should say anything, and that would be the file being reported as deleted.

2 Likes
14

Permissions do not make any difference to garbled directories.

15

Has it been determined this is the problem? I see suggestions that it might be that, but no verification. I’d still check for ACLs or flags. You can check everything with ls -aleO@.

16

Have you tried running First Aid in Disk Utility to see if that makes any difference?

1 Like
17

OK…more info on this one…although since it’s now in /tmp/ at this point and no longer visible unless I go looking for it…and it’s not taking up but a few GB of drive space.

Yep…tried Disk Utility and fsck from the command line after doing su root…all is fine.

Disk Utility does not show it as mounted under All Devices.

Went to /tmp in Finder and drilled down to the .dmg file…right clicked and selected Mount and it mounted and opens just fine…so apparently the image itself isn’t damaged. Unmounted. Went back to terminal, su to admin, su to root, tried to delete the .dmg file from where it’s buried in the package. Operation not permitted even though I answered Y to the question override rw-r–r-- root/wheel restricted for InstallESD.dmg? Y

ls -la in /tmp shows this
drwxr-xr-x 3 root wheel 96 Dec 12 2020 Install macOS Mojave.app

As root…followed tjluoma’s suggestions for chgflgs, chmod, and rm…result operation not permitted.

Tried those same commands on the SharedSupport directory above InstallESD.dmg…failed since directory not empty so didn’t try the Contents directory above that either.

Tried emptying trash with the option key…no luck.

Tried Commander 1 running as admin user…no luck.

Can’t try TDM since I don’t have the right set of cables and adapters to connect TB2 to my iMac.

So…there’s clearly something broke either with the .dmg, the package, or the flag/permission/something else entirely.

I’m happy to just ignore it since it’s not bothering me any more…but OTOH if I’ve roused anybody’s curiosity enough I’m more than happy to keep trying more suggestions…but initializing the volume and starting over is more work than I’m really interested in since everything appears to be just fine except I can’t delete the file.

I didn’t mention before that they laptop doesn’t have the original Apple SSD in it…it was replaced long ago by an OWC 1 TB one…although that’s not likely anything to do with the issue.

18

Can you try ls -lO on the file, to show us the “file flags” and show us the output? (Those options are lower case Lima, followed by upper case Oscar.) That should print something like this:

-rw-r--r--  1 username  wheel  uchg 0 24 Aug 23:46 filename

Note uchg in the fifth column like this… that’s “user immutable”. There’s also schg (“system immutable”, which was mentioned earlier in the thread), and other possibilities: see man chflags.

A file with uchg set on my system gives “Operation not permitted” when I try to remove it. If that is what you are seeing also, try chflags nouchg filename to clear the flag, then try to remove the file again.

2 Likes
19

Ooh! That made me look back and realize that I had left that out of the commands that I had intended to suggest.


	sudo chflags nouchg InstallESD.dmg

was meant to be the 3rd command – immediately following


	sudo chflags noschg InstallESD.dmg
20

Boot into single user mode maybe?

You’re on the right track, but you’re still booting from the same system volume.

Instead, I recommend the following:

  1. Boot into recovery,
  2. Select Terminal from the Utilities menu,
  3. Mount your boot drive* (called Macintosh HD, unless you’ve renamed it), then
  4. Switch to the tmp directory. One of these two should work:
    a. cd /System/Volumes/Data/tmp then ls -al to see if the file is there. If not, try:
    a. cd /System/Volumes/Macintosh\ HD/tmp followed by ls -al to see if the file is there.
  5. Once you’re in the correct directly, then rm -r Install\ macOS\ Mojave.app should delete it.

I haven’t tested this, and I’m mostly working from memory, but this should work. Note that you might also have to disable SIP to get this to work. If you do, remember to re-enable it when you’re done.

3 Likes
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