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
- Verify the user record with occ user:info <uid>
- Inspect the principals table for the row principals/users/<uid> and restore it if missing
- Re-trigger principal creation by re-saving the user (change and revert a setting) or re-provisioning via LDAP
- 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
- Monitor principal/user table consistency after LDAP changes and restores
- Avoid creating users by direct DB inserts
- Keep occ dav:remove-invalid-shares in maintenance toolbox for orphaned shares
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
- User $user is unknown
- User $user has no calendar subscription with the URI $uri
- User <$user> is unknown.
- User $user is unknown
- Unable to fetch principal for user $user
AI-assisted analysis of nextcloud/server@ecdeb153ff (2026-08-17).
Data as JSON: /api/errors/bb0f6c235b8e4c16.
Report an issue: GitHub.