My Hetzner Storage Box Volumes and Backup locations needed remounting post upgrade to 8.0.3

[jdaviescoates]

I think this has happened with previous updates too.

Just clicking on the relevant remount buttons worked fine to get everything working again (edit: post remounting I also had to restart the apps that were using the Volumes as storage before the apps started working properly again), but I still wonder why it happens and why the remounting isn't automated @staff?

[uwcrbc]

Just to confirm that this is not an isolated case, since the same happened to some (not all) of my box.
Solution was indeed to remount the backup storage manually.

Should this help, I have had it happen with v8 and v8.0.2 so far, on multiple servers, but only with Hetzner storage box.

[nebulon]

It is not clear yet, why the mountpoint goes bad sometimes. Do you have any more info from the system/kernel logs around that timeframe for that mountpoint?

[lucidfox]

I've got the same issue on version 8.0.3, but have not been able to remount my Hetzner Storagebox via CIFS or the volumes on the same storage box via SSHFS. @staff any suggestions how to fix this?

[joseph]

@lucidfox can you check if DNS is working on the server? Try to resolve the hostname of the storage box on the server.

[lucidfox]

@joseph i'm able to ping the storagebox succesfully from the cloudron server as well as my local machine.

[lucidfox]

i've been able to remount the backup and storage volumes now, it must have had to do with the Hetzner DNS outage. Thanks for your help @joseph

[uwcrbc]

Hi all,
I am coming back to this since one of my server updated about 3 days ago to from v8.0.3 to v8.0.4 and the same happened.
Upon updating the back to Hetzner storage box failed until manually remounted.

I do not see this as a DNS issue - the remount just work fine
I also do not see this as a Hetzner issue - the pattern is fairly clear: it happens every time there is a cloudron update since v8.0.0 (I think).

Not a massive issue since the remount does the trick.
But as the failing notifications are only sent over email after 3 fails, it can potentially lead to a fair amount of backups being missed.

@any ideas?

[joseph]

So, the mounting is handled by the kernel and Cloudron as such has nothing to do with stability of the mount. Cloudron is really just a user space program.

You can find the mount systemd file in one of the mount files in /etc/systemd/system/*.mount . Maybe you can look for hints in dmesg (but often unmount information logs is not there)