✅ NextCloud uninstalled + broken DB during 31→32 upgrade

[nahoj]

What app is this about, and its version: Nextcloud, v31.x → 32.0.6~ynh1
What YunoHost version are you running: 12.1.39
What type of hardware are you using: Old laptop or computer
MariaDB: 10.11.14

I opened a topic a month ago and didn’t have time to work on the issue before the topic closed: Nextcloud restore fails: ERROR 1180 "Operation not permitted" during COMMIT, after failed upgrade

I managed, by which I mean Claude managed, to get NextCloud back working and up to v32. Thank you @rodinux for your reply, though I didn’t need to use it in the end. Here’s the writeup should it be of help to someone:

Root causes

1. As described in my original post, the 31→32 upgrade initially failed due to a NextCloud app compatibility issue,
2. and reimporting the backed up database was crashing midway because of some encoding issue (unsure why).
3. 76 tables (of those that were imported) were using Compressed row format instead of the Dynamic format required by NC 31+, which would likely have blocked any subsequent upgrade attempt. I remember seeing a notice that I had to manually change this row format, somewhere at some point, but I had neglected it.

What we did

1. Backed up the live data directory (tar) and live database (mysqldump) before touching anything.
2. Converted all 76 Compressed tables to ROW_FORMAT=DYNAMIC.
3. Copied the live DB aside as nextcloud_old, then did a fresh Nextcloud install via YunoHost (which installed NC 32).
4. Dropped the fresh empty tables, imported our real data from nextcloud_old, and restored the original data directory.
5. Ran occ upgrade — the 31→32 migration succeeded this time, though it stumbled on the missing tables.
6. To recreate them: installed NC once again into a throwaway database to get a clean NC 32 schema, then used mysqldump --no-data to extract and import only the missing table structures.
7. Ran files:scan --all (33k files, no errors), re-enabled apps (calendar, contacts, deck, tasks, notes), and everything came back.

We didn’t end up needing the iconv -f latin1 -t utf8mb4 conversion. That was our fallback in case the live database import failed. Since the live DB (incomplete as it was) imported cleanly and the missing tables could be recreated from a fresh schema, we never had to touch the backup’s db.sql.