%s (currently offline, perhaps retry after attaching to the

Error message

%s (currently offline, perhaps retry after attaching to the network)

What it means

Same `ipld.ErrNotFound` handling as the explicit-offline case, but this branch fires when the user did NOT pass `--offline` yet the node is currently offline (`node.IsOnline == false`). Because there is no explicit offline flag, the hint tells the user to attach to the network so missing blocks can be retrieved.

Source

Thrown at core/commands/dag/export.go:151

	res.SetEncodingType(cmds.OctetStream)
	res.SetContentType("application/vnd.ipld.car")
	if err := res.Emit(pipeR); err != nil {
		pipeR.Close() // ignore the error if any
		return err
	}

	err = <-errCh

	// minimal user friendliness
	if errors.Is(err, ipld.ErrNotFound{}) {
		explicitOffline, _ := req.Options["offline"].(bool)
		if explicitOffline {
			err = fmt.Errorf("%s (currently offline, perhaps retry without the offline flag)", err)
		} else {
			node, envErr := cmdenv.GetNode(env)
			if envErr == nil && !node.IsOnline {
				err = fmt.Errorf("%s (currently offline, perhaps retry after attaching to the network)", err)
			}
		}
	}

	return err
}

// exportPartialCAR is the best-effort engine behind `dag export --local-only`.
// It walks the DAG rooted at root and writes the visited blocks to w as a
// CARv1 stream.
//
// The walker reads from the raw blockstore directly (not via the kubo
// CoreAPI or DAGService), so it is structurally incapable of triggering a
// network fetch. Any block missing or unreadable locally, plus its entire
// subtree, is silently skipped: the resulting CAR is partial by design.
//
// Errors writing the CAR itself (emit failures) are surfaced: those are
// output problems, not local-availability problems.

View on GitHub (pinned to 329838acdf)

Solutions

Check node connectivity with `ipfs swarm peers`; reconnect the daemon to the network.
Wait for bootstrapping/swarm to re-attach, then retry the export.
If the node must stay offline, fetch the missing blocks elsewhere or supply them via a CAR import first.
Inspect the daemon log for connectivity errors (NAT, DHT, bootstrap failures).

Defensive patterns

Strategy: validation

Validate before calling

peers, err := run("ipfs", "swarm", "peers")
if err != nil || len(strings.Fields(peers)) == 0 {
    return errors.New("node offline: cannot fetch missing DAG blocks")
}

Try / catch

if strings.Contains(err.Error(), "retry after attaching to the network") {
    // wait for swarm connectivity, then retry the export
}

Prevention

Check `ipfs swarm peers` returns connections before exporting.
Ensure the daemon finished bootstrapping after startup.
Monitor connectivity (AutoNAT status) on machines with flaky networks.

When it happens

Trigger: Running `ipfs dag export <cid>` on a node started without a network connection (e.g. `ipfs dag export` against an offline daemon or `--offline`-initialized node context) where a DAG block is absent from the blockstore.

Common situations: Daemon started without connectivity (no internet, firewall, swarm disconnected); running the command before the daemon finished bootstrapping; laptop offline while traveling.

Related errors

AI-assisted analysis of ipfs/kubo@329838acdf (2026-09-03). Data as JSON: /api/errors/cf5aed9577fcb745. Report an issue: GitHub.