Cloudron Forum

@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 .

For me. It's silly. All the guide is out of date. With new created storage box, there isn't sub dir and ssh pub key is not yet allowed in storage box and storage box's pub isn't in my pc known_hosts, I have to add my pub key to storage and run sshfs command once time to get pub key of storage box. So because of new user without subdirectory, the "remote dir path" after colon should be RELATIVE path or empty "" in this case not "/". uxxxxxx@uxxxxxx.your-storagebox.de: /mnt/local/mount/path -o port=23,IdentifyFile=/home/username/.ssh/id_rsa ....

@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...👍