Cloudron Forum

Will do, James. I have not been able to recreate the held lock issue. I was starting/stopping jobs a fair bit at one point, and can't... be precise about where in the backup cycle those cancellations happened that a cleanup might not have happened. I will watch for it in the future. When I said there was no RAM pressure, I meant that was true for the server. However, my jobs all had 1GB of RAM. Your suggestion clued me in; because that value must be set after you setup the backup job, I had never noticed it before... or, not realized how critical it might be. I have bumped them all to 6GB of RAM, and so far, I've been seeing backup successes. Barring the question below, I'd say we could close this issue. The lesson learned is that I need to provide my backup tasks more RAM. Because I have some RAM to spare, I'm going aggressive, and giving things 6GB. I did not attempt to settle on a smaller amount, for anyone who comes along after--- I just gave the tasks a limit that I considered to be "a lot" in this context. I still see some things like the errors below. The backup completes successfully, but I'm unclear why there would be errors like these sprinkled throughout the backup. Is the relative path full/snapshot/app_... actually correct? Or, should that be a full path (e.g. the base path I provided at setup time along with the relative path)? In the command that succeeds, it is a full path. Feb 13 16:11:00 box:shell filesystem: ssh -o "StrictHostKeyChecking no" -i /tmp/identity_file_d82bc09e-a419-4d60-84bf-95d631fd0ebb -p 22 user@nas.lan cp -aRl full/snapshot/app_c74efccf-d273-46c9-8afe-3fd427bb78c1 full/2026-02-13-210356-064/app_git.jadud.com_v1.37.4 errored BoxError: ssh exited with code 1 signal null Feb 13 16:11:00 at ChildProcess.<anonymous> (/home/yellowtent/box/src/shell.js:82:23) Feb 13 16:11:00 at ChildProcess.emit (node:events:519:28) Feb 13 16:11:00 at maybeClose (node:internal/child_process:1101:16) Feb 13 16:11:00 at ChildProcess._handle.onexit (node:internal/child_process:304:5) { Feb 13 16:11:00 reason: 'Shell Error', Feb 13 16:11:00 details: {}, Feb 13 16:11:00 stdout: <Buffer >, Feb 13 16:11:00 stdoutString: '', Feb 13 16:11:00 stdoutLineCount: 0, Feb 13 16:11:00 stderr: <Buffer 63 70 3a 20 63 61 6e 6e 6f 74 20 73 74 61 74 20 27 66 75 6c 6c 2f 73 6e 61 70 73 68 6f 74 2f 61 70 70 5f 63 37 34 65 66 63 63 66 2d 64 32 37 33 2d 34 ... 50 more bytes>, Feb 13 16:11:00 stderrString: "cp: cannot stat 'full/snapshot/app_c74efccf-d273-46c9-8afe-3fd427bb78c1': No such file or directory\n", Feb 13 16:11:00 stderrLineCount: 1, Feb 13 16:11:00 code: 1, Feb 13 16:11:00 signal: null, Feb 13 16:11:00 timedOut: false, Feb 13 16:11:00 terminated: false Feb 13 16:11:00 } Feb 13 16:11:00 box:storage/filesystem SSH remote copy failed, trying sshfs copy Feb 13 16:11:00 box:shell filesystem: cp -aRl /mnt/managedbackups/1ec6c6b4-7566-4369-b2ce-466968b00d5d/full/snapshot/app_c74efccf-d273-46c9-8afe-3fd427bb78c1 /mnt/managedbackups/1ec6c6b4-7566-4369-b2ce-466968b00d5d/full/2026-02-13-210356-064/app_git.jadud.com_v1.37.4 Feb 13 16:11:07 box:backuptask copy: copied successfully to 2026-02-13-210356-064/app_git.jadud.com_v1.37.4. Took 7.889 seconds

Hello @jadudm Always happy to help.

@tecbox thanks for the update!

@jdaviescoates yes, there was a sshfs backup bug and I think 9.0.14 and 9.0.15 had fixed for exactly this. Unfortunately, Cloudron has no way to "force update" a bugged release.

@girish Thank you very much for the info. I didn’t manage to reply earlier, but I saved the backup configuration again and the morning backup completed successfully. I’ll also try upgrading to 9.0.15.

@avatar1024 in the previous versions, one could change the backup format between tgz and rsync . We used to track the format of each backup (for restore from old backups to work). in Cloudron 9, you cannot change the backup format of a site once set. instead, you can just create a new backup site if you want another format. The migration code probably detected that you have backups in both formats. So, it would create two sites - one tgz and one rsync. That's what you are seeing .

@nebulon , per request: https://forum.cloudron.io/topic/14525/improving-user-experience-with-ssh-keys-for-sshfs-and-volume-mounts Many, many thanks. And, if I find anything useful, I'll update that thread. Or, this one, and cross-link.

@andreasdueren you're welcome, I forgot to post the Hetzner docs, they also have a bit of information on that. Speeds are fine, never had any issues with various kinds of media.

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.