Impossible to delete a rebel file, have tried everything and macOS doesn't let me

[Thor774]

EDIT 2023-01-24-02:46: Trash is now empty but please read ahead. I decided to let the thread as originally posted because the problem still remains and the errors are the same when trying to delete this rebel file.

---

Some weeks ago I downloaded macOS Mojave from the App Store to install on a VMware virtual machine. When the install process finished I moved the "Install macOS Mojave.app" file from Applicatons to the Trash. After some days when trying to empty the trash I was presented with the following surprise: The operation can't be completed because the item "Install macOS Mojave.app" is in use.

I then tried to delete it directly from inside the Trash itself and got this:

I checked the file info and the file isn't locked (that box isn't checked and it's grayed out). I even added my user to the permissions box with write/read but macOS still didn't let me delete the file from the Trash.

I then launched Terminal and tried sudo rm -rf /Users/XXXX/.Trash/Install\ macOS\ Mojave.app and got:

rm: /Users/XXXX/.Trash/Install macOS Mojave.app/Contents/SharedSupport/InstallESD.dmg: Operation not permitted
rm: /Users/XXXX/.Trash/Install macOS Mojave.app/Contents/SharedSupport: Directory not empty
rm: /Users/XXXX/.Trash/Install macOS Mojave.app/Contents: Directory not empty
rm: /Users/XXXX/.Trash/Install macOS Mojave.app: Directory not empty

Under Terminal I tried lsof /Users/XXXX/.Trash/Install\ macOS\ Mojave.app and nothing was shown

The item is located in the internal SSD's Trash.

I have rebooted and it didn't help.

Neither Activity Monitor nor Force Quit show anything related to the file.

I have tried restarting into Safe Mode to empty the Trash from there but am getting some wierd loop at logon that doesn't let me launch macOS in this mode (no problems lauching it in normal mode).

EDIT 2023-01-24-02:46: After updating to macOS 13.2 I can now boot into Safe mode without issues. I tried to delete the file from there and received the same errors as in normal mode.

While in safe mode I dragged and dropped the file from the Trash into a folder I created on the desktop. Now the file resides in this new folder and the Trash is empty, but I still cannot delete the file using sudo rm -rf from Terminal.

I then tried to move this folder containing the rebel file to an external USB stick and got the message that the item was copied but couldn't be moved.

This file is getting me crazy. It is almost 6GB of wasted space and I don't understand why macOS doesn't let me delete the damn thing.

I am now empty of options.

Ideas are greatly appreciated thank you.

Using macOS Ventura 13.2 atm here.

 

[Amazon Rainforest]

It looks like you have tried everything. There is one additional thing I can suggest--no idea whether it will matter. MacOS uses something called an ACL, Access Control List. The ACL supersedes the standard UNIX mode bits. I once had a problem with a directory I dragged from a Time Machine backup into my home directory. I had full r/w/x permission and ownership but the directory was still read-only. I took my computer to see one of Apple's geniuses and they were clueless. I spent a week on the problem before I stumbled on the solution. I removed the ACL entry for the directory and afterwards, I had full access. I don't know how you can access the ACL using Finder or a shell command but I used Path Finder. Select the object (file, folder, etc.) then get Info (CMD-I). There is a button which shows the ACL for that object. I found the ACL entry and deleted it. Here is a sample Info pane with the button:

 

[Amazon Rainforest]

Another thing comes to mind.... Since this thing is defined as an app, it's really a folder. Go into the app/folder (using Show Package Contents) and manually delete all the files you can. As an alternative, you can try using "rm -rf" but make sure you first "cd" into the folder. You don't want to wipe out your other important files. Then reboot and see if you can delete the remaining files.

I know you tried doing this and some of the files failed to delete. Make sure you delete as many of the inside files as you can. There should be some way to tell the "rm -rf" command to ignore errors and keep deleting. Then take a close look at the files that remain, i.e., permissions and ownership and ACL.

 

[MrCheeto]

Interestingly I just had a very very similar issue in Leopard. Yes: 10.5 Leopard! Yes: just this past weekend.

I moved the App from the .trash to a folder on my desktop. Now here is an important distinction that I cannot explain but I can say it worked.

Rather than simply do “sudo”, I changed user to super user.

In terminal:

Type: “sudo su” and return.
Now “rm -rf” the folder that you made on the desktop to contain the app you are trying to delete.

Do not add “sudo” to the “rm” command as you are already switched to super user.

I don’t know why this worked when simply adding “sudo” to my “rm” didn’t work but it did and I don’t care.

 

[Thor774]

