Class OCA\Settings\Controller\AppSettingsController\ does not exist

ℹ️ Support
, ,
1

The Basics

  • Nextcloud Server version (e.g., 29.x.x):
    • 34.0.2
  • Operating system and version (e.g., Ubuntu 24.04):
    • FreeBSD 15.1
  • Web server and version (e.g, Apache 2.4.25):
    • nginx 1.30.4,3
  • Reverse proxy and version _(e.g. nginx 1.27.2)
    • caddy 2.0.2_2 on OPNsense
  • PHP version (e.g, 8.3):
    • 8.5
  • Is this the first time you’ve seen this error? (Yes / No):
    • yes
  • When did this problem seem to first start?
    • after upgrading from 33->34
  • Installation method (e.g. AlO, NCP, Bare Metal/Archive, etc.)
    • Freebsd pkg
  • Are you using CloudfIare, mod_security, or similar? (Yes / No)
    • no

Summary of the issue you are facing:

I had v32 installed, did a manual install of the latest v33, which went fine, the UI was loading and everything looked ok. Then I did the pkg install to v34.0.2, ran occ upgrade which completed without issue but when I try to load the UI, I get “Internal Server Error” and checking the log has this that seems relevant "message":"Class "OCA\Settings\Controller\AppSettingsController" does not exist", but I have no clue what to do with that information and can’t seem to find anything about it.

Log entries

Nextcloud

Full error from the log file when refreshing the page:

{"reqId":"wwZbWzhmPlq23vWU67NI","level":3,"time":"2026-07-26T18:24:45+00:00","remoteAddr":"192.168.1.1","user":"SamKook","app":"index","method":"GET","url":"/index.php/apps/files/preview-service-worker.js","scriptName":"/index.php","message":"Class \"OCA\\Settings\\Controller\\AppSettingsController\" does not exist","userAgent":"Mozilla/5.0 (X11; Linux x86_64; rv:153.0) Gecko/20100101 Firefox/153.0","version":"34.0.2.1","exception":{"Exception":"ReflectionException","Message":"Class \"OCA\\Settings\\Controller\\AppSettingsController\" does not exist","Code":-1,"Trace":[{"file":"/usr/local/www/nextcloud/lib/private/Route/Router.php","line":499,"function":"__construct","class":"ReflectionClass","type":"->"},{"file":"/usr/local/www/nextcloud/lib/private/Route/Router.php","line":455,"function":"getAttributeRoutes","class":"OC\\Route\\Router","type":"->"},{"file":"/usr/local/www/nextcloud/lib/private/Route/Router.php","line":129,"function":"loadAttributeRoutes","class":"OC\\Route\\Router","type":"->"},{"file":"/usr/local/www/nextcloud/lib/private/Route/CachingRouter.php","line":90,"function":"loadRoutes","class":"OC\\Route\\Router","type":"->"},{"file":"/usr/local/www/nextcloud/lib/private/Route/Router.php","line":316,"function":"findMatchingRoute","class":"OC\\Route\\CachingRouter","type":"->"},{"file":"/usr/local/www/nextcloud/lib/base.php","line":1172,"function":"match","class":"OC\\Route\\Router","type":"->"},{"file":"/usr/local/www/nextcloud/index.php","line":25,"function":"handleRequest","class":"OC","type":"::"}],"File":"/usr/local/www/nextcloud/lib/private/Route/Router.php","Line":499,"message":"Class \"OCA\\Settings\\Controller\\AppSettingsController\" does not exist","exception":"{\"class\":\"ReflectionException\",\"message\":\"Class \\\"OCA\\Settings\\Controller\\AppSettingsController\\\" does not exist\",\"code\":-1,\"file\":\"/usr/local/www/nextcloud/lib/private/Route/Router.php:499\",\"trace\":\"#0 /usr/local/www/nextcloud/lib/private/Route/Router.php(499): ReflectionClass->__construct()\\n#1 /usr/local/www/nextcloud/lib/private/Route/Router.php(455): OC\\Route\\Router->getAttributeRoutes()\\n#2 /usr/local/www/nextcloud/lib/private/Route/Router.php(129): OC\\Route\\Router->loadAttributeRoutes()\\n#3 /usr/local/www/nextcloud/lib/private/Route/CachingRouter.php(90): OC\\Route\\Router->loadRoutes()\\n#4 /usr/local/www/nextcloud/lib/private/Route/Router.php(316): OC\\Route\\CachingRouter->findMatchingRoute()\\n#5 /usr/local/www/nextcloud/lib/base.php(1172): OC\\Route\\Router->match()\\n#6 /usr/local/www/nextcloud/index.php(25): OC::handleRequest()\\n#7 {main}\"}","CustomMessage":"Class \"OCA\\Settings\\Controller\\AppSettingsController\" does not exist"}}
2

