About once per day, TextEdit starts showing dialogs like this when I try to open any file:

The document “test.txt” could not be opened. You don’t have permission.

To view or change permissions, select the item in the Finder and choose File > Get Info.

There's usually messages like this in system.log:

9/13/12 10:41:42.952 PM sandboxd[21081]: ([357]) TextEdit(357) deny file-read-data /Users/lauri/Desktop/test.txt
9/13/12 10:41:55.118 PM TextEdit[357]: NSFileVersion tried to tried to add a new generation and failed. Versioned file URL: file://localhost/Users/lauri/Notes/temp.txt, contents URL: file://localhost/Users/lauri/Notes/temp.txt.sb-de6477ff-BhVNrq, error: Error Domain=GSLibraryErrorDomain Code=1 "The operation couldn’t be completed. (GSLibraryErrorDomain error 1.)"
9/13/12 10:41:55.118 PM TextEdit[357]: NSDocument failed to preserve the old version of a document. Here's the error:
Error Domain=GSLibraryErrorDomain Code=1 "The operation couldn’t be completed. (GSLibraryErrorDomain error 1.)"
9/13/12 10:41:55.119 PM TextEdit[357]: <Document: 0x7f971d00a510>: An error occurred while attempting to preserve the backup file at file://localhost/Users/lauri/Notes/temp.txt.sb-de6477ff-BhVNrq: Error Domain=GSLibraryErrorDomain Code=1 "The operation couldn’t be completed. (GSLibraryErrorDomain error 1.)"

I can't open any files until I quit and reopen TextEdit. I also have to delete the backup files (like temp.txt.sb-de6477ff-BhVNrq) manually.

I've had the issue on two different installations. I have tried deleting the sandbox container and repairing permissions from the recovery partition. Does anyone know what's going on?

  • Do you open the dame file in TextEdit and WriteRoom at the same time?
    – mmmmmm
    Commented Jan 1, 2013 at 20:48
  • Can you open terminal.app and tell us the output of ls -lt?
    – paulgrav
    Commented Jan 2, 2013 at 7:36
  • @Mark Sometimes, but I don't think it starts because of that. I should probably try removing WriteRoom temporarily though.
    – Lri
    Commented Jan 2, 2013 at 14:56
  • @paulgrav The issue affects all files, and there's nothing unusual with my permissions (or the permissions of the files I've had open when it has started).
    – Lri
    Commented Jan 2, 2013 at 14:56
  • V strange. Still, probably wouldn’t do any harm to try to repair the user permissions. Might be some extended attributes causing issues. What OS X version are you running? Also, are there any sandbox errors in your logs? Your home directory isn’t hosted on a network mount, is it?
    – paulgrav
    Commented Jan 2, 2013 at 15:37

4 Answers 4


I ended up replacing TextEdit's code signature with an ad-hoc signature:

sudo codesign -f -s - /Applications/TextEdit.app/

It disables sandboxing, so for example the preference files are in ~/Library/Preferences/ instead of the sandbox container.

Edit: The dialogs returned after I reinstalled OS X, and now I'm getting errors like this for codesign -f -s -:

$ sudo codesign -f -s - /Applications/TextEdit.app/
/Applications/TextEdit.app/: replacing existing signature
/Applications/TextEdit.app/: object file format unrecognized, invalid, or unsuitable

I'm using https://github.com/jjgod/TextEditPlus for now. It's based on a version of TextEdit that came with 10.7, but it works with 10.8.2.


Try repairing the user permissions.


In Lion, there is an additional Repair Permissions application utility hidden away. This tool is located inside boot Repair Utilities. Here’s how to access it.

  1. Restart Lion and hold down the Command and R keys.
  2. You will boot into the Repair Utilities screen. On top, in the Menu Bar click the Utilities item then select Terminal.
  3. In the Terminal window, type reset password and hit Return.
  4. The Password reset utility launches, but you’re not going to reset the password. Instead, click on the icon for your Mac’s hard drive at the top. From the drop-down below it, select the user account where you are having issues.
  5. At the bottom of the window, you’ll see an area labeled ‘Reset Home Directory Permissions and ACLs’. Click the Reset button there.

The reset process takes a couple of minutes. When it’s done, quit the programs you’ve opened and restart your Mac. Notice that ‘Spotlight’ starts re-indexing immediately

  • If the user permissions were messed up, wouldn't the application fail every time with the same error and not be able to create any new files?
    – bmike
    Commented Jan 2, 2013 at 18:52
  • Maybe. Repairing user perms couldn’t hurt.
    – paulgrav
    Commented Jan 2, 2013 at 20:05
  • It seems more a comment for something to try but not an actual answer to the question. We'll see based on the OP - I'm sure it's either been tried or can be ruled in/out in a short period of time.
    – bmike
    Commented Jan 2, 2013 at 20:09
  • I tried it yesterday, but I'm getting those dialogs again, so it probably didn't help.
    – Lri
    Commented Jan 4, 2013 at 1:39
  • A permission error leads to reproducible access error. It isn't the case here.
    – dan
    Commented Jan 8, 2013 at 20:04

Possibly related http://forums.macrumors.com/showthread.php?t=798825.

Try deleting the ~/Library/Autosave Informations folder (it will be recreated automatically).

  • I tried that - in fact, if you do that, you have to (also) delete the one in TextEdit's sandbox container (which I found using a search tool such as Find Any File), but that didn't help either (on OSX 10.10.4). Commented Aug 14, 2015 at 20:22

My Solution, type: chmod o+w ~/.CFUserTextEncoding

Here is why:

I had the same problem, found this thread, then figured it out. I am using El Capitan still, but it is probably the same problem in other versions.

The problem is that Apple appears to have added soft links in the directory: ~/Library/Containers/com.apple.TextEdit/Data

Such as: .CFUserTextEncoding@ -> ../../../../.CFUserTextEncoding But, there is no check on the permissions, or even existence, of the places they point to.

I fixed it from the ~/Library/Containers/com.apple.TextEdit/Data directory by changing the permissions on: ../../../../.CFUserTextEncoding:

chmod 644 ../../../../.CFUserTextEncoding

In short, the solution is simply to make sure that the file: ~/.CFUserTextEncoding has the right permissions. Mine did not, but it does now:

In short: You can accomplish this with the command:

chmod o+w ~/.CFUserTextEncoding

And then look at the permissions wth:

ls -la ~/.CFUserTextEncoding

You may need to keep looking at the permissions, as I found it changed on me later. I am not sure why.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .