What causes "dynamic workload users disabled" in hashicorp/nomad?

Enable dynamic workload users in the Nomad client configuration if tasks require them

dynamic workload users disabled

Error message

dynamic workload users disabled

What it means

The noopPool's Acquire always returns this error because dynamic workload users are disabled in the configuration. The pool exists only so callers have a working Pool implementation; acquiring a dynamic user is intentionally unsupported.

Source

Thrown at helper/users/dynamic/pool.go:102

	if opts.MaxUGID < opts.MinUGID {
		panic("bug: users pool max must be >= min")
	}
	// a small but reasonable number of tasks to expect
	const defaultPoolCapacity = 32
	return &pool{
		min:  UGID(opts.MinUGID),
		max:  UGID(opts.MaxUGID),
		lock: new(sync.Mutex),
		used: set.New[UGID](defaultPoolCapacity),
	}
}

// noopPool is an implementation of Pool that does not allow acquiring ugids
type noopPool struct{}

func (*noopPool) Restore(UGID) {}
func (*noopPool) Acquire() (UGID, error) {
	return 0, errors.New("dynamic workload users disabled")
}
func (*noopPool) Release(UGID) error {
	// avoid giving an error if a client is restarted with a new config
	// that disables dynamic workload users but still has a task running
	// making use of one
	return nil
}

type pool struct {
	min UGID
	max UGID

	lock *sync.Mutex
	used *set.Set[UGID]
}

func (p *pool) Restore(id UGID) {
	helper.WithLock(p.lock, func() {

View on GitHub (pinned to 482b49bf1a)

Solutions

Enable dynamic workload users in the Nomad client configuration if tasks require them
Check whether the feature is enabled before calling Acquire and use a static user instead
Note that Release on noopPool returns nil by design, so only Acquire needs guarding
Upgrade/downgrade or align agent config across the cluster so client and workload expectations match

Example fix

// before
ugid, err := pool.Acquire()
if err != nil { return err }
// after: check feature enabled first
if !dynamicUsersEnabled {
  return useStaticUser()
}
ugid, err := pool.Acquire()

Defensive patterns

Strategy: try-catch

Validate before calling

if !dynamicUsersEnabled {
  return useStaticOrFallbackUser()
}

Try / catch

ugid, err := pool.Acquire()
if err != nil && strings.Contains(err.Error(), "dynamic workload users disabled") {
  // feature off; fall back to default/static user
  return fallback()
}

Prevention

Confirm the client config enables dynamic workload users before scheduling tasks needing them
Keep client configs consistent across the cluster
Check the feature flag before calling any Pool method other than Release (Release is a safe no-op)
Document that disabling the feature invalidates in-flight dynamic users

When it happens

Trigger: Calling Acquire() on the pool obtained when dynamic workload users are disabled in the Nomad client configuration; any code path that assumes a functional pool while the feature flag is off.

Common situations: Operator disabled dynamic workload users in client config while workloads still request dynamic users; driver/task code unconditionally calling Acquire without checking whether the feature is enabled.

Related errors

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