NSCocoaErrorDomain 513

I'm fighting with the following error NSCocoaErrorDomain 513 reported by a very small number of users (~ 0.01%):


Unable to create directory at path /var/mobile/Containers/Data/Application/EBE2C5D8-5AEC-4D62-9393-B19CAD598FE5/Documents/documents/FF2F88FB-2C07-4FA3-988E-58AD5C21F659/9A02F8A0-74EB-4ED6-81B6-4F40653856D3. Error: Error Domain=NSCocoaErrorDomain Code=513 "You don’t have permission to save the file “9A02F8A0-74EB-4ED6-81B6-4F40653856D3” in the folder “FF2F88FB-2C07-4FA3-988E-58AD5C21F659”." UserInfo={ NSFilePath=/var/mobile/Containers/Data/Application/EBE2C5D8-5AEC-4D62-9393-B19CAD598FE5/Documents/documents/FF2F88FB-2C07-4FA3-988E-58AD5C21F659/9A02F8A0-74EB-4ED6-81B6-4F40653856D3, NSUnderlyingError=0x15e09de00 { Error Domain=NSPOSIXErrorDomain Code=13 "Permission denied" } }


This error means that the directory cannot be created because of a permission error. That's where I'm lost as the only reason I can see would be if I'm creating a file outside of my app's sandbox.


The code generating this error:


NSArray* paths = NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES); NSString* documentsDirectory = [paths objectAtIndex:0]; NSString *directory = [documentsDirectory stringByAppendingPathComponent:documentsPathAndUUIDs]; NSError *error = nil; if (![[NSFileManager defaultManager] createDirectoryAtPath:directory withIntermediateDirectories:YES attributes:nil error:&error]) { NSError(@"Unable to create directory at path %@. Error: %@", directory, error); }


A couple things worth noting:

  • This path isn't saved, it's regenerated every time, so it's not as if the app container had changed between installs;
  • The users seem to have available disk space;
  • This affects at least iOS 9 (I don't have enough reports to know if it also affects iOS 10)


Would anyone have a hint of why this could happen?

Replies

I'm fighting with the following error NSCocoaErrorDomain 513 reported by a very small number of users (~ 0.01%):

Do the users who have this problem always have the problem? Or can they do something to avoid it (restart the device, delete and reinstall your app, and so on)?

Do the users who have this problem have anything in common? All in the same country? Or using the same language? Or locale? All using a particular type of device? Or using a jailbroken device?

Share and Enjoy —
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Hello,


So far I haven't been able to find a pattern and I'm investigating with more logs.


I know the following information about the people who have reported the issue, without being able to draw statistical conclusions:

- people who have this problem seem to always have it

- on non-jailbroken devices

- at least for English locales

- on devices which have a large amount of free disk space

- at least on iPhone 6, iPhone 6S+

- at least on iOS 9.3.5


Restarting the phone doesn't help.

We cannot ask them to remove and reinstall the app as they would lose their data.


Do you have any hint in what direction I could search for this issue?


Thanks,

Bruno

Do you have any hint in what direction I could search for this issue?

You could create a build that, when it gets this error, manually does the equivalent of

-createDirectoryAtPath:***
using low-level BSD APIs to see which call is actually flagging the error, then pass that build to a few willing victims^H^H^H^H^H^H^H testers.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

OK - I will try that but it's hard to get custom builds in the hands of John Doe, especially when they stop answering the support emails 🙂


Could it be related to data protection in any way? I don't think it should be the case as the application is in the foreground when this error happens (this error happens on a user action).

Could it be related to data protection in any way?

I wouldn’t have thought so; data protection problems typically involve the contents of files, and

-createDirectoryAtPath:***
is manipulating file system metadata.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

We have been unable to find a user able to install a test build so far.


I can confirm this issue is also affecting iOS 10 and it could happen after updating the app. Could it be that the app sandbox directory would be cached in some very rare instance resulting in valid paths generated in the app?


Additionally, I know that the app is able to write to Core Data (eg. some metadata is registered, but the associated data files cannot be created because of this error).


I have also evidence that files fail to be created as the following code fails for these users according to the logs:


if (![UIImageJPEGRepresentation(image, 0.75) writeToFile:self.filePath options:NSDataWritingAtomic error:&error]) {

DDLogError(@"Error while persisting cached image: %@", error);

}


I have submitted a radar: 28827236.

Hello,


This issue is still happening and we are unable to find a willing tester.


Is there any chance this can be due to a file system corruption?


Thanks,

Bruno

I had the same issue, and the problem was that in my "Create Directory" statement I was not using the variable from appendstring, but just the the folder I wanted to create. Here is the method I am now using:


-(BOOL)doCheckRptFolder:(id)sender inFolder:(NSString *)inFolder

{

BOOL folderFound = NO;

NSString *folderPath = nil;


NSFileManager *fileManager = [[NSFileManager alloc] init];

fileManager.delegate = self;


NSArray *paths = NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES);

folderPath = [[paths objectAtIndex:0] stringByAppendingPathComponent:inFolder];

if ([fileManager fileExistsAtPath:folderPath])

{

folderFound = YES;

return folderFound;

}

else

{

/

NSError *error = nil;

if (![fileManager createDirectoryAtPath:folderPath withIntermediateDirectories:YES attributes:nil error:&error])

{

NSLog(@"Create directory error: %@", [error userInfo]);

folderFound = NO;

return folderFound;

}

}

return folderFound;

}

I was having similar issues. The root cause of it was due to Apple's 'data protection class'. It's defaulted to NSFileProtectionCompleteUntilFirstUserAuthentication

I was seeing this error for the longest time until I accidentally reproduced it. I only ran into this issue:
  • after a reboot

  • did NOT unlock device.

  • app made some network call that needed to write into some directory

Failed and got a 513 error.

The fix is simple if you like the tradeoff:

Code Block
try data.write(to: tmpFileURL, options: [.noFileProtection])


Though that would allow the file to be accessed while locked and during boot time.


I suppose if you've set the data protection class to NSFileProtectionCompleteUnlessOpen and the user locks their device after an action and that action of yours takes too much time then you'll get this error again.


The root cause of it was due to Apple's 'data protection class'.

Yeah, that’d do it.

did NOT unlock device

How did you get your code running prior to a first unlock? We generally try to avoid running third-party apps in that state, although there are some cases where we do (the exact list of scenarios has varied over time and I’m not up to speed on what it currently is).

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@apple.com"