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.
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).
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.
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.