"fs-repo-10-to-11" cannot be opened error message

When launching Brave Version 1.29.51 Chromium: 92.0.4515.131 (Official Build) beta (x86_64)
I receive a macOS 10.15.7 (19H1323) System message saying:
“fs-repo-10-to-11” cannot be opened because the developer can not be verified.

I am running macOS Catalina 10.15.7 on an iMac (27-inch, Late 2012)

The message offers two choices: “Move to Trash” or “Cancel”. When I click Move to Trash, I am told that the file could not be moved to Trash and to move it manually. When I search for the file, I can not locate it.

Screen Shot 2021-08-05 at 5.19.07 PM

1 Like

Same exact issue here. Possibly something to do with IPFS?

1 Like

Me too. Every open or every new profile.

This is definitely related to IPFS.

Apparently, IPFS is attempting to automatically run a migration tool from inside Brave, which, by itself, is not an issue. It does the download correctly, which will be inside ~/Library/Application Support/BraveSoftware/Brave-Browser — you’ll see a dozen or so directories with randomly generated lowercase names such as oofiananboodjbbmdelgdommihjbkfag (they’re always 32 characters long).

Inside one of these will be the fs-repo-10-to-11 application. If you’re comfortable using command-line utilities, you can do a find . -name fs-repo-10-to-11 -print to check in which one of them it was (temporarily) downloaded. Also, if you wish, you can manually remove it from the command line (rm -rf oofiananboodjbbmdelgdommihjbkfag — replace with the correct directory name, of course!!)

A few things should be apparent with the fs-repo-10-to-11:

  • It’s clearly an executable (run file fs-repo-10-to-11 to identify it)
  • However, it doesn’t run because the appropriate flags are not set (do a chmod +x fs-repo-10-to-11) and it’s quarantined (to un-quarantine it, run xattr -d com.apple.quarantine fs-repo-10-to-11)
  • It is properly signed, as verified with codesign -dv fs-repo-10-to-11

I believe that it refuses to run exactly because of not having the execute flag set and getting quarantined automatically by Brave. This might be the intended behaviour, though; or the IPFS team may have introduced a bug on that migration tool at some point, thus the weird error.

I’m also running a local IPFS node, and I’ve also experienced instabilities with it. Thus, it’s possible that the issue is not related to Browse at all, but to the IPFS network. On the other hand, the OP is from early August, and today is the first day I got the same error — in my case, Brave + IPFS have been running flawlessly up to today.


Same issue. Alert about fs-repo-10-to-11 appears on every restart of Brave.

1 Like

Hi Gwyneth, is there any solution for those of us that aren’t comfortable using terminal and aren’t so technical?

@garrywithtwors I wish it were easier to do it differently (also, my ‘solution’ is not really a solution, but rather a way to prevent Brave from complaining, at least for a while; it will happily continue to do so after a while). Here’s my attempt at doing it using the GUI:

  • Open Finder
  • Open the Go menu (click once), then press the Option ⌥ key; you should get a new entry in your menu, Library, It appears between Home and Computer. Click on Library
  • On the Library folder, navigate to Application Support, then BraveSoftware, then Brave-Browser
  • Click on the Search icon :mag: and type fs-repo-10-to-11; select it as Filename (makes the search faster), then select the Brave-Browser tab: when click on it, the Finder should almost immediately show an executable file (it has a cute Terminal-like 🖵 icon, in black).
  • Just move it to the Trash (Bin for those in Britain) — it should work without any fuss, when doing it from the Finder (as opposed to having Brave do it)

There, the file is gone!

For a while, at least, As soon as you use IPFS again, the file will be downloaded once more, and Brave will complain again. As @walkertraylor mentioned, restarting Brave will not really make a difference if you do not delete the file manually; but even if you successfully delete it, eventually, sooner or later, you will click on something IPFS-related, and Brave will download it again with wrong permissions…

Until the person dealing with IPFS support under Brave figures out what are the right permissions to apply to that file, and uploads a fixed version to the Brave code repository, we’re all out of luck — we just need to figure out a workaround until someone is able to provide us with a working fix…

I hope that this helped a bit…

1 Like

O-kay… here is what I hope to be the final solution to this issue. Or at least a temporary, permanent hack until the Brave core developers fix their code.

The plot thickens