It looks like you have tried everything. There is one additional thing I can suggest--no idea whether it will matter. MacOS uses something called an ACL, Access Control List. The ACL supersedes the standard UNIX mode bits. I once had a problem with a directory I dragged from a Time Machine backup into my home directory. I had full r/w/x permission and ownership but the directory was still read-only. I took my computer to see one of Apple's geniuses and they were clueless. I spent a week on the problem before I stumbled on the solution. I removed the ACL entry for the directory and afterwards, I had full access. I don't know how you can access the ACL using Finder or a shell command but I used Path Finder. Select the object (file, folder, etc.) then get Info (CMD-I). There is a button which shows the ACL for that object. I found the ACL entry and deleted it. Here is a sample Info pane with the button:

View attachment 2147143

Thank you. I downloaded Path Finder and tried to change the permissions and the ACL but wasn't able to change any of them, after inputting the password I got a message that the operation was denied. Tried to do this for the only file inside "Install macOS Mojave.app" (showing package contents) InstallESD.dmg and the same happened.

 

[Thor774]

Interestingly I just had a very very similar issue in Leopard. Yes: 10.5 Leopard! Yes: just this past weekend.

I moved the App from the .trash to a folder on my desktop. Now here is an important distinction that I cannot explain but I can say it worked.

Rather than simply do “sudo”, I changed user to super user.

In terminal:

Type: “sudo su” and return.
Now “rm -rf” the folder that you made on the desktop to contain the app you are trying to delete.

Do not add “sudo” to the “rm” command as you are already switched to super user.

I don’t know why this worked when simply adding “sudo” to my “rm” didn’t work but it did and I don’t care.

Thanks. I have now tried this and it didn't work.

 

[Nermal]

Please run "diskutil list" and post the output here.

 

[Thor774]

Please run "diskutil list" and post the output here.

Here it is, thank you:

/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *251.0 GB   disk0
   1:                        EFI EFI                     314.6 MB   disk0s1
   2:                 Apple_APFS Container disk2         250.7 GB   disk0s2

/dev/disk1 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *1.0 TB     disk1
   1:                        EFI EFI                     314.6 MB   disk1s1
   2:                 Apple_APFS Container disk3         999.9 GB   disk1s2

/dev/disk2 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +250.7 GB   disk2
                                 Physical Store disk0s2
   1:                APFS Volume Macintosh HD - Data     130.4 GB   disk2s1
   2:                APFS Volume Preboot                 2.1 GB     disk2s2
   3:                APFS Volume Recovery                2.3 GB     disk2s3
   4:                APFS Volume Macintosh HD            8.9 GB     disk2s4
   5:              APFS Snapshot com.apple.os.update-... 8.9 GB     disk2s4s1
   6:                APFS Volume VM                      20.5 KB    disk2s5

/dev/disk3 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +999.9 GB   disk3
                                 Physical Store disk1s2
   1:                APFS Volume DATA MAC-1TB X5         733.4 GB   disk3s1

/dev/disk4 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *4.0 TB     disk4
   1:                        EFI EFI                     314.6 MB   disk4s1
   2:          Apple_CoreStorage STORAGE MAC-4TB BLK     4.0 TB     disk4s2
   3:                 Apple_Boot Boot OS X               134.2 MB   disk4s3

/dev/disk5 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *5.0 TB     disk5
   1:                        EFI EFI                     209.7 MB   disk5s1
   2:                 Apple_APFS Container disk6         5.0 TB     disk5s2

/dev/disk6 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +5.0 TB     disk6
                                 Physical Store disk5s2
   1:                APFS Volume TM                      860.0 GB   disk6s2

/dev/disk7 (external, virtual):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                  Apple_HFS STORAGE MAC-4TB BLK     +4.0 TB     disk7
                                 Logical Volume on disk4s2
                                 01E2743D-852D-49E7-A400-D3CECDF9078D
                                 Unlocked Encrypted

 

[Nermal]

So much for that theory. I suspected, since the problematic file is a .dmg, that something was "silently" keeping it mounted. It seems not.

 

[anshuvorty]

At this point, just erase the hard drive and start over.

 

[Slartibart]

What happens when you “put it back”?

after that open a terminal, locate the file and remove it.

 

[MrCheeto]

Can you rename the file? Repair permissions in disk utility? If you can rename then do so and then restart.

Did you successfully switch to su in terminal? Did you place the file inside of a folder and rm the folder rather than the file directly?

According to my terminal history, I created a folder then did “sudo mv” to place the offender inside that folder then carried out the “rm”.

One other thing I notice is that the temporary folder to contain the turd was one level above its original directory. So if it is in Library or Desktop, place it and the containing temporary folder in your Home folder or just for the hell of it place it at the top of your volume.

If all else fails…single user mode?

 

[pipo2]

Had something similar in December with Ventura and resolved it. In my case a SIP issue.
Form my notes:

Get rid of "macOS Install Data"
Turn SIP off:
Reboot into Recovery (on M1 keep on/off button pressed while booting),
select terminal from the menu bar, type ‘csrutil disable’ and hit cr key.
Reboot as usual, delete "macOS Install Data" folder.
Turn SIP on:
Reboot back into recovery mode, access terminal again type ‘csrutil enable’ and hit cr key.
Reboot as usual.

 

