dgraph-io/dgraph · error

only guardians are allowed to drop all data, but the current

Error message

only guardians are allowed to drop all data, but the current user is %s

What it means

In the ACL mutation/query authorization path (authorizePreds caller), a non-guardian user attempting a DropAll (or drop of all DATA) is rejected with this error. Drop-all is reserved for members of the guardians group.

Source

Thrown at edgraph/access.go:708

	// as a byproduct, it also sets the userId, groups variables
	doAuthorizeAlter := func() error {
		userData, err := extractUserAndGroups(ctx)
		if err != nil {
			// We don't follow fail open approach anymore.
			return status.Error(codes.Unauthenticated, err.Error())
		}

		userId = userData.userId
		groupIds = userData.groupIds

		if x.IsSuperAdmin(groupIds) {
			// Members of guardian group are allowed to alter anything.
			return nil
		}

		// if we get here, we know the user is not a guardian.
		if isDropAll(op) || op.DropOp == api.Operation_DATA {
			return errors.Errorf(
				"only guardians are allowed to drop all data, but the current user is %s", userId)
		}

		result := authorizePreds(ctx, userData, preds, acl.Modify)
		if len(result.blocked) > 0 {
			var msg strings.Builder
			for key := range result.blocked {
				x.Check2(msg.WriteString(key))
				x.Check2(msg.WriteString(" "))
			}
			return status.Errorf(codes.PermissionDenied,
				"unauthorized to alter following predicates: %s\n", msg.String())
		}
		return nil
	}

	err := doAuthorizeAlter()
	span := otrace.FromContext(ctx)

View on GitHub (pinned to 759e242be6)

Solutions

  1. Re-authenticate as a user in the 'guardians' group (galaxy) and retry the drop
  2. Add the current user to the guardians group via the ACL API if they legitimately need drop rights
  3. Issue a fresh JWT with a guardian identity (dgraph acl login or auth token endpoint)
  4. Do the drop in a separate connection/session with admin credentials

Example fix

// before: dropping with non-guardian JWT
dg.Alter(ctx, &api.Operation{DropOp: api.Operation_ALL})
// after: login as guardian first
// dgraph acl login -u gagali -p <password> -d <url>  -> obtain JWT for galaxy/guardian
dg = newClientWithGuardianToken()
dg.Alter(ctx, &api.Operation{DropOp: api.Operation_ALL})
Defensive patterns

Strategy: validation

Validate before calling

// Confirm the JWT's user is in guardians before issuing a drop
import { JwtVerify } from 'jose'
const { payload } = await jwtVerify(token, key)
const groups = (payload['https://dgraph.io/jwt/claims'] ?? {}).groups ?? []
if (!groups.includes('guardians')) {
  throw new Error('current user cannot drop all data')
}

Type guard

function isGuardian(claims) {
  const groups = claims?.['https://dgraph.io/jwt/claims']?.groups
  return Array.isArray(groups) && groups.includes('guardians')
}

Try / catch

try {
  await dg.alter({ dropOp: 'ALL' })
} catch (e) {
  if (/only guardians are allowed to drop/.test(e.message)) {
    // re-login with a guardian (galaxy) JWT and retry once
  }
  throw e
}

Prevention

When it happens

Trigger: An authenticated non-guardian user issues an Alter with DropOp (DropAll or DropData) through /alter or the Alter RPC while ACLs are enabled.

Common situations: CI pipelines or scripts running drops with a regular user's JWT instead of the guardian (galaxy) token; forgotten JWT from a previous non-admin login; multi-tenant apps exposing drop to app users.

Related errors


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