Q: .MobileBackups.trash DELETION

sudo rm -rf /path/to/file

Be careful with this command.

For the record, you have been given irresponsible, dangerous, and incompetent advice in this thread by a habitual troublemaker. Never use the shell as a substitute for the Trash.

You're welcome. Just ignore it.

There was no other way to delete the files.

Yes there was, and if you keep taking stupid advice from people who don't know anything about computers, you're going to lose your data. Good luck.

I had the same issue with the CrashPlan.app folder located within the /.MobileBackups.trash after turning off local backups. I was not permitted to delete it. "rm -rf" on this directory did not work for me.

I had two problems because of this. My system log was full of errors regarding failure to delete the /.MobileBackups.trash directory. So if the operating system wanted to delete it and couldn't I figured something was wrong.

For a very long time there was no evidence of this problem except in the logs. Starting today it caused the icon in the menu bar to report failed time machine backups. The logs showed that the backup was successful but an immediate attempt to delete that trash file failed.

These two problems motivated me to take action.

I ran "ls -lO" and saw that the CrashPlan.app folder had the "schg" flag set. This sets the directory to "system immutable". Running "chflags noschg CrashPlan.app" removed this flag. I could then remove the folder with "rm -rf". I decided it was safe to remove this single folder since it related to an application specific file. Since the root level file "/.MobileBackups.trash" was a system directory I decided to leave it alone. I hoped that subsequent attempts by the OS would succeed.

I uninstalled CrashPlan and verified it was deleted from the Applications folder. I then triggered a time machine backup. The CrashPlan.app folder was reintroduced to the .MobileBackups folder. I got mad. I then decide to delete the trash folder. For me it's safe since I maintain two full clones of the boot volume on external drives.

After this the logs and time machine menu bar icon stopped showing the error.

Be very careful with the "rm -rf" command. It's so dangerous since you could delete a ton of stuff that could break your system. Make sure you understand the command.

As an aside, Linc Davis' comments were astonishing. They made me very uncomfortable and a bit afraid to post my experiences. I hope he doesn't respond to this post.

Put the following code in AppleScript Editor:

set cplocation to choose file with prompt "Choose the CrashPlan application you cannot delete"

try

  do shell script "chflags nouchg \"" & POSIX path of cplocation & "\"" with administrator privileges

  do shell script "chflags noschg \"" & POSIX path of cplocation & "\"" with administrator privileges

on error errmsg

  display alert "ERROR!" message errmsg

  tell me to quit

end try

          display alert "Complete!" message "CrashPlan is now unlocked."

CrashPlan setting the "system immutable" (schg) flag caused the same problem for me too. I found a way to correct the problem which did not require manual deletion or messing around with the original /Applications/CrashPlan.app folder. I simply cleared the schg flag on all the instances of CrashPlan.app under /.Mobilebackups.trash where the schg flag had been set (see recipe below). On the next Time Machine backup, the /.Mobilebackups.trash folder got deleted automatically as it should, with no errors in the console log. No need to rm -rf anything.

To clear the schg flag on all files and folders under /.Mobilebackups.trash, enter the command below in the terminal (exactly as shown). This will work on anything that has the schg flag, not just CrashPlan:

sudo find /.MobileBackups.trash/ -flags +schg -exec chflags noschg {} \;

The "-flags +schg" part finds all files and folders under /.MobileBackups.trash with the schg flag set, while "-exec chflags noschg {} \;" executes the command "chflags noschg" on each of them, which clears the schg flag. This should be safe, since nothing in the .MobileBackups.trash folder should need to have the schg flag, and nothing other than CrashPlan.app did in my case.

The drawback with this approach is that the problem may reappear at some point, but it does not seem to happen very often, so you can repeat the recipe whenever the problem resurfaces. I suspect it happens when CrashPlan autoupdates itself and makes changes to the /Application/CrashPlan.app folder, though I have not had an opportunity to confirm that yet. Unsetting the schg flag on /Applications/CrashPlan.app might be a permanent fix, but could in theory be unsafe, and CrashPlan would probably just reactivate the flag on the next autoupdate anyway.

When I said "Crashplan.app" directory I meant the one that I found under the /.MobileBackups.trash folder. Sorry to mislead you (and maybe everyone else).

Halleluja, korsbakken. I never suspected Crashplan to be responsible, especially after deleting it 2 month ago.... Your command worked perfectly well and avoided rm -rf. Great work. Thx for your suggestion.