[error report] hybrid migration from version 11 to 18

[chrissy-cyber]

Re-opening IPFS to finish getting the CID I need for my images to be decentralized. IPFS already had uploaded 4,444 images and they had a CID attached. Now It is throwing me a huge error on everything I try to click. IT says there is a problem with it's connection and I can't get back to my work or access what it already uploaded at all

• Desktop: 0.48.0
• OS: darwin 23.6.0 arm64
• Electron: 40.6.0
• Chrome: 144.0.7559.177

Error: Initializing daemon...
Kubo version: 0.40.1-39f8a6554
Repo version: 18
System version: arm64/darwin
Golang version: go1.25.7
Kubo repository at /Users/christinaforte/.ipfs has version 11 and needs to be migrated to version 18.
Starting hybrid migration from version 11 to 18
Using hybrid migration strategy: external to v16, then embedded
Phase 1: External migration from v11 to v16
Looking for suitable migration binaries.
Need 5 migrations, downloading.
Downloading migration: fs-repo-11-to-12...
Downloading migration: fs-repo-12-to-13...
Downloading migration: fs-repo-13-to-14...
Downloading migration: fs-repo-14-to-15...
Downloading migration: fs-repo-15-to-16...
Fetching with HTTP: "https://trustless-gateway.link/ipfs/QmRzRGJEjYDfbHHaALnHBuhzzrkXGdwcPMrgd5fgM7hqbe/fs-repo-15-to-16/versions"
Fetching with HTTP: "https://trustless-gateway.link/ipfs/QmRzRGJEjYDfbHHaALnHBuhzzrkXGdwcPMrgd5fgM7hqbe/fs-repo-13-to-14/versions"
Fetching with HTTP: "https://trustless-gateway.link/ipfs/QmRzRGJEjYDfbHHaALnHBuhzzrkXGdwcPMrgd5fgM7hqbe/fs-repo-11-to-12/versions"
Fetching with HTTP: "https://trustless-gateway.link/ipfs/QmRzRGJEjYDfbHHaALnHBuhzzrkXGdwcPMrgd5fgM7hqbe/fs-repo-14-to-15/versions"
Fetching with HTTP: "https://trustless-gateway.link/ipfs/QmRzRGJEjYDfbHHaALnHBuhzzrkXGdwcPMrgd5fgM7hqbe/fs-repo-12-to-13/ve

[lidel]

Hi @chrissy-cyber, your data is safe. The error is from the one-time repo migration that runs before the daemon starts. None of your images or CIDs have been touched, your IPFS folder at /Users/christinaforte/.ipfs is intact.

Your repo is from a much older version of IPFS Desktop (~2022) and Kubo needs to step it through 5 format upgrades (v11 -> v16) by downloading small migration tools from trustless-gateway.link. The error is most likely a slow or interrupted download from that gateway.

A few things to try, in order:

1. Make a backup first so you have a known-good snapshot before any retry: cp -r ~/.ipfs ~/Desktop/ipfs-backup. Migrations create their own .bak files but a manual copy costs nothing.

2. Quit IPFS Desktop and try again on a stable network. The migration is restartable, no data loss.

3. Add fallback gateways so the migration can retry against alternates if trustless-gateway.link is slow or blocked. Edit ~/.ipfs/config and set:

   "Migration": {
     "DownloadSources": [
       "https://trustless-gateway.link",
       "https://dweb.link",
       "https://ipfs.filebase.io",
       "https://dget.top"
     ],
     "Keep": "cache"
   }

   These four are the public gateways I verified return valid application/vnd.ipld.car responses for the migration distribution path without cross-domain redirects, as of today. Kubo will try them in order. Then start IPFS Desktop again.

4. If it still fails, please open Terminal and run:

   /Applications/IPFS\ Desktop.app/Contents/Resources/app.asar.unpacked/node_modules/kubo/kubo/ipfs daemon --migrate=true
   

   and paste the full output here. That gives us the actual error past the truncation point in the report.

What's important: do not delete ~/.ipfs. Once the migration completes (or is rerun manually) all your CIDs return.

Let us know if this helped.

[chrissy-cyber]

My files that I uploaded to a decentralized hosting server IPFS. Are those stable and will they live on the blockchain forever? Or You are recommending me to try this again just in case so I have an actual backup if something fails? I have been at this for days. I am not the typical Dev but I am a project owner and am trying to get our files, metadata, JSON's to a sturdy hosting server and off of a centralized server which they were before I tried any of this. Which step if you can make this in smaller increments I can try for this please? I see many lines of code and I am more of a Step 1. Step 2. Step 3. person when it comes to using the next importing steps to these. If you could please help in any way with explaining a little slower, I know I can make this work. I appreciate you reaching out to me. I have been going a little crazy with using so many IPFS hosting servers like NFT.Storage (which doesnt take new memberships) Also a couple others that were not working as well. Than I used Third Web and imported IPFS into it and did it all together on Third Web and it seemed to go through. I do have a CID for it now and a URL for minting (new URL) so we wont be using the same platform that we launched on. We are going to be using our own and leaving that partnership as they have been no help to us. So the purpose of moving everything over is to build a new smart contract which I am doing now and I have to deploy it. I just want to make sure all of my images are safe first.

…

