Cloudron Forum

Alright something is off for sure it seems. A bit out of ideas. Have you managed to get the mountpoint working without Cloudron using sshfs directly? sshfs is usually quite a good option and most likely there is just some small detail off somewhere. If you get it to work using linux tools directly we can most likely check the difference, as Cloudron only really just generates a config file for systemd to mount it via sshfs. There is not much specific to Cloudron.

Hi,

I finally got it working on Strato storage via SSHFS.
Here are the specifications:

OS: Ubuntu 24
Cloudron 8
SSH key: RSA

I have disabled hard links.

Schermafbeelding 2024-08-31 221452.png

Sounds good! It was also odd that some other apps were affected by the restart-looping Nextcloud instances.

Hey @girish, @nebulon, thanks for coming back to me so quickly!

Happy to report that the fix worked wonders, and the backup completed successfully.

As for our setup, we set up the backup server a while ago now, my memories are not the freshest. But IIRC we are using OpenSSH Server for Windows Server.
And from what I can see Windows shell uses mklink to create hard links. But I have never used it.

@BrutalBirdie said in Volumes error on access but work? kinda?:

Getting the picture?

Yes! Excellent

A little update on this:

I help a friend migrating their cloudron to another server and set-up a new backup storage (also using a Hetzner storage box).

Server migration worked fine (that was not using the Hetzner box).

When it came to connect the new storage box we faced issues.

We generated 4 pairs of ssh keys:

rsa with paraphrase ed25519 with paraphrase rsa without paraphrase ed25519 without paraphrase

With all four we could connect to the storage box from outside cloudron (using terminal or from file manager). 1. and 2. required the paraphrase to do so.

On Cloudron:

and 2. didn't work >> expected as paraphrased is required worked just fine if trying to connect to the box by created a new volume or a new backup storage the connection failed as reported above in this thread. BUT if the volume or backup storage was already present and mounted (using key 3.), then I could go to the settings and replace key 3. by key 4. and then it connected fine.

Maybe this description might help tract where the issue comes from, since it only happens when mounted a new valume/backup and not when it's already present 🙂

This is a Cloudron related forum. I know you posted this in the off topic section, but still I am not exactly sure what you are asking for.

@dylightful Something definitely happened on Cloudron side and It's hurting me in full swing, I'm having a hard time to find the origin of this, it does not make any sense.

current operations at osintukraine.com are fully impacted, each of our telegram archive are now disconnected from their volume, already tried to clean start, new mounts, clean start, same problem.

Right now I'm trying to add a new sshfs volume, the target is empty, i'm still having this exact same error, I'm wondering if there isn't anything else going on here because nothing make sense.

Ah, thanks for reporting. I have opened https://git.cloudron.io/cloudron/box/-/issues/808 internally .

Just purge contents of the folder or delete the folder and recreate it with the same permissions. Other bits of Linux sometimes put logs there.

@girish Thanks!

@girish I haven't done the steps you suggested yet, I just reverted back to my Scaleway backups. But I will try again shortly. Thanks for checking in.

@rmdes I ended up setting up a local backup for Cloudron and use RClone to handle the backup. I've used RClone for years with no issue, and since going this route, no issues with my Cloudron backup.

@mazarian that's correct, the permission is the thing I fixed in 6.3.5. Glad it's working now and thanks for reporting back!

@nebulon Yes before rebooting I tried to umount-remount but it seems it has been impossible due to an error... So I decided to restart.

About auto-remounting it will be an amazing feature

@girish Sounds great, thanks Girish.

@rlp10 there is no clear cut between which backup target is preferred. We try to cover a few options to cover a range or use-cases, but all should work.

If you own the backup machine, I would anyways not advise to encrypt backups. Unencrypted files on trusted storage is a lot easier to restore if worst case trouble hits 🙂

@nebulon That did the trick, thanks a lot again.

@ultraviolet Glad I could help...👍