ipfs/kubo · error

service already present

Error message

service already present

What it means

`ipfs pin remote add` (service registration path) refuses to add a remote pinning service whose name already exists in the node's `Pinning.RemoteServices` config map. Kubo treats service names as unique keys, so re-adding an existing name would silently overwrite its endpoint/key, and this guard prevents that. The check runs after loading the repo config, before the new service is written.

Source

Thrown at core/commands/pin/remotepin.go:510

		if len(req.Arguments) < 3 {
			return fmt.Errorf("expecting three arguments: service name, endpoint and key")
		}

		name := req.Arguments[0]
		endpoint, err := normalizeEndpoint(req.Arguments[1])
		if err != nil {
			return err
		}
		key := req.Arguments[2]

		cfg, err := repo.Config()
		if err != nil {
			return err
		}
		if cfg.Pinning.RemoteServices != nil {
			if _, present := cfg.Pinning.RemoteServices[name]; present {
				return fmt.Errorf("service already present")
			}
		} else {
			cfg.Pinning.RemoteServices = map[string]config.RemotePinningService{}
		}

		cfg.Pinning.RemoteServices[name] = config.RemotePinningService{
			API: config.RemotePinningServiceAPI{
				Endpoint: endpoint,
				Key:      key,
			},
			Policies: config.RemotePinningServicePolicies{},
		}

		return repo.SetConfig(cfg)
	},
}

var rmRemotePinServiceCmd = &cmds.Command{

View on GitHub (pinned to 329838acdf)

Solutions

1. List existing services with `ipfs pin remote ls` (or inspect `Pinning.RemoteServices` in `ipfs config`) and use a different name, or skip adding if present.
2. If you intend to update the endpoint/key, remove the existing service first with `ipfs pin remote rm <name>`, then re-add it.
3. Edit the config directly to update in place: `ipfs config --json Pinning.RemoteServices.<name> '{...}'` (or use `--json` config edits) instead of re-adding.
4. Make automation idempotent: check existence (e.g. `ipfs pin remote ls --json` and grep the name) before calling the add command.

Example fix

// before (script)
ipfs pin remote add web3.storage https://api.web3.storage/pins $KEY
// after (idempotent)
ipfs pin remote ls | grep -q '^web3.storage ' || \
  ipfs pin remote add web3.storage https://api.web3.storage/pins $KEY

#!/usr/bin/env bash
if ipfs pin remote ls 2>/dev/null | grep -q "^${NAME} "; then
  echo "service ${NAME} already registered"
  exit 0
fi
ipfs pin remote add "${NAME}" "${ENDPOINT}" --key="${KEY}"

When it happens

Trigger: Running `ipfs pin remote add --service=web3.storage ...` style service registration (the `pin remote add`/service-add command path) with a `name` argument that already exists under `Pinning.RemoteServices` in the repo config.

Common situations: Re-running an init/setup script or provisioning tool that adds a pinning service on every run without checking first; forgetting the service was already configured; trying to update an existing service's API key or endpoint by re-adding it with the same name.

Related errors

• invalid configuration profile: %s
• cannot add default bootstrap peers: AutoConf is disabled (Au
• cannot remove individual bootstrap peers when using 'auto' p
• cannot set Identity.PeerID to a value that does not match th
• failed to unmarshal json. %s

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