Migration from snap not working

[frdescam]

Hi guys,

Is your feature request related to a problem? Please describe.

Yes, I am trying to migrate a snap installation to Nextcloud-AIO but I'm facing multiple issues when following the documentation to the letter.

Describe the solution you'd like

I'd like the documentation to work.

Additional context

• At step 10, when running this command :
  sudo docker exec -i mysql-migration mysql -u nextcloud -p"$MYSQL_PASSWORD" nextcloud < ~/mysql-dump.sql
  I get the following error (even when starting container with --skip-log-bin) :
  ERROR 1227 (42000) at line 2353: Access denied; you need (at least one of) the SUPER or SET_ANY_DEFINER privilege(s) for this operation

  The workaround I found is to import as root but I am not sure this is the best method.

• At step 13, when running the last command :
  sudo docker exec -u www-data nextcloud-convert php occ db:convert-type --all-apps --password "$PG_PASSWORD" pgsql "$PG_USER" postgres-migration "$PG_DATABASE"

  I get the following error :

  Console has to be executed with the user that owns the file config/config.php Current user id: 33 Owner id of config.php: 1000 Try adding 'sudo -u #1000' to the beginning of the command (without the single quotes) If running with 'docker exec' try adding the option '-u 1000' to the docker command (without the single quotes)

  The workaround I found : sudo chown 33:33 /tmp/migration-config.php

  But then :

    Your data directory is not writable.
    Permissions can usually be fixed by giving the web server write access to the root directory. See https://docs.nextcloud.com/server/33/go.php?to=admin-dir_permissions.

    An unhandled exception has been thrown:
    Exception: Environment not properly prepared. in /var/www/html/lib/private/Console/Application.php:143
    Stack trace:
    #0 /var/www/html/console.php(86): OC\Console\Application->loadCommands(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
    #1 /var/www/html/occ(33): require_once('/var/www/html/c...')

The workaround I found : sudo chown -R 33:33 /var/snap/nextcloud/com mon/nextcloud/data.
Also had to to chown 33:33 the config/ folder inside the container

Then when I could finally run the migration command :

In Config.php line 273:
                                                                                            
  Configuration was not read or initialized correctly, not overwriting /var/www/html/confi  
  g/config.php

I didn't find any workaround for this one.

Is it possible to fix the documentation?

Thank you guys!

[frdescam]

Hello again,

I could finally successfully migrate the instance, here are the issues + workaround :

Feedback: snap → AIO migration guide — 6 issues hit during a real migration

Context: I migrated a Nextcloud snap installation (33.0.6, MySQL, 493 GB data, ~750k files, 4 users, third-party apps: calendar, contacts, mail, memories, richdocuments, spreed, tasks) to AIO v13.3.1 (also Nextcloud 33.0.6) following migration.md → "Migrating from a snap installation". The migration ultimately succeeded with all data intact, but the documented procedure failed at 6 points. Details and working fixes below, in the order they bite.

---

1. db:convert-type --all-apps silently skips ALL third-party app tables

Symptom: the conversion prints a long "The following tables will not be converted" list containing every table of store-installed apps — oc_mail_*, oc_memories*, oc_talk_*, oc_richdocuments_*, oc_calendar_appt_*, etc. If you don't read that list carefully, you lose mail accounts, Talk rooms, memories data, calendar bookings… while core tables convert fine.

Cause: the vanilla nextcloud:<version>-apache image used as the conversion container doesn't contain the code of store apps, and db:convert-type only converts tables whose app schema it can load.

Fix that worked: copy the snap's app code into the conversion container before converting:

docker cp /var/snap/nextcloud/current/nextcloud/extra-apps/. nextcloud-convert:/var/www/html/custom_apps/
docker exec nextcloud-convert chown -R www-data:www-data /var/www/html/custom_apps

This also clears the "Nextcloud or one of the apps require upgrade - only a limited number of commands are available" warning, because the app versions on disk then match the DB. Bonus: it lets tables of disabled-but-installed apps convert too.

Suggested guide change: add this as a mandatory step, and tell readers to treat a non-trivial "will not be converted" list as an error, not noise.

2. Bind-mounting config.php as a single file breaks the conversion's final config write

Symptom: at the end of the conversion: Configuration was not read or initialized correctly, not overwriting /var/www/html/config/config.php.

Cause: Nextcloud rewrites config.php via write-temp-then-rename; rename onto a file mountpoint fails. The guide's -v /tmp/migration-config.php:/var/www/html/config/config.php:rw sets exactly that trap.

