Skip to main content
replaced http://superuser.com/ with https://superuser.com/
Source Link

From debugging a different problem (which showed up as deny file-read-data in the Console, see the other answer), it seems that sandboxd prevents sandboxed applications from reading quarantined data, so I think you'd need to remove the attribute with:

xattr -d com.apple.quarantine /path/to/file

(see for instance http://superuser.com/a/28394/46794https://superuser.com/a/28394/46794). You'd need to prefix the command with sudo if the file didn't belong to your user, but according to your info it does.

The other user reported that using a non-sandboxed application fixed the problem, and this would confirm that sandboxing is at fault.

An aside: When ls reports extended attributes with @ next to the permission field, you don't need ls -le file, but instead ls -l@ file.

From debugging a different problem (which showed up as deny file-read-data in the Console, see the other answer), it seems that sandboxd prevents sandboxed applications from reading quarantined data, so I think you'd need to remove the attribute with:

xattr -d com.apple.quarantine /path/to/file

(see for instance http://superuser.com/a/28394/46794). You'd need to prefix the command with sudo if the file didn't belong to your user, but according to your info it does.

The other user reported that using a non-sandboxed application fixed the problem, and this would confirm that sandboxing is at fault.

An aside: When ls reports extended attributes with @ next to the permission field, you don't need ls -le file, but instead ls -l@ file.

From debugging a different problem (which showed up as deny file-read-data in the Console, see the other answer), it seems that sandboxd prevents sandboxed applications from reading quarantined data, so I think you'd need to remove the attribute with:

xattr -d com.apple.quarantine /path/to/file

(see for instance https://superuser.com/a/28394/46794). You'd need to prefix the command with sudo if the file didn't belong to your user, but according to your info it does.

The other user reported that using a non-sandboxed application fixed the problem, and this would confirm that sandboxing is at fault.

An aside: When ls reports extended attributes with @ next to the permission field, you don't need ls -le file, but instead ls -l@ file.

Source Link
Blaisorblade
  • 676
  • 1
  • 6
  • 19

From debugging a different problem (which showed up as deny file-read-data in the Console, see the other answer), it seems that sandboxd prevents sandboxed applications from reading quarantined data, so I think you'd need to remove the attribute with:

xattr -d com.apple.quarantine /path/to/file

(see for instance http://superuser.com/a/28394/46794). You'd need to prefix the command with sudo if the file didn't belong to your user, but according to your info it does.

The other user reported that using a non-sandboxed application fixed the problem, and this would confirm that sandboxing is at fault.

An aside: When ls reports extended attributes with @ next to the permission field, you don't need ls -le file, but instead ls -l@ file.