On Wed, Apr 29, 2026 at 9:35 AM Marcin Rataj ***@***.***> wrote: *lidel* left a comment (ipfs/ipfs-desktop#3147) <#3147 (comment)> Hi @chrissy-cyber <https://github.com/chrissy-cyber>, your data is safe. The error is from the one-time repo migration that runs before the daemon starts. None of your images or CIDs have been touched, your IPFS folder at /Users/christinaforte/.ipfs is intact. Your repo is from a much older version of IPFS Desktop (~2022) and Kubo needs to step it through 5 format upgrades (v11 -> v16) by downloading small migration tools from trustless-gateway.link. The error is most likely a slow or interrupted download from that gateway. A few things to try, in order: 1. *Make a backup first* so you have a known-good snapshot before any retry: cp -r ~/.ipfs ~/Desktop/ipfs-backup. Migrations create their own .bak files but a manual copy costs nothing. 2. *Quit IPFS Desktop and try again on a stable network.* The migration is restartable, no data loss. 3. *Add fallback gateways* so the migration can retry against alternates if trustless-gateway.link is slow or blocked. Edit ~/.ipfs/config and set: "Migration": { "DownloadSources": [ "https://trustless-gateway.link", "https://dweb.link", "https://ipfs.filebase.io", "https://dget.top" ], "Keep": "cache" } These four are the public gateways I verified return valid application/vnd.ipld.car responses for the migration distribution path without cross-domain redirects, as of today. Kubo will try them in order. Then start IPFS Desktop again. 4. *If it still fails*, please open Terminal and run: /Applications/IPFS\ Desktop.app/Contents/Resources/app.asar.unpacked/node_modules/kubo/kubo/ipfs daemon --migrate=true and paste the full output here. That gives us the actual error past the truncation point in the report. What's important: *do not delete ~/.ipfs*. Once the migration completes (or is rerun manually) all your CIDs return. Let us know if this helped. — Reply to this email directly, view it on GitHub <#3147 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BASCJNIP5G6IFL2KK6VEUJL4YIAJNAVCNFSM6AAAAACYFYXZLGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DGNBUGIYDAOJYGQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[lidel]

taking your questions in order:

Are your IPFS images "on the blockchain"?

No. IPFS is a different system, called content-addressed storage. Every file gets a fingerprint called a CID, and any computer that holds a copy of the bytes can serve them to anyone who asks for that CID. There is a short plain-English explainer at https://docs.ipfs.tech/concepts/what-is-ipfs/.

IPFS is not magic free storage.

You may have heard the saying "there is no cloud, it's just someone else's computer." The same truth applies here: in IPFS, there is no free storage forever. Someone has to actually run a computer that holds your data and shares it with the rest of the network. That act is called pinning, and it is what keeps your content reachable.

What lasts forever is the CID. The bytes behind it are only there as long as somebody keeps a copy alive.

Are your files safe right now?

Two places to think about:

1. The CID you got from Third Web. Reachable today only because Third Web is pinning the data for you. If they shut down or change their service, your CID still exists, but the bytes go offline. The same has played out before with NFT.Storage, web3.storage (now Storacha), Fleek, and others. Services come and go.
2. Your local Mac at /Users/christinaforte/.ipfs. This is the old IPFS Desktop folder with the 4,444 images you added in 2022. It is intact even though IPFS Desktop itself will not start. Nothing in there has been deleted.

Rule of thumb: never trust a single third-party to keep your data alive. Always keep your own backup. Then if a provider goes away, you point a new provider (or your own node) at the same files, and the same CID keeps working as long as at least one pinner is up.

What I would do if I were in your shoes:

1. Try restarting IPFS Desktop. It should fetch migrations fromtrustless-gateway.link eventually (check if its not blocked by your macOS). Quit IPFS Desktop, then open it again. If it still does not finish on the first attempt, close it and open it again. The migration is restartable. Keep trying until the daemon comes up cleanly. Once that happens, your 4,444 images are reachable from your own machine again.

2. If that does not help bring IPFS Desktop back online by retrying the migration with a better list of gateways. While IPFS Desktop is turned off, edit config ~/.ipfs/config and replace your existing Migration block with this, which puts the gateway you had trouble with last, for example:

   "Migration": {
     "DownloadSources": [
       "https://gateway.pinata.cloud",
       "https://ipfs.filebase.io",
       "https://4everland.io",
       "https://dget.top",
       "https://trustless-gateway.link"
     ],
   }

Then repeat what you did for (1), keep retrying until it fetches all things and finishes migration.
Note: this is one-time inconvenience caused by you not updating for 5 years.

3. Once IPFS Desktop is back, sign up to a second pinning service and ask it to pin the CIDs you care about. Now your data lives in three places: your local node, the new pinning service, and Third Web. If any one goes away, the other two keep the bytes online.

A couple of honest notes:

• This is high-level guidance, not consultancy. I wrote this as its useful resource for future use, but I am unable to allocate more time for one-on-one support beyond this comment. For step-by-step help with the config edit or anything else IPFS-related, the friendliest place is the IPFS community forum: https://discuss.ipfs.tech/c/help/13. Post your question there and hopefully people from community will reply.
• The next release of Kubo (the engine inside IPFS Desktop) will ship with this improved gateway list already built in, so you will not need to edit any JSON yourself. That work is in fix: migration fetcher robustness kubo#11305. If editing the config file feels intimidating, you can simply wait for the next IPFS Desktop release that bundles it (3-4 weeks from now). Your local data on disk is safe in the meantime.

Wishing you a smooth launch.

Pleas let us know if you managed to recover IPFS Desktop, and if this issue can be close.