Recovering a directory CID no longer served — files referenced on-chain, gateways return 504 / LoadBlockFailedError

Help
1

Hi everyone,

I’m trying to recover (or confirm the loss of) a directory CID that backs a
Solana NFT collection. The content was originally stored via web3.storage /
Storacha, and the NFTs reference it on-chain through w3s.link.

The CID:
bafybeiegpltp3njuufjwz2aaoufcgbv6u42emqj3w52wp5chje7zjz6t2i

Example file (referenced on-chain):

https://bafybeiegpltp3njuufjwz2aaoufcgbv6u42emqj3w52wp5chje7zjz6t2i.ipfs.w3s.link/26.json

What happens now:
Fetching through public gateways fails. inbrowser.link returns:

504 Gateway Timeout
LoadBlockFailedError: Failed to load block for bafybeiegpltp3n…

The error also lists providers that were “found but did not return the
requested data” — all pointing to /dns4/elastic.dag.house/tcp/443/wss
(peer id QmQzqxhK82kAmKvARFZSkUVS6fo9sySaiogAnx5EnZ6ZmC).

My questions:

  1. Given that providers are found on the DHT but return no blocks, does this
    mean the data is simply no longer pinned/stored anywhere, or could it still
    be retrievable somehow?
  2. Is there any way from my side to attempt retrieval directly from that peer,
    or to verify definitively whether any node still holds these blocks?
  3. Is there a recommended approach to check provider records / block
    availability for a CID like this (e.g. ipfs routing findprovs, or tooling
    you’d suggest)?

I do have the original image files backed up locally, so my main goal is either
to recover the original metadata JSONs, or to get a definitive confirmation that
the data is gone so I can stop trying and finish migrating to permanent storage.

Any pointers appreciated thanks!

Example item:

bafybeiegpltp3njuufjwz2aaoufcgbv6u42emqj3w52wp5chje7zjz6t2i.ipfs.inbrowser.link/1756.json

2

I ran a search for over 12 hours and didn’t get it, it’s probably gone for good.

4

The important part:

That’s what actually saves you here, and it opens a recovery path I’ll get to below.

One thing to untangle first:

Those providers aren’t coming from the DHT. AFAIK Storacha (formerly web3.storage) never announced content to the Amino DHT, so bafybeiegpltp3njuufjwz2aaoufcgbv6u42emqj3w52wp5chje7zjz6t2i has zero DHT providers. That’s expected, not a sign of extra damage. The only result you get comes from IPNI at https://cid.contact, and that provider is dead.

IPNI is a semi-centralized indexer: a handful of nodes you announce content to, then others query. It’s closer to a BitTorrent tracker than to the DHT. IPNI claims to support federation, but as of today there’s no federation across truly independent operators, so in practice it’s one index behind AWS CDN.

The gist of the problem: for legacy/technical reasons cid.contact keeps returning provider records long after the provider is gone, which is what you’re running into. You already spotted the record yourself:

That single record points at elastic.dag.house, but dialing it fails.

You can see it yourself with the retrieval checker:

https://check.ipfs.network/?cid=bafybeiegpltp3njuufjwz2aaoufcgbv6u42emqj3w52wp5chje7zjz6t2i&multiaddr=&ipniIndexer=https%3A%2F%2Fcid.contact&timeoutSeconds=5&httpRetrieval=on produces:

check-screenshot
check-screenshot1264×1024 138 KB

Found 0 working providers out of 1 sampled: the single IPNI record is elastic.dag.house, and every dial to it fails. So the content genuinely isn’t being served anywhere reachable right now.

Storacha itself wound down its services. Their announcement has the timeline; gateways (w3s.link) stopped serving on 2026-05-31. To recover the metadata JSONs from any leftover copy, the support email in that announcement is worth a try, in case anyone still reads it post-shutdown.

Two concrete suggestions:

  1. Report the stale record at IPNI. A dead provider being served indefinitely is the kind of thing the IPNI folks would want a repro for. The /routing/v1/providers endpoint on cid.contact is served by ipni/indexstar, so filing an issue there with your CID and the checker output above is a good place to start.

  2. You may be able to rebuild the exact CIDs from your local backups. If the images produce the same bytes and get chunked the same way, you get the same CIDs, so the same NFT references resolve again once you re-pin them. Kubo now ships deterministic import profiles for this in IPIP-0499. Try both, since older uploads used the legacy defaults and newer ones the modern ones:

    One of them may reproduce the image CIDs directly. The metadata JSONs are trickier unless you kept those too, since you’d need the exact original bytes to match this directory CID.

One takeaway for anyone referencing IPFS CIDs in their apps and products: free hosting is an ephemeral convenience, not a guarantee. The content address stays valid forever, but someone has to keep serving the bytes. Keeping your own copy is what makes recovery possible once a provider goes away. For a 1:1 archive of an IPFS dataset (exact CIDs, directory structure, and all blocks, not just the underlying files) export the DAG to a .car archive with ipfs dag export (see ipfs dag export --help). That single file preserves everything needed to re-serve the exact same CIDs later.