I am experiencing this as well. I posted to the Users list in August.

Here is what I found:

I turned on these debug flags: GCSFolderDebugEnabled
GCSFolderStoreDebugEnabled
SOGoDebugRequests
SoDebugObjectTraversal
SoSecurityManagerDebugEnabled
LDAPDebugEnabled

Deleted the account from two machines (Big Sur and Catalina) and re-added them while watching the logs.

Parsing these logs is difficult for me because I have other machines hitting this server and the IP address is not logged on every line, so there appears to be some logging that interleaves messages from multiple sessions.

That said, what it looks like to me is that the Big Sur machine may not be properly passing credentials?

When I created the account on the Big Sur machine, I see a PROPFIND on the account, and then a traverse miss blamed on SoAuthRequiredException. Subsequent requests only ask for Contacts/global_addressbook.

On the Catalina machine when I recreate the account, the PROPFIND on the account and traverse doesn’t generate a miss error, and subsequent requests ask for Contacts/global_addressbook and Contacts/personal.

==

I have logged this via the Big Sur Feedback Assistant to Apple, but they closed it with "Resolution: Investigation complete - Unable to diagnose with current information."

Same issue, Server 4.3.2

same problem here :-(

Because Big Sur is now released, it becomes a big issue. How can I edit my entry?

I'm afraid, there is no way to edit the access string.
Access works fine on IOS 14.2 but not on 11.0.1.
This issue needs to be fixed by Apple (it was the only thing that changed)

Because Apple has closed my ticket with "Resolution: Investigation complete - Unable to diagnose with current information." it leads me to believe that my logs were not detailed enough, and that there were not enough similar reports that they allocated any engineering time to fix it. I imagine the cross section of macOS users who connect to the CardDAV feed of a SOGo instance, and who also trialed the beta of Big Sur is a fairly small number.

Are there any SOGo devs who use MacOS devices and are also members of the Apple Developer Program, who might be able to log a bug with Apple and provide better logging info? Anyone else on this thread who can, please use the Feedback Assistant to file a ticket with Apple.

As the admin of a SOGo instance and the support person for many Apple devices within my small business, this puts me in a difficult position. My users can't update to the new OS, and I can't figure out a way to make Apple care that their application is broken.

This issue needs to be fixed by Apple (it was the only thing that changed)

Yes, it looks like. But it depends. Need to be checked if the cause of this problem is related to the CardDAV RFC and if the RFC says 'may' or 'must'.

I have filed a bug report with Apple yesterday (3 attempts because the logs were big).
Apple required their own system information and sysdiagnostic logs.

Not sure if that is sufficient

Looks like Big Sur never do:
propfind /sogo/dav/user/contacts/personal

But:
propfind /sogo/dav/user/contacts/directory
... 3 times!

Who is responsible for a:
propfind /sogo/dav/user/contacts/personal

Client or Server?

I have now SOGo debugging enabled. First stuff is identical, but this is different:

Catalina:
Nov 30 23:14:33 sogod [19]: 1.1.1.1 "PROPFIND /SOGo/dav/user/Contacts/directory/ HTTP/1.1" 207 500/782 0.016 1363
Nov 30 23:14:34 sogod [19]: |SOGo| starting method 'REPORT' on uri '/SOGo/dav/user/Contacts/personal/'
Nov 30 23:14:34 sogod [19]: |SOGo| request took 0.016037 seconds to execute
Nov 30 23:14:34 sogod [19]: 1.1.1.1 "REPORT /SOGo/dav/user/Contacts/personal/ HTTP/1.1" 207 125/210 0.019 - - 0 -

Catalina stops.

Big Sur:
Nov 30 23:10:54 sogod [19]: 1.1.1.1 "PROPFIND /SOGo/dav/user/Contacts/directory/ HTTP/1.1" 207 500/782 0.014 1363
Nov 30 23:10:54 sogod [19]: |SOGo| starting method 'PROPFIND' on uri '/SOGo/dav/user/Contacts/directory/'
Nov 30 23:10:54 sogod [19]: [obj-dav-dispatch] constructed root-url:
Nov 30 23:10:54 sogod [19]: |SOGo| constructed root-url: /SOGo/

Big Sur feels like it's in a "directory" loop, because there are many more of this PROPFIND /directory requests.

I've replaced my public IP with 1.1.1.1 and my username with user.

It works. SOGo devs can fix it.

I found that Big Sur get a different XML file right before requests/reponses becomes different between Catalina and Big Sur.

When adding this line to my SOGo's Apache configuration, it works:
RequestHeader set User-Agent "Mac OS X/10.15.7 (19H15) AddressBookCore/1"

Is it possible rewrite the user-agent in Apache if it's anything like:
"macOS/11.1 (20C5048k) AddressBookCore/2452.2"

As a workaround? Thanks

Good find. This probably needs to be fixed in https://github.com/inverse-inc/sogo/blob/master/SoObjects/SOGo/WORequest+SOGo.m, for which I have attached an (untested) patch.

--- WORequest+SOGo copy.m	2020-12-01 18:23:14.000000000 +0100
+++ WORequest+SOGo.m	2020-12-01 18:25:06.000000000 +0100
@@ -127,6 +127,7 @@
 
 //
 // Mac+OS+X/10.10.1 (14B25) CalendarAgent/315
+// macOS/11.0.1 (20B50) CalendarAgent/954
 //
 - (BOOL) isICal
 {
@@ -137,6 +138,7 @@
   return ([self isAppleDAVWithSubstring: @"Mac OS X/10."]
           || [self isAppleDAVWithSubstring: @"Mac_OS_X/"]
           || [self isAppleDAVWithSubstring: @"Mac+OS+X/"]
+          || [self isAppleDAVWithSubstring: @"macOS/"]
           || [self isAppleDAVWithSubstring: @"CoreDAV/"]
           || [[cc userAgent] rangeOfString: @"DAVx5"].location != NSNotFound);
 }
@@ -147,6 +149,7 @@
 // Mac OS X/10.8 (12A269) Calendar/1639
 // Mac OS X/10.8 (12A269) CalendarAgent/47
 // Mac OS X/10.8.1 (12B19) CalendarAgent/47
+// macOS/11.0.1 (20B50) CalendarAgent/954
 //
 - (BOOL) isICal4
 {
@@ -175,6 +178,10 @@
 // Mac OS X/10.8.1 (12B19) AddressBook/1143
 // Mac OS X/10.8.2 (12C60) AddressBook/1167
 //
+// For 11.0, we see:
+//
+// macOS/11.0.1 (20B50) AddressBookCore/2452
+//
 - (BOOL) isMacOSXAddressBookApp
 {
   WEClientCapabilities *cc;
@@ -197,6 +204,11 @@
           [[cc userAgent] rangeOfString: @"Mac OS X"].location != NSNotFound
           && [[cc userAgent] rangeOfString: @"AddressBook"].location != NSNotFound
         )
+        ||
+        (
+          [[cc userAgent] rangeOfString: @"macOS"].location != NSNotFound
+          && [[cc userAgent] rangeOfString: @"AddressBook"].location != NSNotFound
+        )
       );
 
   return b;

Now I have a workaround. Because I'm private, I want to upgrade to macOS 11 asap and this was the only showstopper ;-)

On top of the Alias line in Apache, I set following:

SetEnvIf User-Agent "macOS/11.*" value macOS11
RequestHeader set User-Agent "Mac OS X/10.15.7 (19H15) AddressBookCore/1" env=macOS11

Alias /SOGo.woa/WebServerResources/ /usr/local/lib/GNUstep/SOGo/WebServerResources/

Access from any other client works as usual with his user-agent and I guess, this should also fix an older version of SOGo with Big Sur.