[Bug]: CalDAV free/busy request on user's `outbox` collection always returns `3.7;Could not find principal`

⚠️ This issue respects the following points: ⚠️

• This is a bug, not a question or a configuration/webserver/proxy issue.
• This issue is not already reported on Github OR Nextcloud Community Forum (I've searched it).
• Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
• I agree to follow Nextcloud's Code of Conduct.

Bug description

Coming from downstream
https://gitlab.gnome.org/GNOME/evolution-data-server/-/issues/467

The free/busy requests over CalDAV always return 3.7;Could not find principal, even when asking for the logged in user

Steps to reproduce

Send a request to the server, to the user's scheduling Outbox, which is used for free/busy lookup:

BEGIN:VCALENDAR
PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN
VERSION:2.0
METHOD:REQUEST
BEGIN:VFREEBUSY
UID:5328b732-5010-47b3-8bac-9bb36c2e51b8
DTSTAMP:20250117T114144Z
DTSTART:20250117T070000Z
DTEND:20250202T070000Z
ORGANIZER:mailto:organizer@no.where
ATTENDEE;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT;CUTYPE=INDIVIDUAL:mailt
 o:user@no.where
END:VFREEBUSY
END:VCALENDAR

The server responds:

<?xml version="1.0" encoding="utf-8"?>
<cal:schedule-response xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns" xmlns:cal="urn:ietf:params:xml:ns:caldav" xmlns:cs="http://calendarserver.org/ns/">
  <cal:response>
    <cal:recipient>
      <d:href>mailto:user@no.where</d:href>
    </cal:recipient>
    <cal:request-status>3.7;Could not find principal</cal:request-status>
  </cal:response>
</cal:schedule-response>

regardless the attendee is or is not a legitimate user configured on the server.

Expected behavior

The user is found, and its free/busy information is returned from the server.

It seems searchPrincipals() function is called with principals $prefixPath, which is not known to the function itself. When I add it beside the principals/users case, then it can find the user, but it fails later on. The change looks like:

--- nextcloud/apps/dav/lib/Connector/Sabre/Principal.php.orig	2019-05-15 10:39:32.000000000 -0400
+++ nextcloud/apps/dav/lib/Connector/Sabre/Principal.php	2025-01-17 09:51:10.089227728 -0500
@@ -331,6 +331,7 @@ class Principal implements BackendInterf
 		}
 
 		switch ($prefixPath) {
+			case 'principals':
 			case 'principals/users':
 				return $this->searchUserPrincipals($searchProperties, $test);

More details can be found in the downstream bug.

I do not know how to figure out the exact server version from the web UI, the "About" menu opens some marketing stuff, not a version info like in other apps, thus I cannot tell what precise version this is, I'm sorry, but looking into the latest code the above change is still applicable.

Nextcloud Server version

28

Operating system

None

PHP engine version

None

Web server

None

Database engine version

None

Is this bug present after an update or on a fresh install?

None

Are you using the Nextcloud Server Encryption module?

None

What user-backends are you using?

• Default user-backend (database)
• LDAP/ Active Directory
• SSO - SAML
• Other

Configuration report

List of activated Apps

Nextcloud Signing status

Nextcloud Logs

Additional info

No response

Start in apps/dav/lib/Connector/Sabre/Principal.php at searchPrincipals(), then review the linked downstream Evolution issue for the CalDAV scheduling context. Reproduce a free/busy request against the user's scheduling outbox and trace principal resolution; done when a legitimate user's free/busy information is returned instead of 3.7;Could not find principal.