NSCocoaErrorDomain 513

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"

I am having the same error trying to update to Sonoma on unsupported iMac 27” 5K Late 2014 model.

I'm also getting a 513 error no matter what I code. I even tried using chatGTP and Harmony and Copilot generated code. All to no avail.

Here's the copilot code (as it seemed better to me)

func copilotCreateTheNewDirectory(in downloadsURL: URL)
    {
        guard downloadsURL.startAccessingSecurityScopedResource() else {
            let errorMessage = "Failed to access the selected location"
            showError = true
            return
        }
        
        defer {
            downloadsURL.stopAccessingSecurityScopedResource()
        }
        let newDir = "myShinyNewDir"
        let fileManager = FileManager.default
        let newDirectoryURL = downloadsURL.appendingPathComponent(newDir)
        
        do {
            try fileManager.createDirectory(
                at: newDirectoryURL,
                withIntermediateDirectories: false,
                attributes: nil
            )
        } catch {
            let errorMessage = "Failed to create directory: \(error.localizedDescription)"
            showError = true
        }
        
    }
}

I tried using Swift5 instead of Swift6 and that failed, too. I tried in Documents and Downloads locations - all failed. Here are my App Sandbox settings:

Xcode: Version 16.0 (16A242d) MacOS: Sequoa 15.0.1

Same problem in Sequoa 15.1.

But, when I copy the same code into another project it works. There must be some project/profile/info.plist setting that makes all the difference 🙁

Solved. I'm not sure where or how Sandbox is selected as a capability. I'd much rather it wasn't. But my problem was that User Selected File (see screenshot above) was specified as read/write in the release tab, but none in the debug tab.