Cloudron Forum

My issue is resolved, adding a --allow-other parameter to the mount solved it, thanks @girish and @joseph

Hello @djxx You can find that file in the systemd mount file for the Cloudron backup. systemctl status mnt-cloudronbackup.mount ● mnt-cloudronbackup.mount - cloudronbackup Loaded: loaded (/etc/systemd/system/mnt-cloudronbackup.mount; enabled; preset: enabled) Active: active (mounted) since Sat 2025-05-17 07:04:02 UTC; 2 weeks 1 day ago Where: /mnt/cloudronbackup What: REDACTED@REDACTED.your-storagebox.de:/home Tasks: 11 (limit: 9212) Memory: 9.9M (peak: 18.1M swap: 2.5M swap peak: 11.1M) CPU: 25min 37.199s CGroup: /system.slice/mnt-cloudronbackup.mount ├─ 905 /sbin/mount.fuse.sshfs REDACTED@REDACTED.your-storagebox.de:/home /mnt/cloudronbackup -o rw,allow_oth> └─9487 ssh -x -a -oClearAllForwardings=yes -oport=23 -oIdentityFile=/home/yellowtent/platformdata/sshfs/id> Notice: journal has been rotated since unit was started, output may be incomplete. So the file in question would be: /etc/systemd/system/mnt-cloudronbackup.mount

@humptydumpty Thanks for your interesting info's. I'm looking around to find an alternative to iDrive e2. After more than 4 days they still didn't give me any infos or updates about what happened...

I will close this for now since it's not meant to be run directly . We can continue in the other thread or we can open a new thread .

It was not fail2ban - it was IPv6 connection which is failing, as IPv6 disabled (to ensure mail works well). Hetzner's supported provided a very quick and efficient verification / troubleshooting step: ssh -vvv -p 23 user@server - hope that will be of use for anyone else in the future.

@nebulon Not so clear. The volume disconnected again. The "Remount Volume" button did not help but "Edit Volume" and saving (unchanged settings) worked.

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. [image: 1725653970393-0f6f30c7-0b4f-4950-8928-5680b69c2a11-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