By digging around, I remember that this was not the first time it happened to me, and it was strange that it was happening again. I started with the following clues:

  • There is a notarization issue (see the long explanation below) with a Brave component related to IPFS (makes sense, since I use IPFS as much as I can, recently even setting up my own external node) which has been automatically downloaded
  • Removing the quarantine attribute on the relevant files seems not to help much
  • Exactly the same happened a while ago, but then stopped happening
  • Apparently, it’s not something you can ‘fix’ easily by just deleting the culprit (Brave will simply download it again) or changing anything on the Brave Preferences
  • While searching on Google, most threads related to this specific issue only report the issue, but there seems to be no real ‘solution’

That meant delving deeper…

The actual issue

Every now and then, IPFS subtly changes the way it works, and you have to run some migration tools to keep your system compliant with the rest of the nodes. This is usually a very straightforward procedure. To make it easy for everyday users, the Brave core team has developed a simple procedure, where a temporary ‘migration’ component is downloaded (automatically, as soon as Brave is made aware that the database format has changed), briefly run, and then stored away/deleted until it might become needed again.

Because this is supposed to happen without user intervention, it works in a non-conventional way — you’d suppose that it gets downloaded in the usual Download folder and then have a standard package that you’d click to run.

Instead, it works a bit like the ‘internal’ extensions (such as Tor): the auto-updating of those components will get downloaded in a specially-crafted folder (somewhere under /var/folder), and, once the download is complete, its components get moved to ~/Library/Application\ Support/BraveSoftware/Brave-Browser/nljcddpbnaianmglkpkneakjaapinabi/X.Y.Z, where X.Y.Z is the version.

Why the strange path? Well, as far as I understand, all Chromium-based browsers have some sort of ‘unique’ identifiers for each extension — so that there is no conflict between two extensions that just happen to have the exact name but do different things. If you take a peek at that folder, you’ll see similarly-named paths for other extensions as well. Some of those are inside /Default/Extensions/ (this is true if you’re using different profiles; subsequent profiles will install their own copies under /Profile 1/Extensions/ and so forth), some are not. This particular folder name is for the IPFS extension.

Once the relevant files are in place (or perhaps while they’re being prepared to be copied), macOS will go through all scans and checks for viruses, malware, Trojans, worms, etc. If everything is ok, the executable component of the extension will be run.

As you’ve guessed, when you get this ‘cannot be opened’ error message, something failed.

Again, as far as I can see, the IPFS extension (or pseudo-extension…) has at the very least two sets of files. The first set contains those application files that make up the extension (i.e. the actual code that will run). Then there is a file called manifest.json — which all extensions have, to identify what they are, and to provide a key (very likely, a key used for signing the extension). And most also have a manifest.fingerprint, which, presumably, is a way to double-check that manifest.json hasn’t been tampered with (for details, read the explanation below as well). Under some extensions, this file is empty, so I’m not sure if the fingerprint is mandatory (probably not).

When the IPFS extension figures out that it needs to run a migration tool, it gets downloaded and then copied into the same folder as the extension itself. And, as you guessed it already, the name of the migration tool is (currently) fs-repo-10-to-11, meaning, most likely, ‘tool to upgrade the IPFS repository from version 1.0 to 1.1’ .

Now, in my Mac, what seems to consistently happen is the following (or something close to it):

  • This file is not executable (either on purpose or because of the error) and only my user is allowed to take any action upon it (permission is not given for any other user — which include many processes running on your Mac as well — to even read that file)
  • It is automatically set to be quarantined (i.e. the com.apple.quarantine extended attribute is turned on)
  • For some reason, it has been identified by either Brave or very likely the underlying security system (Gatekeeper) that this file has not been properly notarized, and so it gets rejected by the operating system

Because of the permission issues, it explains why you cannot automatically move the file to the Trash/Bin: whatever process or subprocess detected the lack of proper notarization does not have permission to actually remove that file.

Pressing Cancel will also not work. Remember, all this happens in the background, with zero user intervention. My guess is that Brave simply gets a notification that ‘something failed’ and just attempts to download the migration tool from scratch. Because the migration tool itself fails the notarization checks, you can do whatever you wish with Brave (restart, reinstall…), but nothing will get you rid of the error.

(I didn’t try, but eventually disabling the whole IPFS system and removing everything IPFS-related — especially if you’re running your own local node — might force Brave to download the newest version with an already-migrated database, and so avoid the eternal trap of the ‘cannot be opened’ error message).

Indeed, this has happened before — and the explanation given for the error was a lack of notarization at some stage. The fix mentioned on that GitHub issue applied to version 1.0.5; we’re now at 1.0.6, and apparently suffering from the same issue!

How to fix it

Sorry, this is the kind of thing that really requires using the Terminal… you need to pass special parameters at some point, which is notoriously hard to do from the macOS GUI.

