ipfs/kubo · error

error while listing remote pins: %v

Error message

error while listing remote pins: %v

What it means

Thrown by pinMFS when listing the node's current remote pins from the configured remote pinning service fails: the error received on lsErrCh after the paginated list finishes (or exits early) is non-nil. pinMFS uses this list to decide whether the MFS root is already pinned remotely; listing failure aborts the whole MFS pin operation. Kubo intentionally blocks on this to avoid duplicate or lost pins.

Source

Thrown at cmd/ipfs/kubo/pinmfs.go:218

	pinStatusMsg := "pinning to %q: received pre-existing %q status for %q (requestid=%q)"
	for ps := range lsPinCh {
		existingRequestID = ps.GetRequestId()
		if ps.GetPin().GetCid() == cid && ps.GetStatus() == pinclient.StatusFailed {
			mfslog.Errorf(pinStatusMsg, svcName, pinclient.StatusFailed, cid, existingRequestID)
		} else {
			mfslog.Debugf(pinStatusMsg, svcName, ps.GetStatus(), ps.GetPin().GetCid(), existingRequestID)
		}
		if ps.GetPin().GetCid() == cid && ps.GetStatus() != pinclient.StatusFailed {
			pinning = true
			pinTime = ps.GetCreated().UTC()
			break
		}
	}
	for range lsPinCh { // in case the prior loop exits early
	}
	err := <-lsErrCh
	if err != nil {
		return lastPin{}, fmt.Errorf("error while listing remote pins: %v", err)
	}

	if !pinning {
		// Prepare Pin.name
		addOpts := []pinclient.AddOption{pinclient.PinOpts.WithName(pinName)}

		// Prepare Pin.origins
		// Add own multiaddrs to the 'origins' array, so Pinning Service can
		// use that as a hint and connect back to us (if possible)
		if node.PeerHost() != nil {
			addrs, err := peer.AddrInfoToP2pAddrs(host.InfoFromHost(node.PeerHost()))
			if err != nil {
				return lastPin{}, err
			}
			addOpts = append(addOpts, pinclient.PinOpts.WithOrigins(addrs...))
		}

		// Create or replace pin for MFS root

View on GitHub (pinned to 329838acdf)

Solutions

1. Verify the pinning service is configured and reachable: `ipfs pin remote service ls` and test credentials with `ipfs pin remote ls --service=<name>`.
2. Fix or rotate the service API key in the config: `ipfs pin remote service add <name> <url> <key>`.
3. Check the service's status/rate limits; wait and retry if it is a 429/5xx.
4. Use `--background=false`/retry after connectivity issues resolve, or temporarily pin via a different service.

Example fix

// before
ipfs pin remote add /ipfs/<cid> --service=pinata   # stale key -> list fails
// after
ipfs pin remote service add pinata https://api.pinata.cloud/psa <NEW_API_KEY>
ipfs pin remote add /ipfs/<cid> --service=pinata

// verify the pinning service before pinning MFS remotely
if _, err := exec.Command("ipfs", "pin", "remote", "ls",
	"--service=myService").Output(); err != nil {
	return fmt.Errorf("pinning service unavailable, fix service/key first: %w", err)
}

if err := pinMFS(ctx, nd, svc, opts); err != nil {
	var pe *ipfs.PinDirError
	if strings.Contains(err.Error(), "listing remote pins") {
		// service-side problem: check key/outage, optionally retry with backoff
		return retryWithBackoff(func() error { return pinMFS(ctx, nd, svc, opts) })
	}
	return err
}

When it happens

Trigger: Remote pinning service (Pinata, web3.storage, etc.) returns an error on the LIST /pins endpoint: invalid or expired service API key, service outage/5xx, rate limiting, network failure, or a service that does not implement the pinning-service API list endpoint.

Common situations: `ipfs pin remote add --service=...` against a service whose credentials were rotated; Pinata rate limits; self-hosted pinning services behind a broken proxy; services implementing only add/status but not full list.

Related errors

• no local swarm address for migration node
• could not connect to migration peer %q: %s
• serveHTTPApi: GetConfig() failed: %s
• serveHTTPApi: socket activation failed: %s
• serveHTTPApi: invalid API address: %q (err: %s)

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