hashicorp/nomad · error
running as gid %d is disallowed
Error message
running as gid %d is disallowed
What it means
HasValidIDs checks each of the user's group IDs against the deniedGIDs set configured on the client. This error means at least one of the task user's groups (primary or supplementary) falls in a forbidden GID range, blocking the task as a security measure against privileged group membership (e.g. docker, sudo, disk groups).
Source
Thrown at drivers/shared/validators/validators.go:93
uid, err := getUserID(user)
if err != nil {
return fmt.Errorf("validator: %w", err)
}
// check uids
if v.deniedUIDs.Contains(uid) {
return fmt.Errorf("running as uid %d is disallowed", uid)
}
gids, err := getGroupsID(user)
if err != nil {
return fmt.Errorf("validator: %w", err)
}
// check gids
for _, gid := range gids {
if v.deniedGIDs.Contains(gid) {
return fmt.Errorf("running as gid %d is disallowed", gid)
}
}
return nil
}
// validateIDRange is used to ensure that the configuration for ID ranges is valid
// by checking the syntax and bounds.
func validateIDRange(rangeType string, deniedRanges string) error {
parts := strings.Split(deniedRanges, ",")
// exit early if empty string
if len(parts) == 1 && parts[0] == "" {
return nil
}
for _, rangeStr := range parts {View on GitHub (pinned to 482b49bf1a)
Solutions
- Remove the user from the denied group (gpasswd -d <user> <group> or edit group membership)
- Create a dedicated task user with membership only in benign groups
- If membership is required, ask the operator to adjust the denied_host_gids policy
- Check supplementary groups with id <user> to identify which GID triggered the denial
Example fix
// before: task user in docker group (denied gid 999) // usermod -aG docker taskuser // after: remove from denied group // gpasswd -d taskuser docker
Defensive patterns
Strategy: validation
Validate before calling
u, err := user.Lookup(userName)
if err != nil { return err }
for _, gidStr := range mustGroupIds(u) {
gid, _ := strconv.Atoi(gidStr)
if deniedGIDs.Contains(gid) {
return fmt.Errorf("user %q is in denied group (gid %d); remove membership", userName, gid)
}
} Prevention
- Run tasks under dedicated users with no sensitive group memberships (docker, sudo, wheel)
- Audit group membership whenever users are modified on client hosts
- Document denied_host_gids ranges for job authors
- Check id <user> output before onboarding a user for task workloads
When it happens
Trigger: A task runs as a user who is a member of a protected group (e.g. gid 0/root, docker, sudo, video) while the client config specifies denied_host_gids ranges; validation happens at task start on the client.
Common situations: User added to a sensitive group (docker/wheel) for other purposes, then denied for Nomad tasks; job migrated to a cluster with stricter GID policy; LDAP group membership expanding the user's groups beyond local ones.
Related errors
- running as uid %d is disallowed
- Invalid policy: %s
- running as user %q is disallowed
- failed to identify user %q: %w
- validator: %w
AI-assisted analysis of hashicorp/nomad@482b49bf1a (2026-09-04).
Data as JSON: /api/errors/466b71615855b090.
Report an issue: GitHub.