What I found out was simple enough: what happens if I run the migration tool manually? Theoretically, the next time the IPFS component checks for a migration need, everything will already be migrated, so it doesn’t need to go through the whole cycle again (and fail with the ‘cannot be opened’ error).

In fact, if you go to ~/Library/Application\ Support/BraveSoftware/Brave-Browser/nljcddpbnaianmglkpkneakjaapinabi/1.0.6 (version 1.0.6 was the current version at the time of writing) and change the permissions on fs-repo-10-to-11, it will run from Terminal (assuming that you have given it permission — via the System Preferences — to run anything, anywhere).

For those uncomfortable with the Terminal and the shell, you will need to do the following:

  • Open Terminal
  • Move to the correct folder: cd ~/Library/Application\ Support/BraveSoftware/Brave-Browser/nljcddpbnaianmglkpkneakjaapinabi/1.0.6
  • Unquarantine the application: sudo xattr -d com.apple.quarantine fs-repo-10-to-11 (you will be prompted for your user’s password)
  • Make it executable: sudo chmod 755 fs-repo-10-to-11

At this point, you can simply run ./fs-repo-10-to-11 from the shell, and it should run the migration without errors.

There was only a catch: namely, figuring out where Brave is storing the repository for the internal IPFS node. By default, this migration tool will assume that the repository is in a ‘usual’ location (wherever it might be). But the embedded IPFS node has a special place for the repository, namely, ~/Library/Application\ Support/BraveSoftware/Brave-Browser/brave_ipfs.

How did I find that this is, indeed, the correct path? Well, basically I watched what Brave was running just before it prompts the box with the ‘cannot be opened’ message. And — sure enough! — it attempts to run fs-repo-10-to-11 from the extension directory we have seen before (nljcddpbnaianmglkpkneakjaapinabi), and passes it that path as a parameter, so all you need to do is:

./fs-repo-10-to-11 -path=~/Library/Application\ Support/BraveSoftware/Brave-Browser/brave_ipfs -verbose=true
(that’s all in a single line!)

That’s it! You don’t do anything else; Brave will not complain any longer. If you run the same command twice by mistake, don’t worry — the migration tool will correctly figure out that the repository version is already 11 and refuse to upgrade it from 10 to 11.

So all we need to do now is wait for the Brave team to release a fix for 1.0.6 just like they did for 1.0.5…

Here goes a long explanation on how notarization works

You can safely skip this section if you’re already bored, it doesn’t add anything new. Consider it as ‘reference material’.

Warning: This long explanation is neither exhaustive nor accurate; I’m not an expert on this subject and don’t know that much about the internal workings of the macOS security settings and the integration with Gatekeeper. So, read the following explanations with a pinch of salt; caveat utilitor.

For those who don’t know, with recent versions of macOS, and most definitely starting with Catalina, Apple has been much more aggressive with whatever you install in your Mac from external sources (i.e. anything outside the Apple Store): they require not only that such software gets signed with a special digital (cryptographic) signature provided by Apple only to (paying) developers, but, on top of that, applications now also have to be counter-signed by Apple themselves! This started to get implemented on the Apple Store (where Apple could easily identify the developer, bearer of a valid signature, and see if it had been properly signed — and add their own signature to that as well), but later was applied to everything that you download from so-called ‘untrusted sources’ (which, for Apple, means ‘everything outside Apple’…).

In general, legitimate developers (such as the Brave core developers!) have not only their own digital signature (any legitimate developer can apply for one, it costs roughly $100/year) but, naturally enough, they’re allowed to submit their applications to Apple and request that they counter-sign (‘notarize’) them. As far as I know, this is a semi-automated process (I’m not a paying developer, so I don’t have a key and thus never made experiments with their tools): basically, Apple is just making sure that the application does not have any malware, virus, or trojan subtly embedded in the code, before allowing people to download software. This level of paranoia is what makes it so hard to download anything seriously dangerous on your Mac — no matter where you’re downloading it from.

But Apple also knows that some genuine, legitimate developers are not willing to apply such a complex scheme to their own software — this is particularly true with open-source software, available through GitHub, where hundreds of people may be contributing snippets of code, and not all of them (probably very few of them, in fact) are paying developers. In such cases, if the application is signed by at least one paying developer, your Mac will download the app, but, before installing it, it will run all of Apple’s anti-virus and anti-malware tools — those that are always running in the background and that Mac users are not even aware of their existence (and they get continuously updated, too). You’ll get a floating box saying that Apple has not signed that software, but it appears to come from a legitimate source, so everything will be fine if you allow your system to scan that app. You see, if the app has been notarized by Apple before being distributed, Apple will have done all the checking in advance, and, once it gets signed by Apple, you cannot modify the application any longer. Or rather… you can… which is what happens if someone tries to insert malicious code into the app… but the signature will not validate any longer. So your Mac knows that such an app may have been compromised, and will not allow it to be installed.

