Restoring from backup error: self-signed certificate
-
@KS said in Restoring from backup error: self-signed certificate:
@john-c said in Restoring from backup error: self-signed certificate:
You don't think that it's certificate can interfere but the SMB and/or NFS protocol support digital signing and/or encryption of the connection when configured. So depending on its settings and/or default settings of that QNAP NAS it may be encrypting the connection. Thus putting into place its self signed certificate!
I'm sure that's a possibility, I'm just not sure that's the reason because I haven't had issues with that QNAP - we use Veeam for backup and restore to that QNAP with no issues at all. Also, the log I posted above makes no mention of the QNAP server, by name or by IP, at all.
Those two reasons are why I'm leaning more towards it being a certificate issue with the XCP-ng server and/or the XOA VM.
Does Veeam or any other devices have the self-signed certificate added in a way that it would be trusted or has an certificate error exception been added to any device which connects to Veeam or that QNAP NAS?
Just something to consider as this will cause the certificate error to not appear when connecting to that address. Thus if this was done by someone other than you and it wasn't noted down anywhere then the error won't appear and you won't even know.
-
Hello All,
I'm having a similar issue after upgrading from 8.2.1 to 8.3 Beta 2 in my home lab.
Steps performed prior to backup ..
- Full VM backup to TrueNAS and exported XO config json.
- Upgrade XCP-ng host using the 8.3 Beta 2 ISO
- Updated XO to latest version and imported XO config json.
Tried a VM restore from TrueNAS backup and I'm getting the
"self-signed certificate" error. -
@Ismail said in Restoring from backup error: self-signed certificate:
Just an update, the restore worked on the older version of XO which was about 21 commits behind. Current XO version ...
-
Hey @Ismail
Could you please tell me what version of XO the restore worked in? I'm currently on 6c160 which it says is 4 commits behind. I would like to try that out to see if it solves my issue as well.
Thanks
-
Hello @KS unfortunately I deleted the older XO vm, before making a note of the version, and proceeded to upgrade to the latest.
-
@Ismail No worries! Follow up question then, does the restore still work after you've updated to the latest version?
-
@KS Nope, I did one successful restore and then assumed all was good and proceeded to upgrade XO. By the way I'm using Ronivay's XO vm image from https://github.com/ronivay/XenOrchestraInstallerUpdater
-
Same issue on my host, with commit 8e5d9.
I tried the health check, and it is stuck.
I do not see any error message, the log just says pending.I tried a restore check with XOA 5.91.2, no issue on that side, only XO from source seems to be not working.
-
Thanks for your reply. Seems like this might be a bug with the latest version of XO from sources.
I'm trying to use the XO script by Ronivay to install an older branch to see if that solves this issue. In the xo-install.cfg file there is a "BRANCH" variable and it says you can specify a commit number, but that doesn't seem to working for me. I'm sure I'm formatting it incorrectly. Thoughts?
Tried both:
BRANCH="6056a61" BRANCH="6056a618c3e503fcc0de4fe19007574e40bfddd5"Thanks.
-
Same issue here with the latest XO
I tested restore from Qnap with NFS, and there were no errors it's just stuck in tasks with no movement and no way to cancel.
If it helps everything is with default self-signed certificates.
Backups run with no issues, just something with the restore. -
Same issues with restoring on the current commit, but rolled back 21 commits (6056a) and it works again.
-
Same here. I was able to install the same Commit and it works now with the pre-installed certificates.
This appears to be a bug in newer commits.
-
Hi @KS I use Ronivay's precompiled VM which only deploys the latest build. I will have to look into this install script to compile a previous build of the vm. Will let you know if I get it working.
-
Same here, its definately a bug because I was able to do a backup and restore just last week.
I upgraded to the latest 2 days ago and now backups are broken, same version here:
-
I can confirm that in the community edition, something between 0ccfb4b and 8e5d9 breaks restoring to hosts with self signed certs.
I had to try and restore a couple of VMs after the upgrade to 8e5d9 and despite a couple of attempts to compile previous commits and see if they would work, nothing did until I reached 0ccfb4b.
Once I had rolled it back that far, the restores were no longer stuck at 0% and there were no problems restoring any of the backups that I tied.
-
Someone else on this forum is having trouble with self-signed certificates. So this issue must be more general than just self-signed certificates when restoring backups.
It must be a bug introduced recently which is specifically when handling self-signed certificates generally.
https://xcp-ng.org/forum/topic/8636/self-signed-cert
Others with this issue is the link shown above similar to what you are experiencing with backup restoration?
@florent Can you please check this out there may be a bug in Xen Orchestra which is affecting the handling of self-signed certificates generally? As it's affecting not just restoration of backups but also the creation of new VMs as well.
-
@john-c
"Someone else on this forum is having trouble with self-signed certificates. "Unfortunately, this function does not work either.
márc 18 14:13:12 xoa xo-server[22559]: 2024-03-18T13:13:12.703Z xo:api WARN bogi.kornel | backupNg.importVmBackup(...) [184ms] =!> Error: self-signed certificate -
For those finding this post and are using ronivay's XenOrchestraInstallerUpdater, the solution is as follows...
Edit xo-install.cfg with your favourite editor.
Look for the line...
BRANCH="master"
Comment it out and and on a new line add...
#BRANCH="master"
BRANCH="0ccfd4b"If you then run the script and choose 2) Update, it should work.
Because I was in a hurry, I deleted the /opt/ox directory, put the SSL certs that were in it back, and then ran 1) Install so that I knew that I was certain that there were no conflicts with compiling and older version.
But either method should work.
-
@KS Did you try running "xe task-list" to identify the process and then "xe task-cancel force=true uuid=(UUID-of-process)"?
-
@StormMaster thank you. This workaround did exactly what i needed.
