Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

Recurring trash emptying issue with this message:Error finding user trash dir: -5000 - Insufficient access privileges for operation

Hi,


I've tried several methods that either don't work or last very long. OnyX will empty the trash if needed but being a long time happy user of Hazel Helper to cleanup old files, etc., and now it cannot put them in the trash. If the trash has items loaded manually most of them will delete when asked while others will not and that's when I used MainMenu Pro app to force or secure delete the trash and if not OnyX would never fail. However, Hazel Helper sadly can't seem to do her job anymore. I see this error in the log every time it tries to move a file: "Error finding user trash dir: -5000 - Insufficient access privileges for operation"



I regularlly run OnyX to clean, purge, run permission repairs etc. Any help or thoughts would be greatly appreciated. 🙂


Any thoughts? This problem seemed to start with Lion and become worse with Mountain Lion. Here's a more detailed log excerpt:

2013-07-09 12:10:42.550 hazelworker[4418] File lasm-1.dmg is a dupe. Purging.

2013-07-09 12:10:42.550 hazelworker[4418] [File Event] File moved: File /Users/mjrobertson/Downloads/lasm-1.dmg is a duplicate. Moving to Trash.

2013-07-09 12:10:42.550 hazelworker[4418] Moving lasm-1.dmg to trash.

2013-07-09 12:10:42.550 hazelworker[4418] Error finding user trash dir: -5000 - Insufficient access privileges for operation

2013-07-09 12:10:42.550 hazelworker[4418] Caught exception while processing lasm-1.dmg: *** -[NSURL initFileURLWithPath:]: nil string parameter

2013-07-09 12:10:42.550 hazelworker[4418] (

0 CoreFoundation 0x00007fff8f887b06 __exceptionPreprocess + 198

1 libobjc.A.dylib 0x00007fff92c7b3f0 objc_exception_throw + 43

2 CoreFoundation 0x00007fff8f8878dc +[NSException raise:format:] + 204

3 Foundation 0x00007fff8e28ce07 -[NSURL(NSURL) initFileURLWithPath:] + 81

4 Foundation 0x00007fff8e28cd07 +[NSURL(NSURL) fileURLWithPath:] + 43

5 NoodleKit 0x000000010deee7aa carbonMoveCopyStatusCallback + 33870

6 NoodleKit 0x000000010dee6076 NoodleDecimalIsPreciseToWithinDecimalPlaces + 25322

7 hazelworker 0x000000010ddd37c5 start + 8373

8 hazelworker 0x000000010ddd3c38 start + 9512

9 hazelworker 0x000000010ddd53ba start + 15530

10 hazelworker 0x000000010ddd6a6c start + 21340

11 hazelworker 0x000000010ddd1744 start + 52

12 ??? 0x0000000000000002 0x0 + 2

)

2013-07-09 12:10:43.135 hazelworker[4418] Warning: predicted fire time is in the past: 2013-06-30 22:56:03 +0000

iMac, OS X Mountain Lion (10.8.4), "11.3 2.93 CI7 16GB Ram OWC/Samsung

Posted on Jul 9, 2013 10:17 AM

Reply
13 replies

Jul 9, 2013 10:47 AM in response to Uncle Mac OSX

I've scanned these numerous tips and they seem to mostly address the probelm of a trash can that won't empty. TrashIt app wasn't helpful and most of those terminal commands are so powerful it's possible you could loose way more than trash items.


Maybe my tags were too vague or incorrectly stating my problem. It's more of a permissions issue I believe. But again thanx for the links!

Jul 9, 2013 11:08 AM in response to Uncle Mac OSX

This post although very interesting doesn't seem to apply to my issue but it may help someone else in the future. 🙂

http://reviews.cnet.com/8301-13727_7-57578706-263/fix-permissions-errors-for-san dboxed-applications-in-os-x/

Fix permissions errors for sandboxed applications in OS X


Sometimes file access errors in OS X may actually be related to a program's sandboxing rather than being a classic file permissions error.

User uploaded file

by Topher Kessler April 10, 2013 2:50 PM PDT


User uploaded file


When using some common sandboxed applications in OS X such as TextEdit, you may run into an issue where the program experiences file access errors for which you may not even receive a notification. For example, if such an error occurs in TextEdit, you may see a warning stating that you do not have permission to access a file you are trying to open, or you may just find yourself unable to save a new or existing file you are currently editing.

In addition, access restrictions in sandboxed applications may result in odd file-saving behaviors in which multiple copies of documents may accumulate on your hard drive, and are noted with a file suffix like ".sb-46c1a916-NBYxPj" (the "sb" indicates "sandbox," and the rest is an identifier for the application and system to handle the document through its sandboxing routines).

