cap_drop configured with capabilities not supported by syste

Error message

cap_drop configured with capabilities not supported by system: %s

What it means

TaskConfig.validate() also validates cap_drop against the same supported set; a cap_drop entry naming a capability the host doesn't recognize fails validation, because the driver cannot guarantee consistent drop semantics across hosts.

Source

Thrown at drivers/exec/driver.go:240

	default:
		return fmt.Errorf("pid_mode must be %q or %q, got %q", executor.IsolationModePrivate, executor.IsolationModeHost, tc.ModePID)
	}

	switch tc.ModeIPC {
	case "", executor.IsolationModePrivate, executor.IsolationModeHost:
	default:
		return fmt.Errorf("ipc_mode must be %q or %q, got %q", executor.IsolationModePrivate, executor.IsolationModeHost, tc.ModeIPC)
	}

	supported := capabilities.Supported()
	badAdds := supported.Difference(capabilities.New(tc.CapAdd))
	if !badAdds.Empty() {
		return fmt.Errorf("cap_add configured with capabilities not supported by system: %s", badAdds)
	}

	badDrops := supported.Difference(capabilities.New(tc.CapDrop))
	if !badDrops.Empty() {
		return fmt.Errorf("cap_drop configured with capabilities not supported by system: %s", badDrops)
	}

	if tc.WorkDir != "" && !filepath.IsAbs(tc.WorkDir) {
		return fmt.Errorf("work_dir must be absolute but got relative path %q", tc.WorkDir)
	}

	return nil
}

// TaskState is the state which is encoded in the handle returned in
// StartTask. This information is needed to rebuild the task state and handler
// during recovery.
type TaskState struct {
	ReattachConfig *pstructs.ReattachConfig
	TaskConfig     *drivers.TaskConfig
	Pid            int
	StartedAt      time.Time
}

View on GitHub (pinned to 482b49bf1a)

Solutions

Remove or fix the offending cap_drop entry per the error message
Align drop lists with capabilities.Supported()
Keep drop lists minimal to reduce typo risk

Example fix

// before
config {
  cap_drop = ["CAP_SETFCAP_TYPO"]
}
// after
config {
  cap_drop = ["CAP_SETFCAP"]
}

Defensive patterns

Strategy: validation

Validate before calling

for _, c := range tc.CapDrop {
  if !hostSupportedCaps[c] {
    return fmt.Errorf("cap_drop unsupported: %s", c)
  }
}

Type guard

func dropsSupported(drops []string) bool {
  return capabilities.Supported().Difference(capabilities.New(drops)).Empty()
}

Try / catch

if err := task.Validate(); err != nil {
  if strings.Contains(err.Error(), "cap_drop") {
    cfg.CapDrop = nil
  }
  return err
}

Prevention

Derive drop lists from capabilities.Supported() rather than hand-writing
Lint job templates for capability name typos
Keep hardening lists minimal and reviewed

When it happens

Trigger: Task config cap_drop containing a capability string absent from capabilities.Supported() (typo, wrong prefix, kernel lacking the capability).

Common situations: Hardening templates with long drop lists copied from Docker docs including unsupported names; typos like "CAP_MKNOD" misspelled; cross-version kernel differences.

Related errors

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