Hi, I have found similar posts in the past, but my situation is a little bit different:
I had an installation on my own server that I maintained, updated etc. myself. Now, I have a different hosting contract where I can make use of a feature where I can get popular apps pre-setup by the hoster (in fact, that seems to be a 3rd party tool called “installotron”) which has the advantage that NC will be automatically updated.
This is what I did so far:
Made complete backups of the old installation (files + mysqldump)
Installed NextCloud via the wizard in the new location
Put NC into maintenance mode
Filled the DB with the old data (adapting all tables to the correct table prefix randomly chosen by the one-click installer)
Restored the backup contents of the data folder (in the correct location, which for some stupid reason is not the data/ folder that is misleadingly present and even contains things like a nextcloud.log, but a hidden folder with a randomly chosen name, as can be seen in the config.php)
Now, when I try to log in (as any user, also as admin), I am getting the “HMAC does not match.” error.
My suspicion is that I have to use the old passwordsalt in the config.php? What about secret? (data-fingerprint was not used, so I ignored that part of the docs.)
Ok, in the meantime I have tried just restoring the passwortsalt, and then also the instanceid (since I noticed that the appdata_<instanceid> directory had a new suffix), and this directory came up in discussions of this error in the past.
No, I never came across that one. Cool, thanks – that looks useful.
However, I am getting There are no commands defined in the "passwords:backup" namespace.
What’s useful, though, is the information under “Troubleshooting”, which suggests that my transfer of the passwords db tables + appdata folder should have been nearly sufficient, but apparently I also need the secret config… Alas, setting that on the target server also does not work.
Oh, yes, it finally worked out! I just restored the DB from scratch, since for a while I tried to log in with the wrong secret – now that I did the following, everything worked:
restore the full db
restore the data folder
ensure that instanceid, passwordsalt, and secret are the same as before in the config.php (while many paths, database and smtp setup of course changed for the new server)
So, thanks again, even though I could not get that occ subcommand to run on my installation.