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 := ®istrytypes.AuthConfig{
Username: response["Username"],
Password: response["Secret"],
}
if err := encodeAuth(auth); err != nil {
return nil, err
}
View on GitHub (pinned to 482b49bf1a)
Solutions
- Read the stderr in the error message; fix the underlying helper problem (re-auth with `aws ecr get-login` / `gcloud auth login`, refresh credentials).
- Verify the helper binary exists and is executable: run `<helper> get` manually piping the registry URL.
- Check ~/.docker/config.json credsStore/credHelpers entries match installed helpers.
- 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
- Keep cloud credentials (AWS/GCR) fresh on Nomad clients via instance profiles/workload identity.
- Pin helper binaries on PATH for the nomad user, not just root.
- Reconcile ~/.docker/config.json credsStore/credHelpers with installed helpers during provisioning.
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
- error encoding basic auth: %v
- running container as ContainerAdmin is unsafe; change the co
- error decoding stats data: no reader body
- error decoding stats data: stats were nil
- does not match registry specification
AI-assisted analysis of hashicorp/nomad@482b49bf1a (2026-09-04).
Data as JSON: /api/errors/3d33f1bacbf0952e.
Report an issue: GitHub.