[Thor774]

What happens when you “put it back”?

View attachment 2147208

after that open a terminal, locate the file and remove it.

File isn't any longer in the trash, I moved it from it into a folder on the Desktop. Cannot delete it from there either

 

[ajf.350d]

Is it possible it’s still being referenced in VMWare?
Maybe a boot device or similar?

 

[Thor774]

Can you rename the file? Repair permissions in disk utility? If you can rename then do so and then restart.

Just renamed the file now from Finder and macOS let me do it. Ran first aid on the volume and on all the APFS containers over it. All the operations gave the result 0. No errors were found. I don't see an option to choose to repair permissions in disk utyl as before in OSX, but I guess first aid does the same.

Did you successfully switch to su in terminal? Did you place the file inside of a folder and rm the folder rather than the file directly?

Yes & yes.

One other thing I notice is that the temporary folder to contain the turd was one level above its original directory. So if it is in Library or Desktop, place it and the containing temporary folder in your Home folder or just for the hell of it place it at the top of your volume.

The offending file was placed in a folder under a folder residing in the Desktop. I moved the folder to directly under my home folder and still can't rm -rf the folder.

If all else fails…single user mode?

Haven't tried single user mode. Will do that and try the rm -rf from there, then I will report back

Thank you.

 

[Thor774]

Had something similar in December with Ventura and resolved it. In my case a SIP issue.
Form my notes:

Get rid of "macOS Install Data"
Turn SIP off:
Reboot into Recovery (on M1 keep on/off button pressed while booting),
select terminal from the menu bar, type ‘csrutil disable’ and hit cr key.
Reboot as usual, delete "macOS Install Data" folder.
Turn SIP on:
Reboot back into recovery mode, access terminal again type ‘csrutil enable’ and hit cr key.
Reboot as usual.

Have read something similar in the Apple Support communities. I will also give this a try and will post back. Thank your for the suggestion.

EDIT: I have a silly question, when you say delete "macOS Install Data" folder, you mean the folder where the "Install macOS Mojave.app" is located? In my case it is at the moment placed in my home folder under A/B/Install macOS Mojave.app.

 

[Thor774]

Is it possible it’s still being referenced in VMWare?
Maybe a boot device or similar?

I have tried searching inside VMware and cannot find any reference to the macOS Mojave installer there. The VM where I installed it isn't even present in the system anymore, I deleted it weeks ago.
I still think it was strange to find these lines when I ran diskutil list, but I don't know if they have something to do with the issue:
/dev/disk2 (synthesized):
#: TYPE NAME SIZE IDENTIFIER
0: APFS Container Scheme - +250.7 GB disk2
Physical Store disk0s2
1: APFS Volume Macintosh HD - Data 130.4 GB disk2s1
2: APFS Volume Preboot 2.1 GB disk2s2
3: APFS Volume Recovery 2.3 GB disk2s3
4: APFS Volume Macintosh HD 8.9 GB disk2s4
5: APFS Snapshot com.apple.os.update-... 8.9 GB disk2s4s1
6: APFS Volume VM 20.5 KB disk2s5

 

[Thor774]

Had something similar in December with Ventura and resolved it. In my case a SIP issue.
Form my notes:

Get rid of "macOS Install Data"
Turn SIP off:
Reboot into Recovery (on M1 keep on/off button pressed while booting),
select terminal from the menu bar, type ‘csrutil disable’ and hit cr key.
Reboot as usual, delete "macOS Install Data" folder.
Turn SIP on:
Reboot back into recovery mode, access terminal again type ‘csrutil enable’ and hit cr key.
Reboot as usual.

This did it!!!
Thank you so much man. I wish I could invite you a beer right now ❤️. This had been driving me nuts for weeks.
This community never stops to amaze me. There is so much knowledge and willingness to help each other here.
When I restarted after disabling SIP I entered terminal, enabled super user with "sudo su" as suggested by @MrCheeto and then rm -rf the offending file. I was so happy when the operation was finally successful. Then restarted and re-enabled SIP from macOS Recovery.
I still think this issue was bizarre. I had never experienced anything like it in all my 20 years of experience with macOS/OSX.

 

[MrCheeto]

It is strange that even is Leopard I just had a similar issue. I guess SIP was just another roadblock in your case. Glad it's resolved.

 

[Thor774]

At this point, just erase the hard drive and start over.

I was really contemplating this possibility. I would've hated to have to install and configure everything again from scratch. I have invested lots of time fine-tuning this macOS installation and all the apps the way I like it for several months.
I was thinking of restoring a Time Machine backup (excluding the folder containing the offending file from the backup) after an installation from scratch, but I have never needed to use Time Machine this way before.
How well does it work? You need to run a restore with migration assistant right after the reinstallation I supposed. Would you be able to have everything configured as it is today with all the system options, app licenses, and apps installed as they are now?

Again, thank you for the answer.