Owncloud 10.12.2 to NextCloud Migration

Thorsten23 · August 3, 2023, 8:11am

Hi guys,
I need some help migrating from Owncloud 10.12.2 to Nextcloud.
I tried upgrading to Nextcloud 25.0.9 or 26.0.4 but got the error message “Updates between multiple major versions and downgrades are unsupported”.
The migration manual only mentioned upgrades from owncloud 10.11.x to 25.0.x, does anybody know if there will an uprade path from 10.12.x?
I found follwing post Migrating from ownCloud to a NextCloud docker container: “Updates between multiple major versions and downgrades are unsupported” which edited the version tag to force the upgrade but breakes oauth2 integration.
Normally this should not be a problem for me, or does this break a basic function of Nextcloud?

Thanks for your help!
Thorsten

jtr · August 3, 2023, 8:03pm

Disclaimer: I have not done a migration from OC.

It looks like the owncloud oauth2 migration may have been fixed recently anyhow (and made its way into NC25.0.8) via PR #38577

It looks like 10.11 migration support was added in #35471

For 10.12 a quick look shows some new db migrations (db changes) which are the biggies to look out for typically with OC->NC migrations. Below find the list and my comments on the probable impact of each on a migration.

github.com

owncloud/core/blob/4652fa25a0f979352d31f0ad5a5d6382fc9a601a/core/Migrations/Version20230120101715.php

<?php
/**
 * @author Pasquale Tripodi <ptripodi@owncloud.com>
 *
 * @copyright Copyright (c) 2023, ownCloud GmbH
 * @license AGPL-3.0
 *
 * This code is free software: you can redistribute it and/or modify
 * it under the terms of the GNU Affero General Public License, version 3,
 * as published by the Free Software Foundation.
 *
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 * GNU Affero General Public License for more details.
 *
 * You should have received a copy of the GNU Affero General Public License, version 3,
 * along with this program.  If not, see <http://www.gnu.org/licenses/>
 *
 */

This file has been truncated. show original

^This adds a creation_time column to oc_accounts. It’ll probably just be ignored post migration so likely okay.

github.com

owncloud/core/blob/4652fa25a0f979352d31f0ad5a5d6382fc9a601a/core/Migrations/Version20230210073645.php

<?php
namespace OC\Migrations;

use Doctrine\DBAL\Schema\Schema;
use Doctrine\DBAL\Schema\SchemaException;
use OCP\Migration\ISchemaMigration;

class Version20230210073645 implements ISchemaMigration {
	/**
	 * @throws SchemaException
	 */
	public function changeSchema(Schema $schema, array $options): void {
		$prefix = $options['tablePrefix'];
		$table = $schema->getTable("{$prefix}filecache");
		$table->addIndex(['parent', 'storage', 'size'], 'fs_parent_storage_size');
	}
}

^This just adds an index. Probably fine.

github.com

owncloud/core/blob/4652fa25a0f979352d31f0ad5a5d6382fc9a601a/core/Migrations/Version20230210103154.php

<?php
namespace OC\Migrations;

use OCP\Migration\ISimpleMigration;
use OCP\Migration\IOutput;

/**
 * Migrate from deprecated save_version_author to save_version_metadata
 */
class Version20230210103154 implements ISimpleMigration {
	/**
	 * @param IOutput $out
	 */
	public function run(IOutput $out) {
		$oldValue = \OC::$server->getSystemConfig()->getValue('file_storage.save_version_author', null);
		if ($oldValue !== null) {
			\OC::$server->getSystemConfig()->setValue('file_storage.save_version_metadata', $oldValue);
		}
		\OC::$server->getSystemConfig()->deleteValue('file_storage.save_version_author');
	}

This file has been truncated. show original

^This adds/updates configuration parameters that NC should just ignore. Probably fine.

github.com

owncloud/core/blob/4652fa25a0f979352d31f0ad5a5d6382fc9a601a/core/Migrations/Version20230105001100.php

<?php

namespace OC\Migrations;

use Doctrine\DBAL\Schema\Schema;
use OCP\Migration\ISchemaMigration;

class Version20230105001100 implements ISchemaMigration {
	public function changeSchema(Schema $schema, array $options) {
		$prefix = $options['tablePrefix'];

		if ($schema->hasTable("${prefix}calendars")) {
			$calendarsTable = $schema->getTable("${prefix}calendars");

			if ($calendarsTable->hasColumn('components')) {
				$components = $calendarsTable->getColumn('components');
				$components->setOptions(['length' => 255]);
			}
		}
	}

This file has been truncated. show original

^This might require some special handling, but I think it’ll only require a light touch. The length of the components field in oc_calendars was increased from 20 to 255. This was done to accommodate an issue where it needed to be 21 characters. NC already uses a 64 character field. Probably best to manually ALTER this table field post-migration to match NC. I suspect from reading the associated issue and PR that 64 will still be more than enough.

Docker image comments

That said, while using the Docker image typically simplifies things, the official admin manual approach to an OC to NC migration is entirely built on a manual deploy. The Docker image also has additional version checks and they likely weren’t tested with an OC migration in mind. I skimmed that thread you linked and it looks interesting so no reason to not try that path if you wish, but putting that out there.

Hopefully it goes without saying that this all shouldn’t happen without good backups and recovery processes in place. Fortunately the migration can be tested offline in a test environment.

If you get it to work, might be appreciated by others if you submit some light additions specific to 10.12 to the existing docs like was done for 10.11 not too far back - e.g. Update instructions for upgrading from ownCloud 10.11 by PVince81 · Pull Request #9424 · nextcloud/documentation · GitHub

Disclaimer: Untested. Just from poking around at the code and changes.

Thorsten23 · August 12, 2023, 7:03pm

Hi @jtr ,
thank you for the detailed answer, you helped me a lot!
Little spoiler, i did the upgrade and it worked very well!

So here is a brief summery of what i did.

I Waited for NC Version 25.0.10, to get to oAuth2 fix
Start with the migration according to the NC migration documentation
before I executed die occ upgrade command, I change version.php (this will cause integrity errors which you can fix by undoing the changes after the migration)

