theonedev/onedev · error · DisabledAccountException

Account is disabled

Error message

Account is disabled

What it means

DefaultAccessTokenService wraps every access-token lookup with checkDisabled: after finding the token by value it checks whether the owning user is disabled and rejects the token with DisabledAccountException('Account is disabled'). Disabled users' access tokens are therefore non-functional, even if the token value itself is valid.

Source

Thrown at server-core/src/main/java/io/onedev/server/service/impl/DefaultAccessTokenService.java:72

    }

	@Sessional
	@Override
	public AccessToken findByOwnerAndName(User owner, String name) {
		if (cache != null) {
			var facade = cache.findByOwnerAndName(owner.getId(), name);
			if (facade != null) 
				return load(facade.getId());
			else 
				return null;
		} else {
			throw new ServerNotReadyException();
		}
	}

	private AccessToken checkDisabled(AccessToken accessToken) {
		if (accessToken.getOwner().isDisabled())
			throw new DisabledAccountException("Account is disabled");
		return accessToken;
	}

    @Override
    public final AccessToken findByValue(String value) {
		return sessionService.call(new Callable<AccessToken>() {

			@Override
			public AccessToken call() throws Exception {
				if (cache != null) {
					var facade = cache.findByValue(value);
					if (facade != null) {
						return checkDisabled(load(facade.getId()));
					} else {
						Long userId = temporalAccessTokens.get(value);
						if (userId != null) {
							var accessToken = new AccessToken();
							accessToken.setOwner(userService.load(userId));

View on GitHub (pinned to d44925c47c)

Solutions

  1. Re-enable the owning user in Administration -> Users if the token should keep working.
  2. Issue a new access token from an enabled account and update the CI/script credentials.
  3. If disabling was intentional, migrate automation to a dedicated enabled service account's token.
  4. Verify which user owns the token (token page shows owner) to avoid confusion with similarly named accounts.

Example fix

// before: pipeline uses token of disabled user 'jdoe'
git clone http://jdoe-token@git.onedev/project.git  # Account is disabled
// after: create token under enabled service account and update CI secret
git clone http://svc-token@git.onedev/project.git
Defensive patterns

Strategy: try-catch

Validate before calling

// Before using a token, confirm its owner is enabled (admin API):
User owner = accessTokenService.findOwnerByValue(token);
if (owner != null && owner.isDisabled()) { rotateToken(); }

Type guard

function tokenUsable(token, owner) { return token != null && owner != null && !owner.isDisabled(); }

Try / catch

try {
  callApiWithToken(token);
} catch (DisabledAccountException e) {
  if (e.getMessage().equals("Account is disabled")) {
    rotateToServiceAccountToken();
  }
}

Prevention

When it happens

Trigger: Any REST/SSH/git API call authenticated with an access token whose owner (user) is disabled; thrown via checkDisabled from findByValue-based token authentication.

Common situations: CI pipelines using a personal access token of an employee who was disabled during offboarding; service scripts using a token from a suspended account; integrations breaking after an admin deactivates a user.

Related errors


AI-assisted analysis of theonedev/onedev@d44925c47c (2026-09-06). Data as JSON: /api/errors/e6645e068dc6a2e4. Report an issue: GitHub.