What causes "path '%s' is not pinned" in ipfs/kubo?

Use `ipfs pin ls --type=all ` to check any pin kind, or drop the type filter.

path '%s' is not pinned

Error message

path '%s' is not pinned

What it means

When `ipfs pin ls` is called with explicit path/CID arguments, the command resolves each argument's pin status via `pinLsKeys`. If any returned result reports the item as not pinned (`!p.Pinned()`), the command fails with this error naming the offending path — pin ls on an explicit argument is strict rather than silently omitting it.

Source

Thrown at core/commands/pin/pin.go:620

		rp, _, err := api.ResolvePath(req.Context, p)
		if err != nil {
			return err
		}

		cids = append(cids, rp.RootCid())
	}

	// Check pins using the new type-specific method
	pinned, err := pinner.CheckIfPinnedWithType(req.Context, mode, displayNames, cids...)
	if err != nil {
		return err
	}

	// Process results
	for i, p := range pinned {
		if !p.Pinned() {
			return fmt.Errorf("path '%s' is not pinned", req.Arguments[i])
		}

		pinType, _ := pin.ModeToString(p.Mode)
		if p.Mode == pin.Indirect && p.Via.Defined() {
			pinType = "indirect through " + enc.Encode(p.Via)
		}

		err = emit(PinLsOutputWrapper{
			PinLsObject: PinLsObject{
				Type: pinType,
				Cid:  enc.Encode(cids[i]),
				Name: p.Name,
			},
		})
		if err != nil {
			return err
		}
	}

View on GitHub (pinned to 329838acdf)

Solutions

Use `ipfs pin ls --type=all <cid>` to check any pin kind, or drop the type filter.
Use `ipfs pin ls` without arguments and grep for the CID to avoid the hard failure.
Treat the command's error exit as 'not pinned' in scripts, or use `ipfs pin ls <cid> || echo not-pinned`.
If the pin was expected, re-add it with `ipfs pin add <cid>`.

Example fix

// before
out, err := exec.Command("ipfs", "pin", "ls", cid).Output()
// after
out, err := exec.Command("ipfs", "pin", "ls", "--type=all", cid).Output()
if err != nil { isPinned = false }

Defensive patterns

Strategy: try-catch

Try / catch

out, err := exec.Command("ipfs", "pin", "ls", "--type=all", cid).Output()
if err != nil {
    if strings.Contains(err.Error(), "is not pinned") {
        isPinned = false // treat as a status, not a crash
    } else { return err }
}

Prevention

Query with --type=all to avoid filter-caused false negatives
Use argument-less `ipfs pin ls` + grep for soft existence checks
Re-add pins with `ipfs pin add` before scripts that assume presence

When it happens

Trigger: `ipfs pin ls <cid>` (or `--type=<t> <cid>`) where the CID exists on the node but is not pinned, or is pinned only in a way filtered out by the requested type filter; also direct RPC `pin/ls` calls with such arguments.

Common situations: Checking whether a CID is pinned by running `ipfs pin ls <cid>` and treating exit failure as 'not pinned'; stale scripts referencing unpinned CIDs after a GC; querying with a type filter that excludes the actual pin mode (e.g. `--type=direct` on a recursively pinned CID).

Related errors

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