Devices (Clients) authorization disrupted after disaster recovery to fresh installed Server

I’m testing disaster recovery of my Nextcloud, by recovering backup of ncdata, config.php and a database dump to a fresh installed Nextcloud Server.

This works widely great for me - the previous setup credentials work seamlessly to logon the web interface. The new server is fully functional via its web interface - all user files and data, settings, shares, comments, etc. are back. It looks like an exact clone of the original server.

Just one thing bugs me:

After making the new server available under the same URL (domain name) as the original Server, I was hoping the Devices (Clients) proceed working seamlessly. But this isn’t the case – instead the authorization of all previously connected Desktop Sync clients and Android Devices got disrupted.

It is required to re-authorize (logon) them all. This is a serious issue, as it impacts all users and require manual action from them. No problem for me, but my wife is complaining and even worse my grandparents who life far away don’t know how to handle it…

In the “Settings” menu under “Security” I can see the Devices & sessions have been recovered (name and date is equal to how it is on the original server) but it seems the respective credentials (tokens?) are not functional, or the clients somehow identify and dislike it is not the original server.

Any idea how to avoid the disruption to the client devices in this scenario?

NC 19.0.1 on Ubuntu server (Nextcloud VM from Daniel Hansson)
Apache, Postgres, PHP 7.4

I don’t think it is possible if you start with a new Nextcloud installation.
A full backup would probably be the only way to preserve sessions tokens…

Thanks for the info @anon71540698. That’s a pity.

As a workaround - is it possible to configuren (force) the server and/or clients to only use the classic username/password authentication without Sessions/Tokens?

I believe there a timeout variable - number of (idle) seconds after which you are automatically logged out… It didn’t work at the beginning, but now reportedly is fixed

Also, this feature was announced as part of Nextcloud 19 but was not implemented

@anon71540698 do you, how to configure (force) the server / clients to only use the classic username/password authentication that was used in the past before this tokes mechanism has been invented?

Recover from a full backup as you suggested above isn’t always possible. Sometimes an existing Nextcloud needs to be shifted to new HW and/or a new major Linux version.

If the tokens cannot preserve when all files, config.php and database is recovered to the new machine, the only appropriate way is to renounce on the Token mechanism.

Really the aim is that Android and Desktop Clients don’t cry for reauthorization in this scenario. They shall proceed working seamlessly after the server recovery.

I understand what you are after and why you don’t want any disruption on the user-end while completely rebuilding the back-end… But I don’t know how to achieve this…

If you have the hardware, I’d recommend looking into running virtual machines.
They are the easiest to backup and restore. And most of the needed components can be free.
Including the Community version of the latest Veeam backup software (if you go VMware)…

The breakneck pace NC is releasing new versions is not very receptive to running the same version of the software for a long time anyway…

Thanks @anon71540698 I will try a post in the NC git forum.

BTW I’m using those VMs already and a restore is usually a mous cklick to apply last snapshot. But my current recovery use case is to migrate the Nextcloud from an old VM with Ubuntu 18, to the latest downloaded VM that is based on Ubuntu 20. I was hoping this can be done without disrupting the users, but it does not seem so…