realm-swift: Error Domain=io.realm Code=2 "Unable to open a realm at path

Getting this exception from realm:

Fatal error: 'try!' expression unexpectedly raised an error: Error Domain=io.realm Code=2 
"Unable to open a realm at path '/var/mobile/Containers/Data/Application/E617FF40-6D77-4F3B-
8F3B-0DAC23C9C954/Documents/ApplicationData.realm.lock': open() failed: Operation not
 permitted." UserInfo={Error Code=2, NSFilePath=/var/mobile/Containers/Data/Application/E617FF40-
6D77-4F3B-8F3B-0DAC23C9C954/Documents/ApplicationData.realm.lock, 
Underlying=open("/var/mobile/Containers/Data/Application/E617FF40-6D77-4F3B-8F3B-
0DAC23C9C954/Documents/ApplicationData.realm.lock") failed: Operation not permitted, 
NSLocalizedDescription=Unable to open a realm at path 
'/var/mobile/Containers/Data/Application/E617FF40-6D77-4F3B-8F3B-
0DAC23C9C954/Documents/ApplicationData.realm.lock': open() failed: Operation not permitted.}: file 
/BuildRoot/Library/Caches/com.apple.xbs/Sources/swiftlang_Fall2018/swiftlang_Fall2018-
1000.11.37.1/src/swift/stdlib/public/core/ErrorType.swift, line 184

This started in a version of our app 3 months ago. We have done realm schema changes and migrations in many of our releases including the one in which this crash started to show up.

I have gone through https://realm.io/docs/swift/latest/#using-realm-with-background-app-refresh, but found that there is mismatch between Realm’s and Apple’s documentation, specifically this part:

  • Realm
If your app attempts to do any work involving Realm while the device is locked and the 
NSFileProtection attributes of your Realm files are set to encrypt them (which is the case by default), 
an open() failed: Operation not permitted exception will be thrown.
This (NSFileProtectionCompleteUntilFirstUserAuthentication) is the default class for all third-party app 
data not otherwise assigned to a Data Protection class.

We do access realm when the app is in background (via background fetches and silent notifications). However, our crash numbers are quite high and it’s hard to imagine them all happening due to NSFileProtectionCompleteUntilFirstUserAuthentication protection level (i.e. user restarting the device and our app waking up and accessing realm via background fetches or silent notifications before user unlocks).

Some other things to note:

  • We are not using Realm’s encryption
  • We are not using any data protection capabilities in iOS
  • We are seeing almost a 1:1 correlation between number of users and number of crashes
  • We are not setting any explicit file protection level on the realm file url in our app

Goals

Understand when and why realm would throw this exception when using the default file protection level.

Expected Results

More details logs into why Operation not permitted.

Actual Results

Stack trace only tells open() failed: Operation not permitted.

Steps to Reproduce

Don’t have repro steps yet

Code Sample

NA

Version of Realm and Tooling

Realm framework version: 3.13.1

Realm Object Server version: NA

Xcode version: 10.1 (10B61)

iOS/OSX version: 12.1.4 (16D57)

Dependency manager + version: Cocoapods 1.5.3

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Reactions: 9
  • Comments: 42 (11 by maintainers)

Most upvoted comments

I had the same problem, in my application has the possibility of the user log off and enter with another account, which generates another bank file of realm, the problem in my application happens when the user already has a database realm in the documents folder of the application and logs off, I imagine the realm problem has happened because realm is trying to access the primary database without having access to it.

@tgoyne thanks for jumping in!

To give some more context: this is happening for users who previously had accessed this ApplicationData.realm. Immediately after installing the app update, they start getting this exception when accessing realm.

One thing that I forgot to mention previously is that we do add new config.objectTypes to this realm and bump up the schemaVersion occasionally.

Also to re-iterate, we don’t change the file system permissions on realm’s configuration.

This is the LOC where realm catches this exception:

catch (util::File::AccessError const& ex) {
        // Errors for `open()` include the path, but other errors don't. We
        // don't want two copies of the path in the error, so strip it out if it
        // appears, and then include it in our prefix.
        std::string underlying = ex.what();
        RealmFileException::Kind error_kind = RealmFileException::Kind::AccessError;
        // FIXME: Replace this with a proper specific exception type once Core adds support for it.
        if (underlying == "Bad or incompatible history type")
            error_kind = RealmFileException::Kind::BadHistoryError;
        auto pos = underlying.find(ex.get_path());
        if (pos != std::string::npos && pos > 0) {
            // One extra char at each end for the quotes
            underlying.replace(pos - 1, ex.get_path().size() + 2, "");
        }
        throw RealmFileException(error_kind, ex.get_path(),
                                 util::format("Unable to open a realm at path '%1': %2.", ex.get_path(), underlying), ex.what());

Can you provide any pointers about any potential causes this could happen?

It seems that this problem occurred after an app upgrade. Not quite sure yet, just guessing.

Having same problem but the error message is slightly different in my case.

Thread 1: Fatal error: 'try!' expression unexpectedly raised an error: Error Domain=io.realm Code=2 "Unable to open a realm at path '/var/mobile/Containers/Data/Application/97C06C05-7655-4DD2-929A-DB5C4981C715/Documents/default.realm': Invalid top array (ref: 31048, size: 11)
Exception backtrace:
0   Realm                               0x0000000105d30808 _ZN5realm15InvalidDatabaseC2ERKNSt3__112basic_stringIcNS1_11char_traitsIcEENS1_9allocatorIcEEEES9_ + 60
1   Realm                               0x0000000105d220e0 _

having the same problem, any solution?