hashicorp/nomad · error

%s with input %q failed with stderr: %s

Error message

%s with input %q failed with stderr: %s

What it means

When the docker credential-helper subprocess (helper like docker-credential-ecr-login) exits non-zero, this error wraps the helper name, the repo string passed on stdin, and the helper's stderr. It means the external credential helper binary itself failed, not the docker daemon.

Source

Thrown at drivers/docker/utils.go:207

func authFromHelper(helperName string) authBackend {
	return func(repo string) (*registrytypes.AuthConfig, error) {
		if helperName == "" {
			return nil, nil
		}
		helper := dockerAuthHelperPrefix + helperName
		cmd := exec.Command(helper, "get")

		repoInfo, err := parseRepositoryInfo(repo)
		if err != nil {
			return nil, err
		}

		cmd.Stdin = strings.NewReader(repoInfo.Index.Name)
		output, err := cmd.Output()
		if err != nil {
			exitErr, ok := err.(*exec.ExitError)
			if ok {
				return nil, fmt.Errorf(
					"%s with input %q failed with stderr: %s", helper, repo, exitErr.Stderr)
			}
			return nil, err
		}

		var response map[string]string
		if err := json.Unmarshal(output, &response); err != nil {
			return nil, err
		}

		auth := &registrytypes.AuthConfig{
			Username: response["Username"],
			Password: response["Secret"],
		}
		if err := encodeAuth(auth); err != nil {
			return nil, err
		}

View on GitHub (pinned to 482b49bf1a)

Solutions

  1. Read the stderr in the error message; fix the underlying helper problem (re-auth with `aws ecr get-login` / `gcloud auth login`, refresh credentials).
  2. Verify the helper binary exists and is executable: run `<helper> get` manually piping the registry URL.
  3. Check ~/.docker/config.json credsStore/credHelpers entries match installed helpers.
  4. Ensure the Nomad client user's environment (PATH, HOME, cloud env vars) exposes the helper and credentials.

Example fix

// before (helper exits 1)
// aws ecr get-authorization-token fails: no credentials
// after: give the Nomad client a working credential chain
export AWS_ACCESS_KEY_ID=... AWS_SECRET_ACCESS_KEY=... AWS_REGION=us-east-1
# or attach an instance profile with ecr:GetAuthorizationToken
Defensive patterns

Strategy: try-catch

Validate before calling

// preflight: ensure the helper is present and credentials work
if _, err := exec.LookPath(helper); err != nil {
  return fmt.Errorf("credential helper %s not installed", helper)
}
if code, _ := exec.Command(helper, "get").ProcessState // or run once with registry input and check exit code; non-zero => fix creds first

Type guard

func isHelperFailure(err error) (*exec.ExitError, bool) {
  var ee *exec.ExitError
  return ee, errors.As(err, &ee)
}

Try / catch

resp, err := fetchCreds(repo)
if err != nil {
  var ee *exec.ExitError
  if errors.As(err, &ee) {
    log.Printf("helper failed: %s", ee.Stderr)
    return nil, fmt.Errorf("credential helper unavailable: %w", err) // do not retry blindly
  }
  return nil, err
}

Prevention

When it happens

Trigger: Running cmd.Output() on a configured credential helper that exits non-zero (exec.ExitError): missing AWS/ECR credentials, expired tokens, helper binary crashing, or a helper not installed for the registry domain.

Common situations: Nomad client with credsStore/credHelpers configured pulling from ECR/GCR without valid cloud credentials (missing AWS_ACCESS_KEY_ID or IAM permissions), stale ~/.docker/config.json pointing at a removed helper, helper not on PATH causing unexpected behavior.

Related errors


AI-assisted analysis of hashicorp/nomad@482b49bf1a (2026-09-04). Data as JSON: /api/errors/3d33f1bacbf0952e. Report an issue: GitHub.