nextcloud/server · error · InvalidArgumentException

Unable to fetch principal for user $user

Error message

Unable to fetch principal for user $user 

What it means

InvalidArgumentException from the same command when the user exists but getPrincipalByPath('principals/users/<uid>') returns null — the CalDAV principal record is missing or inconsistent with the user backend. This signals a data inconsistency (partially deleted rows, desynchronized principals table), not an input typo.

Source

Thrown at apps/dav/lib/Command/ClearCalendarUnshares.php:65

	#[\Override]
	protected function configure(): void {
		$this->addArgument(
			'uid',
			InputArgument::REQUIRED,
			'User whose unshares to clear'
		);
	}

	#[\Override]
	protected function execute(InputInterface $input, OutputInterface $output): int {
		$user = (string)$input->getArgument('uid');
		if (!$this->userManager->userExists($user)) {
			throw new \InvalidArgumentException("User $user is unknown");
		}

		$principal = $this->principal->getPrincipalByPath('principals/users/' . $user);
		if ($principal === null) {
			throw new \InvalidArgumentException("Unable to fetch principal for user $user ");
		}

		$shares = $this->mapper->getSharesByPrincipals([$principal['uri']], 'calendar');
		$unshares = array_filter($shares, static fn ($share) => $share['access'] === BackendAlias::ACCESS_UNSHARED);

		if (count($unshares) === 0) {
			$output->writeln("User $user has no calendar unshares");
			return self::SUCCESS;
		}

		$rows = array_map(fn ($share) => $this->formatCalendarUnshare($share), $shares);

		$table = new Table($output);
		$table
			->setHeaders(['Share Id', 'Calendar Id', 'Calendar URI', 'Calendar Name'])
			->setRows($rows)
			->render();

View on GitHub (pinned to ecdeb153ff)

Solutions

  1. Verify the user record with occ user:info <uid>
  2. Inspect the principals table for the row principals/users/<uid> and restore it if missing
  3. Re-trigger principal creation by re-saving the user (change and revert a setting) or re-provisioning via LDAP
  4. Clean up orphaned share rows with occ dav:remove-invalid-shares if the principal cannot be restored

Example fix

# before: user exists but the principal row is gone -> 'Unable to fetch principal'
occ dav:clear-calendar-unshares jdoe
# after: verify and repair the principal first
occ user:info jdoe
# DB check: SELECT * FROM oc_principals WHERE uri = 'principals/users/jdoe';
# restore the row (or re-provision the user), then re-run
occ dav:clear-calendar-unshares jdoe
Defensive patterns

Strategy: validation

Validate before calling

#!/bin/bash
uid="$1"
occ user:info "$uid" >/dev/null 2>&1 || { echo "unknown user: $uid" >&2; exit 1; }
# if the user is fine but this still fails, check principal consistency before retrying:
# SELECT * FROM oc_principals WHERE uri = "principals/users/$uid";

Prevention

When it happens

Trigger: occ dav:clear-calendar-unshares <uid> on a user whose principal entry is absent from the principal backend — e.g. users created directly in the database, LDAP users whose principal row was removed, or a user deleted while share rows still reference their principal.

Common situations: Manual database edits; interrupted user deletion; LDAP reconfiguration that dropped and re-created users; restored backups where oc_principals is out of sync with the user table.

Related errors


AI-assisted analysis of nextcloud/server@ecdeb153ff (2026-08-17). Data as JSON: /api/errors/bb0f6c235b8e4c16. Report an issue: GitHub.