ipfs/kubo · critical

failed to get config: %w

Error message

failed to get config: %w

What it means

During MFS root setup, Kubo reads the node configuration via repo.Config() to obtain Import-scoped settings. If the config cannot be loaded (file read error, JSON parse error, datastore-backed config failure), the error is wrapped as "failed to get config". This is an infrastructure failure, not a validation failure of individual config values.

Source

Thrown at core/node/core.go:270

		default:
			return nil, err
		}

		// MFS (Mutable File System) provider integration: Only pass the provider
		// to MFS when the strategy includes "mfs". MFS will call StartProviding()
		// on every DAGService.Add() operation, which is sufficient for the "mfs"
		// strategy - it ensures all MFS content gets announced as it's added or
		// modified. For non-mfs strategies, we set provider to nil to avoid
		// unnecessary providing.
		strategyFlag := config.MustParseProvideStrategy(strategy)
		if strategyFlag&config.ProvideStrategyMFS == 0 {
			prov = nil
		}

		// Get configured settings from Import config
		cfg, err := repo.Config()
		if err != nil {
			return nil, fmt.Errorf("failed to get config: %w", err)
		}
		mfsOpts, err := cfg.Import.MFSRootOptions()
		if err != nil {
			return nil, fmt.Errorf("failed to build MFS options from Import config: %w", err)
		}

		// Keep dag here an online (network-backed) DAGService. "ipfs files cp
		// /ipfs/<cid> /path" stores a lazy pointer: only the referenced root is
		// fetched, and its children are pulled from the network on demand when
		// the tree is later traversed ("files ls -l", or "stat"/"read" of a
		// subpath). Do NOT swap in an offline/local-only DAGService to avoid an
		// under-lock bitswap hang, that turns those lazy lookups into "block not
		// found locally" errors. The GC-vs-MFS wedge that tempts that change
		// (ipfs/kubo#10842) is fixed on the GC side instead: MFS mutations hold
		// the pin lock and GC snapshots the MFS root under the GC lock, so live
		// MFS blocks are never collected out from under an in-flight write.
		root, err := mfs.NewRoot(ctx, dag, nd, pf, prov, mfsOpts...)
		if err != nil {

View on GitHub (pinned to 329838acdf)

Solutions

1. Validate the config file: `ipfs config show | jq .` — fix any JSON syntax errors it reports.
2. Check permissions/ownership of `$IPFS_PATH/config` and the repo directory for the daemon's user.
3. Restore config from a backup, or re-create defaults with `ipfs config` commands; keep a copy before hand edits.
4. Ensure only one process manages the repo (no concurrent daemon/writer) and re-run `ipfs daemon`.

Example fix

// before: hand-edited config.json
{"Identity": {"PeerID": "...",}  // trailing comma -> parse error

// after
ipfs config show | jq .   # validate; edit via: ipfs config --json Import.XYZ ...

# Validate the config parses before daemon start
ipfs config show | jq -e . > /dev/null && echo "config OK" || echo "config invalid JSON"

// Programmatic repo usage
if cfg, err := repo.Config(); err != nil {
    return fmt.Errorf("cannot read node config at %s: %w (check JSON syntax and file permissions)", repo.Path(), err)
}

When it happens

Trigger: Daemon startup when `$IPFS_PATH/config` is unreadable (permissions, missing file), contains invalid JSON or is truncated, or the repo's config store returns an I/O error while the Files constructor runs.

Common situations: Hand-editing config.json and leaving a syntax error; running the daemon as a different user without read access; crash mid-write leaving a truncated config; migrating IPFS_PATH across machines with wrong ownership.

Related errors

• failed to build MFS options from Import config: %w
• serveHTTPGateway: GetConfig() failed: %s
• could not read config: %w
• failed to get repo path: %w
• failure to decode config: %w

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