nextcloud/server · error · Sabre\DAV\Exception\NotFound

Node with name $name was not found

Error message

Node with name $name was not found

What it means

Sabre\DAV\Exception\NotFound (HTTP 404) from CalDAV\Principal\User::getChild() when the principal backend cannot resolve <principalURL>/<name> — the requested child of a user principal does not exist as a sub-principal at all. The only valid children in this implementation are calendar-proxy-read and calendar-proxy-write.

Source

Thrown at apps/dav/lib/CalDAV/Principal/User.php:53

			'privilege' => '{DAV:}read',
			'principal' => '{DAV:}authenticated',
			'protected' => true,
		];
		return $acl;
	}

	/**
	 * Returns a specific child node, referenced by its name.
	 *
	 * @param string $name
	 *
	 * @return \Sabre\DAV\INode
	 */
	#[\Override]
	public function getChild($name) {
		$principal = $this->principalBackend->getPrincipalByPath($this->getPrincipalURL() . '/' . $name);
		if (!$principal) {
			throw new \Sabre\DAV\Exception\NotFound("Node with name $name was not found");
		}
		if ($name === 'calendar-proxy-read') {
			return new ProxyRead($this->principalBackend, $this->principalProperties);
		}

		if ($name === 'calendar-proxy-write') {
			return new ProxyWrite($this->principalBackend, $this->principalProperties);
		}

		throw new \Sabre\DAV\Exception\NotFound("Node with name $name was not found");
	}

	/**
	 * Returns an array with all the child nodes.
	 *
	 * @return \Sabre\DAV\INode[]
	 */
	#[\Override]

View on GitHub (pinned to ecdeb153ff)

Solutions

  1. Address only principals/users/<uid>/calendar-proxy-read or principals/users/<uid>/calendar-proxy-write
  2. Enumerate existing children with PROPFIND depth 1 on the user principal and use the returned URIs
  3. If a proxy child unexpectedly 404s, verify proxy configuration and the principal backend data (ProxyMapper)

Example fix

// before: guessing child names under a user principal -> 404
await propfind(`/remote.php/dav/principals/users/${uid}/${name}/`);
// after: address only the supported proxy children
if (!['calendar-proxy-read', 'calendar-proxy-write'].includes(name)) {
  throw new Error(`unsupported principal child: ${name}`);
}
await propfind(`/remote.php/dav/principals/users/${uid}/${name}/`);
Defensive patterns

Strategy: validation

Validate before calling

const PRINCIPAL_CHILDREN = ['calendar-proxy-read', 'calendar-proxy-write'];
function isAddressablePrincipalChild(name) {
  return PRINCIPAL_CHILDREN.includes(name);
}

Type guard

// PHP: enumerate before addressing
$names = array_map(static fn ($n) => $n->getName(), $principal->getChildren());
// only names returned here are valid getChild() arguments

Try / catch

try {
  $node = $principal->getChild($name);
} catch (\Sabre\DAV\Exception\NotFound $e) {
  // unknown principal child: fall back to enumerating getChildren()
}

Prevention

When it happens

Trigger: PROPFIND/GET on /remote.php/dav/principals/users/<uid>/<name> where the backend returns nothing for that sub-principal path — invented child names, misspelled proxy segments, or proxy principals not resolvable in the current configuration.

Common situations: Clients that guess principal child names instead of enumerating; scripts addressing principals/groups/... segments under a user principal; proxy feature disabled or proxy rows missing so even the two valid names fail to resolve.

Related errors


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