I downloaded Mojave and Catalina installers, for later use and copied them to an external drive.
I can’t delete the installers from my boot drive.
Tried so far:
Boot in Safe Mode
Disk First Aid (all comes back with OK)
Change permissions to “Read & Write”
Use Terminal function rm -R /Users/mHm/.Trash/Install\ macOS\ Mojave.app
The latter comes back with:
override rw-r–r-- root/wheel restricted for /Users/mhm/.Trash/Install macOS Mojave.app/Contents/SharedSupport/InstallESD.dmg?
(I press RETURN)
override rwxr-xr-x root/wheel for /Users/mhm/.Trash/Install macOS Mojave.app/Contents/SharedSupport?
override rwxr-xr-x root/wheel for /Users/mhm/.Trash/Install macOS Mojave.app/Contents?
override rwxr-xr-x root/wheel for /Users/mhm/.Trash/Install macOS Mojave.app?
If I, instead of pressing RETURN, enter “YES”, I get this:
override rw-r--r-- root/wheel restricted for /Users/mhm/.Trash/Install macOS Mojave.app/Contents/SharedSupport/InstallESD.dmg? YES
rm: /Users/mhm/.Trash/Install macOS Mojave.app/Contents/SharedSupport/InstallESD.dmg: Operation not permitted
override rwxr-xr-x root/wheel for /Users/mhm/.Trash/Install macOS Mojave.app/Contents/SharedSupport? YES
rm: /Users/mhm/.Trash/Install macOS Mojave.app/Contents/SharedSupport: Permission denied
override rwxr-xr-x root/wheel for /Users/mhm/.Trash/Install macOS Mojave.app/Contents? YES
rm: /Users/mhm/.Trash/Install macOS Mojave.app/Contents: Permission denied
override rwxr-xr-x root/wheel for /Users/mhm/.Trash/Install macOS Mojave.app? YES
rm: /Users/mhm/.Trash/Install macOS Mojave.app: Directory not empty
Happened to me all the time until I remember to reboot into Recovery mode and disable SIP:
Click the Apple symbol in the Menu bar.
Hold down Command-R to reboot into Recovery Mode.
Type csrutil disable.
Press Return or Enter on your keyboard.
Click the Apple symbol in the Menu bar.
If you later want to start using SIP once again (and you really should), then follow these steps again, except this time you’ll enter csrutil enable in the Terminal instead.
Another option I’ve found to work…even for perms issues or file in use issues…although occasionally the latter requires a reboot first.
sudo rm -R followed by a space
Open Trash and drag everything into the Terminal window
Return, enter password and it all goes away.
Occasionally some stuff doesn’t get deleted…if so drag it into a folder out of the trash, give everyone group full R/W perms and propagate through the folder then drag the folder into the trash and repeat the above.
This presumes you’ve given your normal everyday non admin account sudoers perms by editing the sudoers file…if not add a su admin account name and enter that password as the first terminal step.
During my various attempt (including @neil1 's suggestion, which I had already tried) I saw messages that Install macOS Mojave.app is a directory, this is true, but why was I not allowed to delete it? And why does SIP block such deletions?
I did use sudo, but kept the copy of my terminal session short. My understanding is that you can run sudo once to gain the super-user privileges, then run a series of commands with said privileges. Correct me if I’m wrong.
Since I solved the original problem I had to download further installers, I could delete them afterwards without problem. I did re-enable SIP.
All of this happened on BigSur, maybe Apple finally fixed something in Monterey. I have also done similar tasks before (in BigSur) and never saw this problem before.
Usually, you use sudo as a prefix to each command in a series. You are asked for your password once and it is remembered and you don’t need to enter it again for some period (something like ten minutes).
sudo ls -l
sudo rm -f foo
sudo rm -f bar
(Note: To use sudo, you must be an admin user, not a standard user. (Or you need to modify /etc/sudoers, which I don’t recommend. If you do modify it it you should read about it first and always modify it using the sudo visudo command – after reading about that!)
One issue with visudo is that the file gets restored to default with a lot of updates…last time I found a link on creating a second file that gets read as well and does not get restored. Can’t remember the details but will look and post them if I can find it…I know I saved either the link or an email or pdf or something…but email search on iPad which is where I think I kept it doesn’t work worth a darn. Modifying sudoers or adding the other file is far more secure overall than unningnan admin daily driver account…and while su to get to the admin account works it’s more work IMO.
More specifically, editing the main /etc/sudoers file (through any means) may result in updates clobbering your changes.
But you can use visudo to edit any other file, and get its error checking capabilities on your other files:
BTW, when Apple discovers a conflict between their default config files and your customized ones, they always create a “Relocated Items” folder (in the /Users/Shared folder) as a part of the upgrade. You should see an alias to this on your desktop. Within it, you should find everything you need to manually resolve the conflicts.
If Apple replaced a file, your original one should be backed up in there
If Apple didn’t replace the file, their default version should be in there
In either case, I recommend comparing the live version against the one in Relocated Items and make any changes (to the live file) that you believe must be made.
I do this whenever an update creates a Relocated Items folder (and then delete that folder after resolving the differences). It usually only takes a few minutes (on my system, it always flags the changes I made to the Apache web server configuration).
I’ve noticed command line stuff that worked just fine in earlier versions of Mac OS won’t work in Ventura. The “.Trashes” directory seems to be protected specially, so that “sudo” commands that used to work no longer work (including ‘ls’ and ‘rm’.) I find this -incredibly frustrating-, it’s taking away an advantage of Mac OS X (and successors) to use my Unix knowledge to do or fix things in the file system that weren’t doable, or were hard to do, from the Finder.
First, make sure the Shared Support isn’t mounted: look in Disk Utility, if it is in the side bar, eject it from there.
This is due to a bug in the Installer app. If you launch it, it invisibly mounts the shared support volume, but doesn’t dismount it when you quit. You hit the same bug when you try to create installer media. In either case, one symptom is that you can not delete the installer.
Other than that, if it is permissions issue for Trash, I’d try restoring the installer back (Trash > right-click on item > Put Back), and then delete it without putting in Trash, by Finder > File > (option) Delete Immediately.