Backup failed | Backup endpoint is not active: Could not determine mount failure reason. | Failed to mount (inactive): Could not determine mount failure reason.

[nebulon]

Ah this is a good start then. So Cloudron places a mount file for systemd at /etc/systemd/system/mnt-cloudronbackup.mount You should see the mount options there, compare those with the working ones from your fstab file. Do you see any difference there which could produce the issue?

You can also change that cloudronbackup.mount file for testing and afterwards run systemctl restart cloudronbackup.mount to test this.

[OneTools Project]

One question. I just saw in the backup configuration that there is a " : " added behind the IP address. Do I need to indicate a port number?

[nebulon]

Can you be a bit more specific to what you are referring to here? Maybe you could share some of those config files (with the personal information redacted)

[OneTools Project]

[nebulon]

ah here, that is just an info display. It would help if you could share your working fstab file content though.

[OneTools Project]

Ok. Here is the file content (with modified data).

//11.222.333.444/FolderName /home/user/FolderName cifs credentials=/home/user/filename,iocharset=utf8,file_mode=0777,dir_mode=0777 0 0

[nebulon]

And what was rendered in your case into /etc/systemd/system/mnt-cloudronbackup.mount to see what the difference is. Both in the end will run the same mount command and if one works and the other does not, there is probably some difference between the two config formats.

Also have you already tried to run systemctl restart -u mnt-cloudronbackup.mount and looked at the logs with journalctl? Most likely this will also show some error hinting at the root cause. In the end it may just be a typo or so

[OneTools Project]

I tried modifying the mnt-cloudronbackup.mount with all sorts of different information. I copied and pasted the same values to the file as they are in the fstab file but no luck.
I tried the systemctl restart mnt-cloudronbackup.mount command but also without any luck.
I tried as well to empty the data from the mnt-cloudronbackup.mount file and then save the settings again via the Cloudron Backup interface. What I find strange is, that the file was not updated and stayed empty.

I opened journalctl but the data starts on october 15th and is packed so going trough till I see the data from today would take me a while.

[nebulon]

Maybe to avoid further back and forth here, if you want enable remote SSH support for us and send us a mail to support@cloudron.io with all the information about your cifs share, then we can test this ourselves. Might be faster to debug the root issue then.

[nebulon]

This was resolved via support. For some reason unbound was not running. Restarting that made the backup storage work again (we may have a wrong configuration, where unbound is a systemd dependency for the storage mount, which seems like not needed anymore)

[SansGuidon]

I just had the issue while attempting to migrate to a new Cloudron restore, at the step of restoring a full backup and this despite following exactly the steps in Cloudron guide for restoring backups.

I quickly solved it through:

• Reviewing unbound service status shows everything looked ok
• I had a doubt about the private key password being good, as the backup configuration didn't clarify that in the UI.
• I just put my private key password again, and attempted the restore button, this time it works.

So it's good to mention maybe in the guide that the private key password should be double checked even if using a preexisting backup configuration generated from the previous Cloudron instance.