Backup failed | Backup endpoint is not active: Could not determine mount failure reason. | Failed to mount (inactive): Could not determine mount failure reason.
-
Hello.
Since several day my backup is not working anymore.
On the 14th Cloudron was updated to V8.0.6 and from the 15th the backup is not working.
I use a CIFS Mount with the IP address of my NAS server and a directory. Up until the 15th the backup was running fine, so the settings should be correct.When I save the settings now, I get the error "Failed to mount (inactive): Could not determine mount failure reason. "
I found this in the log:
box:shell getStatus: mountpoint with args -q -- /mnt/cloudronbackup errored Error: Command failed: mountpoint -q -- /mnt/cloudronbackup
at genericNodeError (node:internal/errors:984:15)
[no timestamp] at wrappedFn (node:internal/errors:538:14)
[no timestamp] at ChildProcess.exithandler (node:child_process:422:12)
[no timestamp] at ChildProcess.emit (node:events:518:28)
[no timestamp] at maybeClose (node:internal/child_process:1105:16)
[no timestamp] at ChildProcess._handle.onexit (node:internal/child_process:305:5) {
[no timestamp] code: 32,
[no timestamp] killed: false,
[no timestamp] signal: null,
[no timestamp] cmd: 'mountpoint -q -- /mnt/cloudronbackup'
[no timestamp] }
Oct 24 01:00:17 box:shell getStatus exec: journalctl -u $(systemd-escape -p --suffix=mount /mnt/cloudronbackup) -n 10 --no-pager -o json
Oct 24 01:00:17 box:shell remountMount /usr/bin/sudo -S /home/yellowtent/box/src/scripts/remountmount.sh /mnt/cloudronbackup
[no timestamp] dependency job for mnt-cloudronbackup.mount failed. See 'journalctl -xe' for details.Can anybody help me out here?
-
This means the system was unable to mount the storage. This is likely some setup issue. Cloudron uses stock linux tooling for mounting remote filesystems, so a first step would be to mount it without Cloudron and then we can check what the difference in mount parameters are to see if we can improve here. You should be able to get more info here using
journalctl
-
Hi. I can mount the folder via the fstab file. Unfortunately I'm not a big Linux pro and I don't know what you need from the journalctl.
-
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 runsystemctl restart cloudronbackup.mount
to test this. -
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?
-
-
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
-
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 samemount
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 withjournalctl
? Most likely this will also show some error hinting at the root cause. In the end it may just be a typo or so -
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.
-
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.
-
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)