The system is not undefeatable, of course (no system is 100% perfect and secure), but it provides a reasonable guarantee that Apple-notarized applications are, indeed, really safe to run (they may still have bugs, of course… but no malicious code of any sort), and that you can get them trusting that such apps will not harm your Mac.

What about a non-Apple-notarized app? Well, to guarantee some degree of security, when you download such an app, your Mac will step in and ‘self-notarize’ the app on behalf of Apple. Essentially, macOS will check for viruses, scan for malware, do some local testing, and lock the application in place with a digital signature, which acts as a seal — even though the origin of such an application may not have been Apple, at the very least, at the time of scanning, it did not contain any known virus/malware; and once the scanning finishes, nothing can tamper with the application any longer: a new virus, which may have eluded Apple’s own virus scanner, may infect the application after it has been downloaded, but to no avail: once that happens, the seal is broken — the application was changed in subtle ways, and the signature will not match any longer — so your Mac knows that the app is not ‘safe’ any longer. ‘Something’ has happened to it, and it’s likely that it was a virus of some sort (or not…). Or the app may have become corrupted in some subtle way (imagine that your hard disk failed at some point, and the recovery from Time Machine wasn’t complete, so you only got the app restored partially). When that happens, macOS will complain, saying that it cannot run the application any longer, and suggest that you contact the developer, or go back to the site where you originally downloaded it, and download a fresh copy. This will, in theory, overwrite whatever code had been compromised, and the fresh copy will be scanned again, and if everything seems to be correct, then your Mac will sign it once again.

In certain cases, you can override Apple’s security layers. For instance, when files for an application have been downloaded, if they run as regular user processes and are found not to be notarized, macOS will allow you to override the check when you right-click on the application and select Open, In those cases, macOS will run Gatekeeper on the application to check for malware before running the first time.

Sometimes, however, for some reason, a certain application cannot be checked (I really don’t know in which cases that happens), and macOS flags it as ‘quarantined’. Such apps cannot be automatically launched. You still can do it manually, though: ‘quarantine’ is just an extended attribute flag, and you can remove it with:

$ xattr -d com.apple.quarantine /path/to/your/application

You can even use -r to un-quarantine whole folders, because a macOS application is usually packaged as a ‘special’ folder:

$ xattr -r -d com.apple.quarantine ~/Application/Something.app

This is the usual way to run applications that haven’t been properly signed by their developers. Be aware that there is a good reason why an application has been quarantined — while it may have been signed with a digital signature, for instance, that signature may have been compromised, or simply has expired, or is not known by Apple as a ‘valid’ signature, and so on.

When the signature seems to be fine, but the files inside a package are not the size (or have a different content than) that the signature is actually signing, that really means that the whole package can be compromised, and this is especially true if, for some reason, Gatekeeper is unable to check the package for malware. In that scenario, you get the dreaded error that the file/app cannot be openend and should be removed and a new one downloaded again.

You can see that the overall Apple security system is complex, and I’m not even sure that the above is but an oversimplification…

Anyway, the point here is that hopefully the core developers of the IPFS migration tool become aware of the issue, properly sign their tool, and release a new version that ‘just works’. In the meantime, the above solution really works: manually migrate to the latest IPFS version, and Brave will never try to run the migration tool again.

Interestingly, a week or so before I got this error, I was getting a lot of IPFS-related errors on Brave pages that loaded things over IPFS, and I couldn’t figure out what was wrong with them (since they worked so well in the past). Allegedly, these errors came from the changes in the repository file format — thus the need to migrate them! Once I manually ran the tool, those errors disappeared as if by magic.

Also note that the IPFS node dæmon — the small application that will run in the background, creating a local node which will connect to the rest of the world using IPFS — is designed to migrate the repository files as soon as a new version is released. Apparently, since the IPFS specifications are still evolving at a rapid pace, it’s expectable that the repository will change its file format and requires migration — and this will be the case for quite a while, until IPFS leaves the ‘alpha’ stage of development. That is still a bit in the future, so, in the meantime, we have to rely on the automatic migration tools to do their jobs — and that means, at least on the Mac platform, that everything is properly signed and notarized…


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.