Can't set <dgraph.rule.permission> to %d, Value for this pre

Error message

Can't set <dgraph.rule.permission> to %d, Value for this predicate should be between 0 and 7

What it means

The dgraph.rule.permission predicate (only checked when ACLs are enabled) holds a 3-bit permission bitmask, so its value must be between 0 and 7 inclusive. ValidateAndConvert rejects out-of-range integers to prevent writing meaningless or unsafe permission masks.

Source

Thrown at worker/mutation.go:580

	// check compatibility of schema type and storage type
	// The goal is to convert value on edge to value type defined by schema.
	if dst, err = types.Convert(src, schemaType); err != nil {
		return err
	}

	// convert to schema type
	b := types.ValueForType(types.BinaryID)
	if err = types.Marshal(dst, &b); err != nil {
		return err
	}

	if x.WorkerConfig.AclEnabled && x.ParseAttr(edge.GetAttr()) == "dgraph.rule.permission" {
		perm, ok := dst.Value.(int64)
		if !ok {
			return errors.Errorf("Value for predicate <dgraph.rule.permission> should be of type int")
		}
		if perm < 0 || perm > 7 {
			return errors.Errorf("Can't set <dgraph.rule.permission> to %d, Value for this"+
				" predicate should be between 0 and 7", perm)
		}
	}

	// TODO: Figure out why this is Enum. It really seems like an odd choice -- rather than
	//       specifying it as the same type as presented in su.
	edge.ValueType = schemaType.Enum()
	var ok bool
	edge.Value, ok = b.Value.([]byte)
	if !ok {
		return errors.Errorf("failure to convert edge type: '%+v' to schema type: '%+v'",
			storageType, schemaType)
	}

	return nil
}

// AssignNsIdsOverNetwork sends a request to assign Namespace IDs to the current zero leader.

View on GitHub (pinned to 759e242be6)

Solutions

Set the value to a valid mask in 0..7 (e.g. 7 = all permissions; 4 = read-only).
Compute the mask with bitwise OR of READ(4), WRITE(2), MODIFY(1) instead of arbitrary numbers.
Fix the automation that produced the out-of-range number and clamp/validate before submitting.

Example fix

// before (fails)
{"set":[{"uid":"0x1","dgraph.rule.permission":100}]}

// after (read|write|modify)
{"set":[{"uid":"0x1","dgraph.rule.permission":7}]}

Defensive patterns

Strategy: validation

Validate before calling

const READ = 4, WRITE = 2, MODIFY = 1
function toPermissionMask({read, write, modify}) {
  const perm = (read ? READ : 0) | (write ? WRITE : 0) | (modify ? MODIFY : 0)
  if (perm < 0 || perm > 7) throw new RangeError(`permission mask ${perm} out of range 0..7`)
  return perm
}

Try / catch

try {
  await aclClient.modifyPermissions(rule)
} catch (e) {
  if (String(e).includes('between 0 and 7')) {
    // clamp/recompute the mask from read/write/modify flags and retry
  }
}

Prevention

Build masks from booleans via bitwise OR (4|2|1), never from raw numbers.
Clamp or assert 0 <= perm <= 7 before submitting any ACL mutation.
Document the bit layout (read=4, write=2, modify=1) wherever permissions are configured.

When it happens

Trigger: A mutation sets dgraph.rule.permission to an int64 outside 0..7, e.g. 8, -1, or a full 0xFF mask, typically from combining permission bits incorrectly or using a decimal read/write value like 100.

Common situations: Scripts computing permissions as sums that exceed 7; using percentages or byte masks from other systems; misunderstanding the bit layout (read=4, write=2, modify=1).

Related errors

AI-assisted analysis of dgraph-io/dgraph@759e242be6 (2026-09-01). Data as JSON: /api/errors/6a1c8fe4ca8d7ff5. Report an issue: GitHub.