This is a leftover-file problem from the upgrade, not a bug in Nextcloud itself.

In Nextcloud 34 the App Store / app management was moved out of the settings app into a new dedicated appstore app. (PR#59997)
As part of that, OCA\Settings\Controller\AppSettingsController was removed, and the routes that pointed at it were removed from the settings app at the same time. You can see both sides of the change between the release branches:

  • apps/settings/lib/Controller/AppSettingsController.php: present in stable33, gone in stable34.
  • apps/settings/appinfo/routes.php: lists AppSettings#... routes in stable33, and no longer references them in stable34.
  • The new app lives at apps/appstore.

So on a clean 34 install, neither the controller nor the routes that reference it exist. On your instance they are out of sync: your apps/settings/appinfo/routes.php is still the old 33 version (it lists AppSettings#...), while the controller class file has already been removed. When the router loads that route it tries to reflect on OCA\Settings\Controller\AppSettingsController, the class is not there, and you get the ReflectionException / Internal Server Error.

occ upgrade did not catch it because occ upgrade migrates the database and app state, it does not rewrite the app source files. It trusts whatever is on disk. Your FreeBSD pkg upgrade replaced some files but left the old routes.php (and possibly other stale files) in the settings app directory, so the mismatch only surfaces at runtime.

Fix: make the settings app on disk actually match 34.0.2, so the obsolete files are gone and the new appstore app is present. Do not just upgrade on top of the existing tree, remove the stale files. Clean way on FreeBSD: reinstall so the app directories are fully replaced, or drop in a fresh apps/settings and apps/appstore from the official 34.0.2 release tarball, then clear the caches. After that the phantom route is gone.

For the port maintainer this is worth reporting: the pkg upgrade should remove files that no longer exist in the new version instead of leaving them behind.

h.t.h.

ernolf

3

I see. It could be an issue with me not updating to 33 via pkg that caused issues with the pkg update for 34, not sure if it’s an issue with the pkg process or not.

Did a manual install of 34.0.1(because 34.0.2 isn’t on Nextcloud changelog for some reason), refollowed the manual upgrade from Upgrade manually — Nextcloud 34 Administration Manual and then did the pkg upgrade to 34.0.2 and I can access the UI now, but the app store seems completely broken.
If I go to settings/apps, it’s just an empty page, nothing loads and I’m missing a bunch of apps, there’s only 5 installed.

Maybe it has something to so with clearing the cache, which I didn’t do because I’m not sure what you’re referring to.

4

Messed around fixing stuff from “Security & setup warnings” and now the app page shows up, but there are a lot that are missing, like calendar that shows version 0 and refuses to install, not sure what’s up with that.

5

From what you describe, the empty app store looks to me like the same root cause as the reflection error, only seen from the other side now that the UI loads. Five apps left, the rest missing or stuck at version 0 and refusing to install, is what a mixed-version app tree typically looks like, so my best guess is that your apps/ on disk is still a blend of the versions you passed through, the bundled apps no longer match the core version, and the new appstore app that 34 split out of settings is not cleanly in place, so the store cannot list or install anything.

Cron will not fix that kind of thing. Background jobs run database migrations and repair steps, they never rewrite the source files on disk and cannot replace an app tree that is out of sync. What it needs, I think, is a clean file state. Get apps/ to be exactly 34.0.2 with nothing left over from the earlier versions, ideally by dropping a fresh apps/ from the official 34.0.2 release over the current tree so the obsolete files are really gone, then clear the caches. After that run occ upgrade once, and let cron run a couple of times so the migrations settle.

I cannot see your box from here, so take this as the most likely explanation rather than a certainty, but once the code on disk is genuinely one single version, the store, the missing apps and the version 0 entries should fall back into place, because nothing would be pointing at a controller, route or manifest that is no longer there.

h.t.h.

ernolf

6

Where can I get an archive of 34.0.2? the changelog page doesn’t have it so I’m not sure where to get it.

7
8

Thanks for the link.

Using a clean apps folder didn’t change anything(I fully deleted the old apps folder and copied the new from the archive, then set the permissions)

These are the missing(v0) apps if I look at app bundles leaving me with 5 listed in the menu(don’t think they would be all deprecated):

Nextcloud_apps
Nextcloud_apps2061×1025 157 KB

I do fully reload the browser page(with Ctrl+Shift+R) after a webserver restart so I’m assuming that’s enough to clear the cache you mentioned. Am I wrong in thinking that?
BTW, I can’t run occ upgrade again, it just says “No upgrade required.”.

There is an apps-apk folder I keep copying from my install that isn’t included in the archive. I’m assuming that’s tracking what I had installed and I have no choice but to use that since it complains it’s missing if I don’t.

9

This is what I had in mind when I suggested copying the fresh apps/ over the existing one instead of replacing it. Replacing the whole folder with the one from the tarball did clear the version mismatch, but it also took every app that does not ship with Nextcloud along with it, so the third-party apps you had added are simply gone from disk now. That is where the new round of errors comes from: Nextcloud does not decide whether an app is installed by looking at the folder, it reads that from its database, and there those apps are still marked as enabled. So it keeps trying to load code that is no longer there, and every time something tries to resolve one of those paths it throws.

The good news is that this is easy to walk back, and you do not have to touch the database by hand. The app store judges by what is actually on disk, so it now sees those missing apps as not installed and will offer them for a fresh install again. Just reinstall the ones you want from the app store as normal. That puts the files back, reconciles the enabled flag the database already holds, and runs each app’s migrations, so they line up again.

For anything you do not want back, disabling it is enough to stop the noise:

occ app:disable <appid>

That clears the stale enabled flag even though the files are gone. Note that occ app:remove will not do anything useful here, it refuses once the files are already missing, so disable is the right tool for the leftovers.

Once every enabled app is either back on disk or disabled, the database and the file tree agree again and the errors about missing controllers and apps should stop.

For next time, save yourself all of this and let Nextcloud update itself, ideally with the command line based updater, which swaps the code for you and leaves your added apps in place:

h.t.h.

ernolf

10

Nextcloud introduces breaking changes too often for me to consider auto-updating, I’ve had to fix a bunch of things just now that had broken like the image viewer that changed a while back(I’ve been lazy fixing that one) and some java stuff that prevented the app store from working at all. If I need it, I’d like to know it’s working even if it’s not fully updated.

The original apps folder was gone when I updated to v33 anyway, I would have needed to restore the v32 backup to preserve them and that likely would have caused some issues I bet unless I redid the whole updating from scratch.

It’s not allowing me to download and enable those that have a v0, if I click on the download button on the interface either from the screenshot above or from the details in discover, it just does nothing. No error message in the log either.
I can download and enable those that have a version number perfectly fine though.

11

Two things there. First, I never said a word about automatic updates, so let us not hang that on Nextcloud. What I pointed you at is the command line based updater, and that is the exact opposite of auto-updating. It is a tool you run by hand, one release at a time, that does nothing at all until you start it and that leaves your apps in place while it swaps the core. If anything, the less controlled path is the one you are already on: automatic, unattended updates are what you get from a package install, and your FreeBSD pkg upgrade is exactly that. It is also, remember, the pkg upgrade that left the stale routes.php behind and started this whole thread. So the updater is not the thing to be wary of here, the package path is.

The second thing, and I will be honest because it is what makes this hard to help with, is that I still cannot tell what you actually did to your installation, and every post adds another move. Deleting the whole apps/ folder, then thinking about restoring apps/ from a v32 backup, none of that is a supported way through an upgrade, and it does more damage than it repairs. The apps folder is not a standalone thing you can swap or roll back on its own. Its contents have to match both the core version on disk and the state Nextcloud keeps in its database. Drop an older apps folder in, or wipe it and only partly refill it, and those two drift apart. The v0 apps you are staring at now are precisely that drift: Nextcloud still has them marked as enabled in the database while their files are gone, so the version reads as 0 and the store button has nothing to act on, which is why clicking it does nothing and logs nothing.

The way out of that is the command line, not the web UI:

  • to get an app back, run occ app:install <appid>. It checks the files on disk, sees they are missing, downloads the app fresh from the store and enables it, which is the exact step the store button refuses while the database still believes the app is there.
  • to clear a ghost you do not want back, occ app:disable <appid> drops the stale enabled flag even with the files gone.
  • occ app:list shows you the whole picture, enabled against disabled, so you can see what is still hanging.

Once every enabled app is either back on disk or disabled, the database and the files agree again and the v0 entries stop.

And on the breaking changes, I will say it plainly: the app store not loading and this whole app mess are not something a Nextcloud release did to you, they are what the pkg upgrade and the manual folder surgery left behind. Go through the updater next time and let it handle the code in one coherent step, and you skip all of this.

h.t.h.

ernolf

12

Ok, I can get them back(see a version number) by manually downloading the file and extracting it into apps, but it’s working weird. I get “Page not found” when I open the apps, even after setting the permission, restarting the web server and doing a full refresh(or even trying in a different browser where I never tried to access it). So far I installed 2 back and one eventually worked for no apparent reason, but the other is just refusing to open still.

13

Dropping the extracted tarball into apps/ is not installing an app, it only puts the files there. The install is a separate step, and it is the part that sets up the database for the app: it runs the app’s migrations and its repair steps. When you extract by hand you skip exactly that step, so the tables and registrations the app needs are never created and it cannot load. That is your “Page not found”. The one app that came up anyway simply had nothing to migrate, so the files alone were enough for it. The one that refuses to open needs its migrations, and they never ran.

There is a catch, because of the state it is in now. Nextcloud still has the app marked as enabled in its database, so running occ app:enable on it directly just reports “already enabled” and does nothing, the install step never fires. You have to take the app out of that enabled state first and bring it back in:

occ app:disable <appid>
occ app:enable <appid>

After the disable Nextcloud no longer considers the app installed, so the enable runs the full path: it pulls the app from the app store itself if the files are missing, runs its migrations and repair steps, and enables it, all in one step. Run that pair for each app, whether you extracted it by hand or it is still missing entirely. That is the whole procedure, with no manual downloading or unpacking anywhere in it.

Now I have to be plain with you. Every step you have described has been a manual workaround that is not how Nextcloud is meant to be maintained: replacing the whole apps folder, thinking about restoring apps from an old backup, hand-extracting tarballs. Each one has created the next problem, and I have handed you the supported commands twice already. Please sit down with the documentation before you touch anything else:

I am glad to keep helping you, but I would rather not chase a chain of hand-made repairs that go against both the manual and what I have already recommended. Give the documented way an honest try first, and I will happily pick it up with you from there.

h.t.h.

ernolf

14

I guess I misunderstood what letting nextcloud update itself meant so sorry about that, letting apps update themselves tends to be a cause of more problems, like dependencies not following(pkg takes care of the php stuff) so I prefer to avoid it. It’s not often I miss a major release so there’s usually no problems. I might give the updater a shot next time I wait too long to update, but I’m pretty comfortable with doing things manually, which is why I went with the manual way.

With that said, seems I messed up step 10 of the manual update, I did not think I had any 3rd party apps since I installed everything from nextcloud so I didn’t check, but it seems I was wrong about that, the apps from the store are considered 3rd party I guess.

Is there an easy way to get the appid so I can install them properly? I don’t see it anywhere in the store or the apps descriptions.

Edit: Oh, the id is the name(not quite but close enough), I expected a number since that’s what ids usually are.

15

Extracting the archive in the apps folder seems to have the exact same effect as occ app:install, I had the file not found page. I’m assuming it migrated the settings fine and as soon as the files are back, its happy.
The issue about the file not found was that I was only restarting the webserver and not php, restarting both fixed that.

I should be good once I reinstall everything(all done and good now), thanks for all of your help and sorry for being hard to understand at time and doing things too fast.