User uploaded file

Sandboxing errors may clutter the system console if a problem exists with the sandboxing daemon (click for larger view).

(Credit: Screenshot by Topher Kessler/CNET)

Sandboxing of programs is supposed to increase security and stability by isolating the program from access to all system resources and only allows access via elected permissions the developer adds to its program. This interface is an additional layer of complexity the program must pass through in order to perform its tasks like opening, saving, and accessing system resources.

Unfortunately at times Apple's sandboxing rules run into a bug or two, which may restrict a program even if it should have proper access to a specific resource. When this happens, such errors as those described with TextEdit may occur.

Sometimes sandboxing errors can be difficult to identify because they can mimic behaviors that indicate filesystem corruption or systemwide access permissions errors. Therefore, if you find yourself suddenly unable to save or open a document, or otherwise use a program's normal functions, then before attempting filesystem checks and global system permission repair routines, first try troubleshooting for sandboxing errors.

Open the Console program and search for "sandboxd," which is the daemon process (or "server") in the system that manages the sandboxing routines that programs like TextEdit interface with. With this search, you should be able to see a reference to the affected program along with any associated messages, such as the sandbox daemon denying access to a requested file. With Console open, you can try to use your application again and see if similar messages show up.

You can also try quitting and relaunching the application, and if that fails, restarting the computer. If all that's needed to clear the problem is reinitializing the sandboxing background services, then these steps should restore proper access to the resources that the program needs. Keep in mind that sandboxing snafus may prevent a program from auto-saving documents, so quitting it may result in losing unsaved changes to your current work. Therefore, preserve your work by copying and pasting it to another program (preferably a non-sandboxed one) before quitting.

User uploaded file

The program's container will be in the user's library folder, and can be removed so the system will recreate it when the program is next launched.

(Credit: Screenshot by Topher Kessler/CNET)

Lastly, there's the possibility of faults in the program's sandbox container, which is a mirrored structure of your user account that is presented to the program. It is through this container that the program accesses your account's folder hierarchy, so if there is a problem with the container, then even if your account's permissions setup is perfectly fine, the program may report access errors, even after restarting and relaunching the program.

In this case, you will need to clear the program's container so it can be rebuilt from scratch, which can be done by selecting Library from the Go menu in the Finder (hold the Option key if the Library is missing), and then opening the Containers folder. In here you will see each sandboxed application's container named by its domain (e.g., "com.apple.TextEdit" for TextEdit), so locate the one for your program and move it to the desktop. Then relaunch the program and see if the problems go away.

Do not immediately throw out the program's container, as it may contain preferences, autosaved documents, and other resources that the program was previously using. After your program is working properly, you can explore the old container to retrieve any of these documents before finally discarding it.

Jul 9, 2013 11:57 AM in response to Uncle Mac OSX

First, an extermely dangerous and incorrect shell command has been posted in this thread. Never empty the Trash in the shell under any circumstances. Correct the underlying problem that's keeping you from emptying it, then empty it as usual.


If you're having trouble with third-party utilities, refer to their developers for support, or (preferably) just get rid of them. If you can't empty the Trash in the Finder, what exactly happens? It's not clear from your description.

Jul 9, 2013 12:12 PM in response to Linc Davis

Hi Linc.


Sorry if I wasn't more clear I'm assuming that the trash issue encountered by Hazel Helper, or MainMenu Pro is actually a permissions problem. OnyX, for some reason or other will delete any and all items in the trash. Hazel Helper is a great utility that cleans up behind you any way you like. Old incomplete downloads, duplicate files etc.


Seems that a web search yeilds mostly the same results as if the trash has items in it and is refusing to delete them and that's not always the case. One of the developers of Hazel Helper tried to help back in January and it seemed to work for a few months then it became more and more difficult to empty the trash when it was populated with items. He believes it a permissions issue and I was giving this forum a try to reslve the problem if possible. 🙂

Jul 9, 2013 4:01 PM in response to nbar

Perhaps the confusion would be eliminated if the thread was 100% deleted. The 3rd party app cannot do it's job but it isn't the fault of the code of Hazel Helper, there's something wrong in the permissions preventing it and sometimes other 3rd party apps with the exception of OnyX. When I manually populate the trash I sometimes have diffficulty in empting it so I turned to MainMenu Pro or OnyX then Hazel wouldn't populate the trash and the developer tried but it's not related to 3rd party apps it's in OS X permissions somewhere.



Maybe a moderator can delete this thread and it can be a error message issue only I'm trying to diagnose.

Recurring trash emptying issue with this message:Error finding user trash dir: -5000 - Insufficient access privileges for operation

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple ID.