# Recovering a directory CID no longer served — files referenced on-chain, gateways return 504 / LoadBlockFailedError **URL:** \ **Category:** Help\ **Created:** [July 7, 2026, 9:07pm UTC](https://discuss.ipfs.tech/t/recovering-a-directory-cid-no-longer-served-files-referenced-on-chain-gateways-return-504-loadblockfailederror/20271 "2026-07-07T21:07:33Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![ToddlerNFT](https://avatars.discourse-cdn.com/v4/letter/t/47e85d/32.png) [@ToddlerNFT](https://discuss.ipfs.tech/u/ToddlerNFT)\ **Post date:** [July 7, 2026, 9:07pm UTC](https://discuss.ipfs.tech/t/recovering-a-directory-cid-no-longer-served-files-referenced-on-chain-gateways-return-504-loadblockfailederror/20271/1 "2026-07-07T21:07:33Z")
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](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 ---
**Author:** ![ylempereur](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/ylempereur/32/5528_2.png) [@ylempereur](https://discuss.ipfs.tech/u/ylempereur)\ **Post date:** [July 8, 2026, 2:49pm UTC](https://discuss.ipfs.tech/t/recovering-a-directory-cid-no-longer-served-files-referenced-on-chain-gateways-return-504-loadblockfailederror/20271/2 "2026-07-08T14:49:12Z")
I ran a search for over 12 hours and didn’t get it, it’s probably gone for good. ---
**Author:** ![lidel](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/lidel/32/9853_2.png) [@lidel](https://discuss.ipfs.tech/u/lidel)\ **Post date:** [July 19, 2026, 6:58pm UTC](https://discuss.ipfs.tech/t/recovering-a-directory-cid-no-longer-served-files-referenced-on-chain-gateways-return-504-loadblockfailederror/20271/4 "2026-07-19T18:58:43Z")
The important part: > [@ToddlerNFT](#): > > I do have the original image files backed up locally That’s what actually saves you here, and it opens a recovery path I’ll get to below. One thing to untangle first: > [@ToddlerNFT](#): > > 1. providers are found on the DHT but return no block 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](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](https://web.archive.org/web/20260308034058/https://ipni.io/), 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: > [@ToddlerNFT](#): > > all pointing to /dns4/elastic.dag.house/tcp/443/wss 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](https://check.ipfs.network/?cid=bafybeiegpltp3njuufjwz2aaoufcgbv6u42emqj3w52wp5chje7zjz6t2i&multiaddr=&ipniIndexer=https%3A%2F%2Fcid.contact&timeoutSeconds=5&httpRetrieval=on) produces: > > ![check-screenshot](https://us1.discourse-cdn.com/flex020/uploads/ipfs1/original/2X/8/8b5b7e952eda37d2593ab087eba4c4ed00ece307.png) 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](https://web.archive.org/web/20260503081756/https://medium.com/@storacha/an-update-on-storacha-and-important-news-for-you-and-your-data-15a5d10b7da0) 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](https://github.com/ipni/indexstar), so [filing an issue there](https://github.com/ipni/indexstar/issues) 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](https://specs.ipfs.tech/ipips/ipip-0499/). Try both, since older uploads used the legacy defaults and newer ones the modern ones: 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.