Fix that worked: mount a config directory instead (containing config.php), e.g. -v /path/to/convert-config:/var/www/html/config:rw.

Caveat this introduces (worth documenting either way): when the mounted config dir is non-empty, the image entrypoint does NOT install its default apps.config.php, so custom_apps isn't registered in apps_paths and fix #1 silently stops working. Solution:

docker exec nextcloud-convert sh -c 'cp -n /usr/src/nextcloud/config/*.config.php /var/www/html/config/'

3. Temp config template lacks 'mysql.utf8mb4' => true → emoji corruption + hard failure

Symptom: SQLSTATE[23505]: Unique violation ... "comment_reaction_unique" DETAIL: Key (parent_id, actor_type, actor_id, reaction)=(..., ?) already exists during copy of oc_reactions.

Cause: the snap uses mysql.utf8mb4 => true, but the guide's temp migration-config.php omits it. The conversion then reads MySQL over a 3-byte-utf8 connection, every 4-byte character (all emoji) collapses to ?, and two distinct reactions (👍/😍) become identical rows. Even where it doesn't collide, all emoji in comments/Talk/etc. would be silently destroyed.

Fix: add 'mysql.utf8mb4' => true, to the temp config template (at least when the source config has it — which every snap install does).

Also worth adding to the template: 'version' => '<exact source version>' (avoids the "require upgrade – limited commands" state), and note that Nextcloud ≥ 32-era datadirs are validated via .ncdata (the container refuses a datadir without it).

4. Foreign-key ordering makes the copy fail on PostgreSQL (oc_mail_accounts → oc_mail_mailboxes)

Symptom: SQLSTATE[23503]: Foreign key violation ... on table "oc_mail_accounts" ... Key (drafts_mailbox_id)=... is not present in table "oc_mail_mailboxes".

Cause: db:convert-type copies tables in list order with FK constraints already created in the target; any app whose FKs point at a table copied later (mail app at minimum) fails.

Fix that worked: drop all FK constraints in the target Postgres during the copy and re-add them afterwards (saved via pg_get_constraintdef() before dropping; all 15 re-applied cleanly once data was complete). Arguably a Nextcloud server bug — db:convert-type should create FKs after the copy, or copy in FK-dependency order.

5. Sequence fix-up crashes: SELECT setval('oc_jobs_id_seq', (SELECT MAX() FROM ))

Symptom: after all tables are copied, the command aborts with a syntax error — empty MAX()/FROM — on oc_jobs_id_seq. (Server bug; data is complete at this point, so the guide should at least tell readers how to finish manually.)

Two distinct problems surfaced here:

• the generated setval SQL loses the column/table identifiers (the visible crash);
• Doctrine creates some sequences with int4 bounds while the (bigint) column data can exceed them — our oc_jobs.id had a value > 2^31, so even a correct setval fails with "out of bounds" until ALTER SEQUENCE ... AS bigint MAXVALUE 9223372036854775807.

Manual completion that worked: widen all sequences to bigint, then set each from its owning table's max via a pg_depend query. Happy to share the exact SQL.

6. Stale image path in older docs/scripts

Minor: make sure all references use ghcr.io/nextcloud-releases/all-in-one — a locally cached :latest of the old ghcr.io/nextcloud/all-in-one path deploys an outdated Nextcloud that then breaks the "versions must match exactly" requirement. A docker pull / mastercontainer update step before comparing versions would prevent this.

---

Suggestions beyond bug fixes

• The guide's advice to run mysqldump while the snap is still running risks an inconsistent dump; recommend occ maintenance:mode --on (or stopping apache/php/cron while keeping mysql up) before dumping.
• For large datadirs on spinning disks, docker cp during downtime is painful; a note about pre-copying with rsync (--chown=33:0 --chmod=D750,F640 matches AIO's expected permissions and saves a full extra pass) and/or using NEXTCLOUD_DATADIR with an instant same-filesystem mv would save users hours.
• After a successful conversion, occ db:add-missing-indices / add-missing-columns / add-missing-primary-keys is a cheap sanity step worth mentioning.

All six issues were hit on: snap 33.0.6 (MySQL 8, utf8mb4) → AIO v13.3.1 / Nextcloud 33.0.6.2, nextcloud:33.0.6-apache as conversion image, mysql:8 --skip-log-bin and postgres:16 temp containers, Docker 29.6.1, Ubuntu (kernel 6.8).

[pabzm]

Thank you for posting your workaround and suggestions! Would you be interested to put them into a pull request against the migration guide?

[frdescam]

Yes, I can, but not soon, maybe next week, maybe next month