remotePath must be a string

[3246]

What?! Why are error messages always unhelpfully vague

Also, can you make it easier to understand which fields are required?

[girish]

@3246 See https://forum.cloudron.io/topic/6920/issue-restoring-backup-remotepath-must-be-a-string . You have to re-install with cloudron-setup --version 7.1.4 . This is a bug in 7.2.0

[3246]

@girish ARGH! How can I upgrade my previous to 7.2.0?

[girish]

@3246 You have to update it manually at the moment. Settings -> Check For Updates . Unless, you have a reason to, don't update it yet. We released it for making some cloudron.io related changes. It is stable though.

[3246]

@girish sorry, still getting this error.

I have updated the source Cloudron to 7.2.0, run a backup and now try to import it to the destination.

Yet, the error persists. What else do I need to do?

[d19dotca]

I wonder if this is at all related in some way to the issue I had on Restore process of IPv4 must be a string error.
https://forum.cloudron.io/topic/6911/restore-cloudron-ipv4-must-be-a-string-when-using-static-ip-config/1

[girish]

@3246 This is a bug in 7.2.0 . You can apply this patch:

• Edit /home/yellowtent/box/dashboard/dist/js .
• Line 1677 has the restore function. Change backupId to remotePath
• There's a told of 3 places to replace - the function arguments and in the data object.
• Then, refresh restore UI in the browser and it should work.

    Client.prototype.restore = function (backupConfig, remotePath, version, sysinfoConfig, skipDnsSetup, setupToken, callback) {
        var data = {
            backupConfig: backupConfig,
            remotePath: remotePath,

[3246]

@girish thank you.

To clarify:

I edit /home/yellowtent/box/dashboard/dist/js/restore.js and replace backupId with remotePath?

Is there a way you can make that patch available for me to just pull from git or elsewhere?

[echokos]

@girish This isn't working. Trying to move servers - have a 7.2.0 backup and installed at Hetzner with version 7.2.0. The restore path properly fills in from the backup, but cannot get around the "remotePath must be a string" error message even after editing the function mentioned in restore.js and rebooting the server.

EDIT: Nevermind. I've reverted everything to using 7.1.4 and it was fine. I saw your note on the top of this to force the new server to install 7.1.4 but I had been doing the opposite and using 7.2.0.

[girish]

@echokos ah, glad you got that sorted out.

We will get out 7.2.1 in a few days to fix these regressions.

[mikewen8888]

@echokos said in remotePath must be a string:

@girish This isn't working. Trying to move servers - have a 7.2.0 backup and installed at Hetzner with version 7.2.0. The restore path properly fills in from the backup, but cannot get around the "remotePath must be a string" error message even after editing the function mentioned in restore.js and rebooting the server.

EDIT: Nevermind. I've reverted everything to using 7.1.4 and it was fine. I saw your note on the top of this to force the new server to install 7.1.4 but I had been doing the opposite and using 7.2.0.

@echokos what do you mean by reverted everything using 7.14?

did you revert old server to 7.1.4 and take a backup?
or did you use 7.2.0 backup and used it on 7.1.4 new installation?

i have 7.2.0 backup today from 7.2.0 server, and try to simulate restore process, having on different server (install it today, so I assume it is on the same version, but get that remotePath must be a string problem

already did what @girish said about replacing those 3 backupId into remotePath, but the problem persist

btw: how to check cloudron version? in GUI or CLI?

[mikewen8888]

@girish said in remotePath must be a string:

@echokos ah, glad you got that sorted out.

We will get out 7.2.1 in a few days to fix these regressions.

@girish any time line for 7.2.1 release? If soon I probably wait the restore simulation process until this bug is fixed

[girish]

@mikewen8888 Yes, it's due for next week. Probably around tuesday. Sorry for the bug!

[ajtatum]

Just to let anyone else know, I ran into the same issue with 7.2.0 when migrating servers and made the change that @girish mentioned and it still didn't work until I restarted docker (systemctl restart docker) and then it worked!