Oauth2 app upgrade failing

I saw there were app updates ready for my Owncloud instance (in Marketplace on the web portal), so I simply clicked.

When I tried to upgrade Oauth2, it went to a maintenance screen and wouldn’t get out of it. So I looked into doing it by hand at the command line. I can now see where its stuck.

Steps to reproduce

  1. Navigate to /var/www/owncloud
  2. Run: sudo -u www-data ./occ upgrade
  3. Upgrade process throws an error

Expected behaviour

Oauth2 app should just upgrade as normal

Actual behaviour

Upgrade process throws an error:

sudo -u www-data ./occ upgrade
ownCloud or one of the apps require upgrade - only a limited number of commands are available
You may use your browser or the occ upgrade command to do the upgrade
2025-05-09T16:34:59+00:00 Set log level to debug
2025-05-09T16:34:59+00:00 Repair step: Upgrade app code from the marketplace
2025-05-09T16:34:59+00:00 Repair step: Repair MySQL database engine
2025-05-09T16:34:59+00:00 Repair step: Repair MySQL collation
2025-05-09T16:34:59+00:00 Repair info: All tables already have the correct collation → nothing to do
2025-05-09T16:34:59+00:00 Repair step: Repair SQLite autoincrement
2025-05-09T16:34:59+00:00 Repair step: Repair orphaned reshare
2025-05-09T16:34:59+00:00 Repair step: Repair duplicate entries in oc_lucene_status
2025-05-09T16:34:59+00:00 Repair info: lucene_status table does not exist → nothing to do
2025-05-09T16:34:59+00:00 Updating database schema
2025-05-09T16:34:59+00:00 Updated database
2025-05-09T16:34:59+00:00 Updating …
An unhandled exception has been thrown:
Error: Class ‘Doctrine\DBAL\Types\Types’ not found in /var/www/owncloud/apps/oauth2/appinfo/Migrations/Version20201123114127.php:13
Stack trace:
#0 /var/www/owncloud/lib/private/DB/MigrationService.php(416): OCA\oauth2\Migrations\Version20201123114127->changeSchema(Object(Doctrine\DBAL\Schema\Schema), Array)
#1 /var/www/owncloud/lib/private/DB/MigrationService.php(371): OC\DB\MigrationService->executeStep(20201123114127)
#2 /var/www/owncloud/lib/private/legacy/app.php(969): OC\DB\MigrationService->migrate()
#3 /var/www/owncloud/lib/private/Updater.php(345): OC_App::updateApp(‘oauth2’)
#4 /var/www/owncloud/lib/private/Updater.php(271): OC\Updater->doAppUpgrade()
#5 /var/www/owncloud/lib/private/Updater.php(112): OC\Updater->doUpgrade(‘10.3.0.4’, ‘10.3.0.4’)
#6 /var/www/owncloud/core/Command/Upgrade.php(261): OC\Updater->upgrade()
#7 /var/www/owncloud/lib/composer/symfony/console/Command/Command.php(255): OC\Core\Command\Upgrade->execute(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#8 /var/www/owncloud/lib/composer/symfony/console/Application.php(963): Symfony\Component\Console\Command\Command->run(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#9 /var/www/owncloud/lib/composer/symfony/console/Application.php(254): Symfony\Component\Console\Application->doRunCommand(Object(OC\Core\Command\Upgrade), Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
10 /var/www/owncloud/lib/composer/symfony/console/Application.php(147): Symfony\Component\Console\Application->doRun(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#11 /var/www/owncloud/lib/private/Console/Application.php(165): Symfony\Component\Console\Application->run(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#12 /var/www/owncloud/console.php(106): OC\Console\Application->run()
#13 /var/www/owncloud/occ(11): require_once(‘/var/www/ownclo…’)

Server configuration

Operating system:
Ubuntu 18.04

Web server:
Apache

Database:
Mysql

PHP version:
7.2

ownCloud version: (see ownCloud admin page)
10.3.0.4

Updated from an older ownCloud or fresh install:
Updated from first install version 10.0.10.4

Where did you install ownCloud from:
Owncloud

Login as admin user into your ownCloud and access 
http://example.com/index.php/settings/integrity/failed 
paste the results into https://gist.github.com/ and puth the link here.

No errors have been found.

The content of config/config.php:

Log in to the web-UI with an administrator account and click on
'admin' -> 'Generate Config Report' -> 'Download ownCloud config report'
This report includes the config.php settings, the list of activated apps
and other details in a well sanitized form.

or 

If you have access to your command line run e.g.:
sudo -u www-data php occ config:list system
from within your ownCloud installation folder

{
“system”: {
“updatechecker”: false,
“instanceid”: “ocww14f1maef”,
“passwordsalt”: “REMOVED SENSITIVE VALUE”,
“secret”: “REMOVED SENSITIVE VALUE”,
“trusted_domains”: [
cloud.dbtekpro.com
],
“datadirectory”: “/owncloud/data”,
“overwrite.cli.url”: “https://cloud.dbtekpro.com”,
“dbtype”: “mysql”,
“version”: “10.3.0.4”,
“dbname”: “owncloud”,
“dbhost”: “localhost”,
“dbtableprefix”: “oc_”,
“mysql.utf8mb4”: true,
“dbuser”: “REMOVED SENSITIVE VALUE”,
“dbpassword”: “REMOVED SENSITIVE VALUE”,
“logtimezone”: “UTC”,
“installed”: true,
“mail_domain”: “REMOVED SENSITIVE VALUE”,
“mail_from_address”: “REMOVED SENSITIVE VALUE”,
“mail_smtpmode”: “smtp”,
“mail_smtpauthtype”: “LOGIN”,
“mail_smtpauth”: 1,
“mail_smtpsecure”: “ssl”,
“mail_smtpname”: “REMOVED SENSITIVE VALUE”,
“mail_smtppassword”: “REMOVED SENSITIVE VALUE”,
“mail_smtphost”: “REMOVED SENSITIVE VALUE”,
“mail_smtpport”: “465”,
“theme”: “”,
“loglevel”: 0,
“maintenance”: false
}
}

List of activated apps:

If you have access to your command line run e.g.:
sudo -u www-data php occ app:list
from within your ownCloud installation folder.

Enabled:
  - comments: 0.3.0
  - configreport: 0.2.0
  - dav: 0.5.0
  - federatedfilesharing: 0.5.0
  - federation: 0.1.0
  - files: 1.5.2
  - files_external: 0.7.1
  - files_mediaviewer: 1.0.5
  - files_pdfviewer: 0.11.0
  - files_sharing: 0.12.0
  - files_texteditor: 2.5.1
  - files_trashbin: 0.9.1
  - files_versions: 1.3.0
  - files_videoplayer: 0.10.1
  - gallery: 16.1.1
  - market: 0.5.0
  - notifications: 0.5.0
  - oauth2: 0.4.2
  - provisioning_api: 0.5.0
  - systemtags: 0.3.0
  - updatenotification: 0.2.1
Disabled:
  - audioplayer
  - drawio
  - encryption
  - external
  - firstrunwizard
  - richdocuments
  - user_external
  - wallpaper

Are you using external storage, if yes which one: local/smb/sftp/…
EFS, but mounted as local drive

Are you using encryption: yes/no
No

Are you using an external user-backend, if yes which one: LDAP/ActiveDirectory/Webdav/…
No

Client configuration

Browser:
Chrome

Operating system:
MacOS

I’m fairly new with ownCloud and have installed it recently from “hxxps://owncloud.com/download-server/” and received version 10.15.2 while yours seems to be 10.3.0.4 which looks fairly old to me so i wouldn’t expect that a recent app update is compatible with it.

It is six years old and, like the OS it is running on, long out of support. Both desperately need upgrading. Ubuntu 18.04 is two weeks away from being two years past its end of life.

Watch for PHP version requirements when you upgrade your ownCloud, as the current version requires PHP 7.4.

1 Like

Thanks for that feedback, but the OAuth2 app shows it supports Owncloud 10.3. In fact, it was Owncloud itself that showed this app required updating right within the Admin console itself, and it specified version 0.5.4, which is exactly what its trying to update to (not trying to go past that to the latest, which is 0.6.1, and would NOT be supported by 10.3). So it seems Owncloud itself would know which version its acceptable.

And Owncloud 10.3 can run on PHP 7.2, which is what I have.

The core of the problem seems to be not being able to find the Doctrine\DBAL\Types\Types class. So either I’m missing some updated PHP library, or its some sort of path / environment variable issue.

Any thoughts?

Not sure if feasible but updating the operating system, PHP and ownCloud to supported versions would be the most sane thing to do because unlikely that support from anyone will be given on long EOL versions / products:

Even if the app says it is compatible with ownCloud 10.3.0 i wouldn’t expect that the app developer had tested it down to all version.

There could be also an issue in the update routine of the six year old ownCloud version itself.

1 Like

Thanks for that feedback, but that seems just going deeper into the rabbit hole. I will eventually update the whole thing… in fact, I would probably create a new owncloud server with the newest version from scratch, and simply attach the existing EFS volume I have to it and resync.

But that’s a lot of work for the moment and I need to get this working. I was able to fix it by hacking it.

The script that is trying to run on when upgrading OAuth2 is a database migration script. In fact, there are three of them with the OAuth2 app version 0.5.4. So I simply interpreted what the three scripts were trying to do and generated the appropriate SQL commands to manually modify the database tables myself. This is what it came down to:

alter table oc_oauth2_clients add column trusted boolean not null default false;
alter table oc_oauth2_auth_codes add column code_challenge varchar(64), add column code_challenge_method varchar(64);
create unique index oauth2_token_idx on oc_oauth2_access_tokens (token);

Then I inserted the three migrations into the oc_migrations table:

insert into oc_migrations values ('oauth2','20201123114127');
insert into oc_migrations values ('oauth2','20201126140622');
insert into oc_migrations values ('oauth2','20220312110422');

This should execute the same commands the migration scripts were trying to do, and record in the database that the migrations were already run. Then I re-ran the occ upgrade command again, and it worked just fine.

This enabled the upgrade to move forward. I should note, it wasn’t trying to upgrade all of Owncloud - it simply upgraded the OAuth2 app, which is what I was trying to do.

So now my Owncloud instance is functional and the desktop app and mobile app are able to connect and sync.

Still don’t know why the migration process couldn’t find the Doctrine\DBAL\Types\Types class, but I simply stepped around that issue by manually running the SQL commands from the migrations myself.

Thanks!

1 Like

Not sure if manually modifying a database is a good idea at least this is something i wouldn’t risk on my own server.

But running EOL versions of various products with known bugs and security issues and trusting my data to it seems to “live on the edge” anyway :grimacing:

1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.