  'owncloud' =>
  array (
    '10.11' => true,
  ),

to

  'owncloud' =>
  array (
    '10.12' => true,
  ),

execute occ upgrade without any problems
execute database fixes according to the NC migration documentation
Alter DB to utf8mb4_general_ci

ALTER DATABASE owncloudDB CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

edited OC cron to NC cron
be lucky new NC user!
First of all after the migration I upgraded to PHP 8.0
Next step will be a NC Upgrade to 26

According to the owncloud database scheme changes

new column creation_time for oc_accounts will be remove through the database migration process during upgrade

MariaDB [owncloudDB]> DESCRIBE oc_accounts;
+-------+-------------+------+-----+---------+-------+
| Field | Type        | Null | Key | Default | Extra |
+-------+-------------+------+-----+---------+-------+
| uid   | varchar(64) | NO   | PRI |         |       |
| data  | longtext    | NO   |     | NULL    |       |
+-------+-------------+------+-----+---------+-------+

new index fs_parent_storage_size exists after the upgrade, but i also think that should not cause any problems
i do no see the configuration paramter after the migration, maybe because the old config value was NULL
char lenght for components column of oc_calendards table will automaticly altered through the migration routine and does not have to be altered afterwrads. I checkt the table content before and there were no values with more than 21 characters.
According to the issue report which cause the increase to 255 characters, the orginal size was 255, before it was reduce to 20. Perhaps therefore nextcloud had already the correct database migration routine.
before migration

MariaDB [owncloudDB]> DESCRIBE oc_calendars;
+---------------+---------------------+------+-----+---------+----------------+
| Field         | Type                | Null | Key | Default | Extra          |
+---------------+---------------------+------+-----+---------+----------------+
| id            | bigint(20) unsigned | NO   | PRI | NULL    | auto_increment |
| principaluri  | varchar(255)        | YES  | MUL | NULL    |                |
| displayname   | varchar(255)        | YES  |     | NULL    |                |
| uri           | varchar(255)        | YES  |     | NULL    |                |
| synctoken     | int(10) unsigned    | NO   |     | 1       |                |
| description   | varchar(255)        | YES  |     | NULL    |                |
| calendarorder | int(10) unsigned    | NO   |     | 0       |                |
| calendarcolor | varchar(255)        | YES  |     | NULL    |                |
| timezone      | longtext            | YES  |     | NULL    |                |
| components    | varchar(255)        | YES  |     | NULL    |                |
| transparent   | smallint(6)         | NO   |     | 0       |                |
+---------------+---------------------+------+-----+---------+----------------+

after migration

MariaDB [owncloudDB]> DESCRIBE oc_calendars;
+---------------+---------------------+------+-----+---------+----------------+
| Field         | Type                | Null | Key | Default | Extra          |
+---------------+---------------------+------+-----+---------+----------------+
| id            | bigint(20) unsigned | NO   | PRI | NULL    | auto_increment |
| principaluri  | varchar(255)        | YES  | MUL | NULL    |                |
| displayname   | varchar(255)        | YES  |     | NULL    |                |
| uri           | varchar(255)        | YES  |     | NULL    |                |
| synctoken     | int(10) unsigned    | NO   |     | 1       |                |
| description   | varchar(255)        | YES  |     | NULL    |                |
| calendarorder | int(10) unsigned    | NO   |     | 0       |                |
| calendarcolor | varchar(255)        | YES  |     | NULL    |                |
| timezone      | longtext            | YES  |     | NULL    |                |
| components    | varchar(64)         | YES  |     | NULL    |                |
| transparent   | smallint(6)         | NO   |     | 0       |                |
| deleted_at    | int(10) unsigned    | YES  |     | NULL    |                |
+---------------+---------------------+------+-----+---------+----------------+

Summary:
Overall, the migration went smoothly and I did not notice any problems or limitations!

Thanks for the help, I hope this thread will help more people migration to nextcloud!

Best,
Thorsten

jtr · August 12, 2023, 7:42pm

Awesome to hear. And thanks for sharing your experience for others to benefit from as well!