"Fix classification for calendar objects" error when manually upgrading to 9.1

I tried to upgrade Owncloud 9.03 to 9.1 via manully uploading the files to my shared hosting environment. Before that I disabled all the 3rd party apps (such as user_sql which I use to authenticate against a Joomla database).

The upload seems to work fine, in the sense that after uploading I'm being presented with a screen asking me to start the upgrade process. However, once I start this process, it keeps getting stuck at the " Fix classification for calendar objects" status. Please find the log below.

What to do?

Thanks.

> Update voorbereiden
> Logniveau instellen op debug
> Onderhoudsmodus ingeschakeld
> Controleert of het database schema geüpdatet kan worden (dit kan lang duren afhankelijk van de grootte van de de database)
> [1 / 24]: Controleren tabel oc_appconfig
> [2 / 24]: Controleren tabel oc_storages
> [3 / 24]: Controleren tabel oc_mounts
> [4 / 24]: Controleren tabel oc_mimetypes
> [5 / 24]: Controleren tabel oc_filecache
> [6 / 24]: Controleren tabel oc_group_user
> [7 / 24]: Controleren tabel oc_group_admin
> [8 / 24]: Controleren tabel oc_groups
> [9 / 24]: Controleren tabel oc_preferences
> [10 / 24]: Controleren tabel oc_properties
> [11 / 24]: Controleren tabel oc_share
> [12 / 24]: Controleren tabel oc_jobs
> [13 / 24]: Controleren tabel oc_users
> [14 / 24]: Controleren tabel oc_authtoken
> [15 / 24]: Controleren tabel oc_vcategory
> [16 / 24]: Controleren tabel oc_vcategory_to_object
> [17 / 24]: Controleren tabel oc_systemtag
> [18 / 24]: Controleren tabel oc_systemtag_object_mapping
> [19 / 24]: Controleren tabel oc_systemtag_group
> [20 / 24]: Controleren tabel oc_privatedata
> [21 / 24]: Controleren tabel oc_file_locks
> [22 / 24]: Controleren tabel oc_comments
> [23 / 24]: Controleren tabel oc_comments_read_markers
> [24 / 24]: Controleren tabel oc_credentials
> Database schema-update gecontroleerd
> Controleert of er updates voor apps zijn
> Controleert of het database schema voor dav geüpdatet kan worden ( dit kan lang duren afhankelijk van de grootte van de database )
> [1 / 10]: Controleren tabel oc_addressbooks
> [2 / 10]: Controleren tabel oc_cards
> [3 / 10]: Controleren tabel oc_addressbookchanges
> [4 / 10]: Controleren tabel oc_calendarobjects
> [5 / 10]: Controleren tabel oc_calendars
> [6 / 10]: Controleren tabel oc_calendarchanges
> [7 / 10]: Controleren tabel oc_calendarsubscriptions
> [8 / 10]: Controleren tabel oc_schedulingobjects
> [9 / 10]: Controleren tabel oc_cards_properties
> [10 / 10]: Controleren tabel oc_dav_shares
> Controleert of het database schema voor files_sharing geüpdatet kan worden ( dit kan lang duren afhankelijk van de grootte van de database )
> [1 / 1]: Controleren tabel oc_share_external
> Controleert of het database schema voor files_trashbin geüpdatet kan worden ( dit kan lang duren afhankelijk van de grootte van de database )
> [1 / 1]: Controleren tabel oc_files_trash
> Controleert of het database schema voor notifications geüpdatet kan worden ( dit kan lang duren afhankelijk van de grootte van de database )
> [1 / 1]: Controleren tabel oc_notifications
> Database schema-update voor apps gecontroleerd
> Database schema aan het updaten
> Database bijgewerkt
> [1 / 0]: admin
> [1 / 1]: Fix classification for calendar objects
> Er heeft zich een fout voorgedaan.
> Herlaad deze pagina.

Hi,

you need to wait until that process is finished (just have some patience). As an alternative you can also wait for oC 9.1.1 which makes this process faster:

Thanks for your quick reply.

In my memory, nothing happend anymore and the upgrade process ordered me to reload the page (in which case it was back in maintenance mode again). I might try again, but right now I'm placing back (re-uploading) the old version.

Do you have a lot of users?

In general its also recommended to use the occ command line tool to update the instance to avoid such timeouts.

No, just one admin user and +/- 100 users via Joomla (via the user_sql app).

Then please always use the occ command on such large installs.

How could I do that on a shared hosting environment? I only have FTP/Directadmin access to my server.

BTW, I'm rather surprised that you consider just 100 users already a large install.

Further, please note that I have done a fresh install using the web installer. This seemed to be the best and fastest solution for this moment. All seems to be running smoothly right now on 9.1.

Hi,

on such a large user base a shared hosting environment is really the wrong environment for your installation.

They even see a installation with more then 50 users as a large install:

You probably just don't get that message as you're using the user_sql app.