After upgrading to Nextcloud v34.0.1.2 (running in a Docker setup with MariaDB and Redis), accessing the Personal Settings (/settings/user/personal-info) results in a persistent HTTP 500 Internal Server Error. The instance was previously migrated/upgraded across several major versions and from bare metal into a compose setup using traefik. I don’t know if the error was present immediately after migration, the rest of the instance works without issue.
Log Exception:
{
"app": "index",
"method": "GET",
"url": "/index.php/settings/user/personal-info",
"message": "FederatedUser is not complete",
"version": "34.0.1.2",
"exception": {
"Exception": "OCA\\Circles\\Exceptions\\FederatedUserException",
"Message": "FederatedUser is not complete",
"Code": 500,
"Trace": [
{
"file": "/var/www/html/apps/circles/lib/Service/FederatedUserService.php",
"line": 291,
"function": "confirmFederatedUser",
"class": "OCA\\Circles\\Service\\FederatedUserService",
"type": "->"
},
{
"file": "/var/www/html/apps/circles/lib/CirclesManager.php",
"line": 161,
"function": "setCurrentUser",
"class": "OCA\\Circles\\Service\\FederatedUserService",
"type": "->"
},
{
"file": "/var/www/html/lib/private/Teams/TeamManager.php",
"line": 184,
"function": "startSession",
"class": "OCA\\Circles\\CirclesManager",
"type": "->"
}
],
"File": "/var/www/html/apps/circles/lib/Service/FederatedUserService.php",
"Line": 1124
}
}
Seems like the core TeamManager triggers the Circles app to initialize a session for the local user via startSession. Inside FederatedUserService.php -> confirmFederatedUser(), the validation fails because the generated FederatedUser model for the local account is deemed incomplete by the code.
What I have already tried:
- App Config Reset: Checked and restricted
circlesapp-config (type_federatedto0,refresh_rateto0). - Database Cleanup: Checked
oc_circles_memberand dropped old database leftovers/orphaned rows from a previous domain/old federation layout. - Maintenance Repair: Executed
php occ maintenance:repairandphp occ dav:sync-system-addressbook. - Cache Clears: Flushed the Redis cache (
redis-cli FLUSHALL) completely. - Workaround: Disabling the
circlesapp viaocc app:disable circlesimmediately restores access to the settings page, confirming that the Circles integration is the bottleneck.
Loopback Behavior
External connectivity from inside the container works flawlessly:
# docker exec -it nextcloud-app curl -I [https://nextcloud.example.com](https://nextcloud.example.com)
HTTP/2 302
server: Apache/2.4.68 (Debian)
location: [https://nextcloud.example.com/index.php/login](https://nextcloud.example.com/index.php/login)
However, running the interactive circles:check command reveals that the Circles app fails to verify its own internal endpoints:
# docker exec --user www-data -it nextcloud-app php occ circles:check
### Checking loopback address.
. The loopback setting is mandatory and can be checked locally.
. The address you need to define here must be a reachable url of your Nextcloud from the hosting server itself.
. By default, the App will use the entry 'overwrite.cli.url' from 'config/config.php'.
* testing current address: https://
- You do not have a valid loopback address setup right now.
Please write down a new loopback address to test: http://nextcloud-app
* testing address: http://nextcloud-app
- GET request on http://nextcloud-app/csrftoken: 404
Using the container name (http://nextcloud-app) results in an HTTP 404 on the /csrftoken endpoint. Testing via https://mytraefikdomain also throws a 404.
I guess its possible that the FederatedUser is not complete exception stems directly from Circles being unable to perform this mandatory self-test or token verification on its own API routes but I am at this point clueless as to how I could fix that.