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

[mcrha]

⚠️ 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:[email protected]
ATTENDEE;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT;CUTYPE=INDIVIDUAL:mailt
 o:[email protected]
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:[email protected]</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

[kesselb]

cc @SebastianKrupinski @st3iny @tcitworld

[st3iny]

Hi, thanks for the report.

Does a user with the email [email protected] exist on the server? Is this email address the primary email address of the user? Please have a look a the personal settings of the user.

EDIT: Correct the email address.

[mcrha]

I changed the address for privacy reason in the description. It fails also for the user itself, the one being logged in. It's the only email address the user has set, thus might be the primary.

If you re-read the description, you'll see there is a block with a patch there - the function the patch touches never tries to search for the user, due to the parameter being different than expected. If I correct it (apply the patch), it fails later on, which was beyond my abilities to investigate it further.

Maybe for easier testing, the client runs this query over https::

POST /remote.php/dav/calendars/mcrha/outbox/ HTTP/1.1
Content-Type: text/calendar; charset="utf-8"

BEGIN:VCALENDAR
CALSCALE:GREGORIAN
PRODID:-//Ximian//NONSGML Evolution Calendar//EN
VERSION:2.0
METHOD:REQUEST
BEGIN:VFREEBUSY
UID:fa2566720b5589ed27115df0ec3b16dfaf098b61
DTSTAMP:20250203T164701Z
DTSTART:20250126T230000Z
DTEND:20250302T230000Z
ORGANIZER:mailto:mcrha
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=CHAIR;PARTSTAT=NEEDS-ACTION;RSVP=FALSE:mailto:[email protected]
END:VFREEBUSY
END:VCALENDAR

and the server responds:

HTTP/1.1 403 Forbidden
Content-Type: application/xml; charset=utf-8
Server: nginx

<?xml version="1.0" encoding="utf-8"?>
<d:error xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns">
	<s:exception>Internal Server Error</s:exception>
	<s:message>
		The server was unable to complete your request.		If this happens again, please send the technical details below to the server administrator.		More details can be found in the server log.			</s:message>

	<s:technical-details>
		<s:remote-address>0.0.0.0</s:remote-address>
		<s:request-id>aGIOMI3gtGtnUmzi6iL3</s:request-id>

		</s:technical-details>

[mcrha]

Okay, I see the response is slightly different than in the description. It's what I get when I apply the patch. I re-tried with a newer Nexcloud (but I do not know where to find the exact version; if you tell me where it is in the web interface, then I can paste it here), which might have the part with the patch changed already or something, I cannot tell for sure, because I do not have access to the server itself. The line is 401 for the patch at the moment, inside the searchPrincipals() function.

I verified the logged-in user's email address is the one I used in the ATTENDEE property of the component, thus there's everything as it should be.