iOS Core Data + iCloud, error for addPersistentStoreWithType: You don’t have permission to save the file “store” in the folder

🎤 General Discussion iOS
1

I’ve created a Core Data project from scratch, the only change I made is that where the persistent coordinator is adding a store, I’m providing a NSPersistentStoreUbiquitousContentNameKey option:

coordinator.addPersistentStoreWithType(NSSQLiteStoreType, configuration: nil, URL: url, options: [NSPersistentStoreUbiquitousContentNameKey : "coreDataiCloudTestStore"])

and I’m inserting and saving a new managed object at launch.

When at launch there is no iCloud account logged in, no problems. While the app is running, I’m logging into iCloud and going back to the app. I’m getting this error: You don’t have permission to save the file “store” in the folder, operation not permitted:

CoreData: error: -addPersistentStoreWithType:SQLite configuration:PF_DEFAULT_CONFIGURATION_NAME URL:file:///var/mobile/Containers/Data/Application/9032B2BC-BE8B-42C9-A9CC-EF3E01AA6F2B/Documents/SingleViewCoreData.sqlite options:{ NSPersistentStoreUbiquitousContentNameKey = coreDataiCloudTestStore; PFUbiquitySetupSynchronousSideLoadKey = 1; }

… returned error Error Domain=NSCocoaErrorDomain Code=513 “You don’t have permission to save the file “store” in the folder “380E290C-97F9-4DC3-9B3C-43322FCA455D”.” UserInfo={NSFilePath=/var/mobile/Containers/Data/Application/9032B2BC-BE8B-42C9-A9CC-EF3E01AA6F2B/Documents/CoreDataUbiquitySupport/mobile~C5A2ECE3-1AB9-45FA-9C15-037DCCA054DE/coreDataiCloudTestStore/380E290C-97F9-4DC3-9B3C-43322FCA455D/store, NSUnderlyingError=0x1453f430 {Error Domain=NSPOSIXErrorDomain Code=1 “Operation not permitted”}} with userInfo dictionary { NSFilePath = “/var/mobile/Containers/Data/Application/9032B2BC-BE8B-42C9-A9CC-EF3E01AA6F2B/Documents/CoreDataUbiquitySupport/mobile~C5A2ECE3-1AB9-45FA-9C15-037DCCA054DE/coreDataiCloudTestStore/380E290C-97F9-4DC3-9B3C-43322FCA455D/store”; NSUnderlyingError = “Error Domain=NSPOSIXErrorDomain Code=1 "Operation not permitted"”; }

PFUbiquitySwitchboardEntry containerIdentifierChanged:: CoreData: Ubiquity: Error loading new temporary coordinator after account change with options { { NSPersistentStoreUbiquitousContentNameKey = coreDataiCloudTestStore; } } and URL file:///var/mobile/Containers/Data/Application/9032B2BC-BE8B-42C9-A9CC-EF3E01AA6F2B/Documents/SingleViewCoreData.sqlite and error = Error Domain=NSCocoaErrorDomain Code=513 “You don’t have permission to save the file “store” in the folder “380E290C-97F9-4DC3-9B3C-43322FCA455D”.” UserInfo={NSFilePath=/var/mobile/Containers/Data/Application/9032B2BC-BE8B-42C9-A9CC-EF3E01AA6F2B/Documents/CoreDataUbiquitySupport/mobile~C5A2ECE3-1AB9-45FA-9C15-037DCCA054DE/coreDataiCloudTestStore/380E290C-97F9-4DC3-9B3C-43322FCA455D/store, NSUnderlyingError=0x1453f430 {Error Domain=NSPOSIXErrorDomain Code=1 “Operation not permitted”}}

Why is this happening ?

2

Troubleshooting Core Data+iCloud Error
Core Data builds on functionality provided by other parts of Cocoa. When diagnosing a problem with an application that uses Core Data, take care to distinguish between problems that are specific to Core Data and those that stern from an error with another framework or that are architecture-related. Poor performance, for example, may not be a Core Data problem, but instead due to a failure to observe standard Cocoa techniques of memory management or resource conservation. If a user interface does not update properly, this may be due to an error in how you have configured Cocoa bindings.

Object Life Cycle Problems
Merge errors
Problem: You see the error message, “Could not merge changes.”

Cause: Two different managed object contexts tried to change the same data. This is also known as an optimistic locking failure.

Remedy: Either set a merge policy on the context, or manually (programmatically) resolve the failure. You can retrieve the currently committed values for an object using committedValuesForKeys:, and you can use refreshObject:mergeChanges: to refault the object, so that when it is next accessed, its data values are retrieved from its persistent store.

Assigning a managed object to a different store
Problem: You see an exception that looks similar to this example.

[<MyMO 0x3036b0>_assignObject:toPersistentStore:]:
Can’t reassign an object to a different store once it has been saved.
Cause: The object you are trying to assign to a store has already been assigned and saved to a different store.

Remedy: To move an object from one store to another, you must create a new instance, copy the information from the old object, save it to the appropriate store, and then delete the old instance.

Fault cannot be fulfilled
Problem: You see the error message, NSObjectInaccessibleException; “Core Data could not fulfill a fault.”

Cause: The object that Core Data is trying to realize has been deleted from the persistent store.

Remedy: Discard this object by removing all references to it.

Details: This problem can occur in at least two situations:

First situation:

You started with a strong reference to a managed object from another object in your application.

You deleted the managed object through the managed object context.

You saved changes on the object context.

At this point, the deleted object has been turned into a fault. It isn’t destroyed because doing so would violate the rules of memory management.

Core Data will try to realize the faulted managed object but will fail to do so because the object has been deleted from the store. That is, there is no longer an object with the same global ID in the store.

Second situation:

You deleted an object from a managed object context.

The deletion failed to break all relationships from other objects to the deleted object.

You saved changes.

At this point, if you try to fire the fault of a relationship from another object to the deleted object, it may fail, depending on the configuration of the relationship, which affects how the relationship is stored.

The delete rules for relationships affect relationships only from the source object to other objects (including inverses). Without potentially fetching large numbers of objects, possibly without reason, there is no way for Core Data to efficiently clean up the relationships to the object.

Keep in mind that a Core Data object graph is directional. That is, a relationship has a source and a destination. Following a source to a destination does not necessarily mean that there is an inverse relationship. So, in that sense, you need to ensure that you are properly maintaining the object graph across deletes.

Core Data uses inverse relationships to maintain referential integrity within the data model. If no inverse relationship exists and an object is deleted, you will be required to clean up that relationship manually.

In practice, a well-designed object graph does not require much manual post-deletion clean-up. Most object graphs have entry points that in effect act as a root node for navigating the graph, and most insertion and deletion events are rooted at those nodes just like fetches. This means that delete rules take care of most of the work for you. Similarly, because smart groups and other loosely coupled relationships are generally best implemented with fetched properties, various ancillary collections of entry points into the object graph generally do not need to be maintained across deletes, because fetched relationships have no notion of permanence when it comes to objects found through the fetched relationship.

Regards,
Rachel Gomez