9

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?

Lri
  • 105,117
  • Do you open the dame file in TextEdit and WriteRoom at the same time? – mmmmmm Jan 01 '13 at 20:48
  • Can you open terminal.app and tell us the output of ls -lt? – paulgrav Jan 02 '13 at 07:36
  • @Mark Sometimes, but I don't think it starts because of that. I should probably try removing WriteRoom temporarily though. – Lri Jan 02 '13 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 Jan 02 '13 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 Jan 02 '13 at 15:37
  • @paulgrav I hadn't tried it before, but I did that now as well. 10.8.2, but I don't remember if it started on Mountain Lion or Lion. I do have a lot of errors like deny mach-lookup com.apple.ls.boxd and deny mach-lookup com.apple.coresymbolicationd. I haven't worked with files on other volumes. – Lri Jan 02 '13 at 15:40
  • Since it is repeatable, once you're in that state you can use dtruss to see the exact system call that is failing, and then verify whether it should fail or not, based on the file's permissions. Find the pid of textedit from a terminal with ps -ef | grep TextEdit, and use the second number. (the first is your UID).

    Then you can use dtruss -p <pid> to see the system call fail. Then you should be able to tell if the filesystem is correct, and if so, perhaps TextEdit has the wrong perms.

     – Tim B Jan 02 '13 at 15:48
  • Starting up in safe mode might fix the com.apple.ls.boxd errors. I'll try that next and then removing WriteRoom. @TimothyButler Thanks, I didn't know about dtruss. – Lri Jan 02 '13 at 15:59
  • I have a ton of those lsboxd errors in my system.log too. I think they’re mostly harmless. – paulgrav Jan 02 '13 at 20:07

4 Answers4

3

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.

Lri
  • 105,117
0

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

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

Jawa
  • 2,484
mecano
  • 11
  • 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). – Thomas Tempelmann Aug 14 '15 at 20:22
0

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.

Jonathan
  • 1
0

Try repairing the user permissions.

http://www.ernieflores.net/mac-os-x-10-7-lion/repair-user-permissions-in-mac-os-x-lion/

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

paulgrav
  • 553
  • 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 Jan 02 '13 at 18:52
  • Maybe. Repairing user perms couldn’t hurt. – paulgrav Jan 02 '13 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 Jan 02 '13 at 20:09
  • I tried it yesterday, but I'm getting those dialogs again, so it probably didn't help. – Lri Jan 04 '13 at 01:39
  • A permission error leads to reproducible access error. It isn't the case here. – dan Jan 08 '13 at 20:04