Cannot add Hetzner Storage Box via sshfs

[ekevu123]

I have set up a Hetzner storage box and I am trying to use it as the main backup location for Cloudron, but it fails with this error:

Failed to mount (inactive): Could not determine mount failure reason.

This is what I have done:

1. I have created an ssh key on the cloudron server
2. Added it to Hetzner into .ssh
3. Connected to Hetzner via "ssh -p 23 uXXXXX@uXXXXX.your-storagebox.de"
4. Verified that /home is writable

For the cloudron backup setup:

• hostname: USER.your-storagebox.de
• remote directory: /home
• port: 23
• user: Hetzner user id
• private key inserted
• use hardlinks checked

This was in the Cloudron server logs:

Mar 02 15:57:55 box:shell mounts: mountpoint -q -- /mnt/backup-storage-validation
Mar 02 15:57:55 box:shell mounts: mountpoint -q -- /mnt/backup-storage-validation errored BoxError: mountpoint exited with code 32 signal null
Mar 02 15:57:55 at ChildProcess.<anonymous> (/home/yellowtent/box/src/shell.js:72:23)
Mar 02 15:57:55 at ChildProcess.emit (node:events:519:28)
Mar 02 15:57:55 at ChildProcess.emit (node:domain:488:12)
Mar 02 15:57:55 at maybeClose (node:internal/child_process:1105:16)
Mar 02 15:57:55 at Socket.<anonymous> (node:internal/child_process:457:11)
Mar 02 15:57:55 at Socket.emit (node:events:519:28)
Mar 02 15:57:55 at Socket.emit (node:domain:488:12)
Mar 02 15:57:55 at Pipe.<anonymous> (node:net:339:12) {
Mar 02 15:57:55 reason: 'Shell Error',
Mar 02 15:57:55 details: {},
Mar 02 15:57:55 stdout: <Buffer >,
Mar 02 15:57:55 stdoutLineCount: 0,
Mar 02 15:57:55 stderr: <Buffer >,
Mar 02 15:57:55 stderrLineCount: 0,
Mar 02 15:57:55 code: 32,
Mar 02 15:57:55 signal: null
Mar 02 15:57:55 }

A similar thread recommended to check whether unbound was working, which I checked like this:

systemctl status unbound

I would appreciate assistance with this as the error doesn't give me anything else, it seems.

[jdaviescoates]

@ekevu123 said in Cannot add Hetzner Storage Box via sshfs:

created an ssh key on the cloudron server

Did you remember not to use any passphrase?

[ekevu123]

No, I didn't, that solved the issue!
And I just came to the same conclusion and came here to update this thread. Thank you for pointing this out!

[BrutalBirdie]

Give a minute, I have many storage boxes and sub-account and use them for Cloudron.

---

This is working for me and has worked for years.
Here is also my Hetzner overview of the storage box.

---

If you'd like @ekevu123 we can take a look together.
Send me a dm if want to do that.

[jdaviescoates]

@BrutalBirdie it was just that he'd added a passphrase to the SSH keys

@ekevu123 having done it a few times myself now (for backups and various volumes) it looked like you'd done everything right so that was the only thing I could guess it could've been - glad it was that and it helped

[ekevu123]

Yes, exactly, it works now!

Maybe there could be a dedicated tutorial in https://docs.cloudron.io/backups/ as many people seem to use it as a backup provider. I had to look up a few other things in the process to make it work.

[SansGuidon]

I also used a passphrase the first time I had to setup hetzner storage via sshfs, for me it's a best practice so I always put a passphrase.

[BrutalBirdie]

Ahhh.
I did not expect that

[potemkin_ai]

Have the same issue, error logs seems to be the same pretty much:

<...>
errored BoxError: mounts exited with code 3 signal null
    at ChildProcess.<anonymous> (/home/yellowtent/box/src/shell.js:137:19)
    at ChildProcess.emit (node:events:519:28)
    at ChildProcess._handle.onexit (node:internal/child_process:294:12) {
  reason: 'Shell Error',
  details: {},
  code: 3,
  signal: null
}
2025-04-10T11:37:24.641Z box:shell mounts: mountpoint -q -- /mnt/backup-storage-validation
2025-04-10T11:37:29.648Z box:shell mounts: mountpoint -q -- /mnt/backup-storage-validation errored BoxError: mountpoint exited with code null signal SIGTERM
    at ChildProcess.<anonymous> (/home/yellowtent/box/src/shell.js:72:23)
    at ChildProcess.emit (node:events:519:28)
    at maybeClose (node:internal/child_process:1105:16)
    at ChildProcess._handle.onexit (node:internal/child_process:305:5) {
  reason: 'Shell Error',
  details: {},
  stdout: <Buffer >,
  stdoutLineCount: 0,
  stderr: <Buffer >,
  stderrLineCount: 0,
  code: null,
  signal: 'SIGTERM'
}

SSH key comes without password, and I can connect via SSH - no problems:
ssh -p23 u1212121@u1212121.your-storagebox.de -i hetzner

I've tried to pick up systemd file for troubleshooting, but I didn't find any in the system - guess it's removed if no luck connecting.

Any help would be much appreciated!

[andreasdueren]

@potemkin_ai Did you specify /home as Remote Directory?

[potemkin_ai]

@andreasdueren sure!

[andreasdueren]

@potemkin_ai Looks like it might be a networking issue. Is the storage box responding to a ping if you ping it from the server? The SIGTERM suggests the command timed out waiting for a response, indicating the storage device might be unresponsive or inaccessible.

[BrutalBirdie]

@potemkin_ai
Be aware, Hetzner Storage Box via port 23 sshfs has fail2ban.
After some attempts you get blocked for some time.

@potemkin_ai can you test if these steps work:
https://forum.cloudron.io/post/105362
Test it locally and on your server.

[potemkin_ai]

Like I've told:

I can connect via SSH - no problems:
ssh -p23 u1212121@u1212121.your-storagebox.de -i hetzner

=> not a networking issue and 23 port works fine.

Looks more like a SW bug to me: https://forum.cloudron.io/topic/13634/addmount.sh-script-error-prevents-sshfs-mount

[potemkin_ai]

@potemkin_ai can you these steps work:
https://forum.cloudron.io/post/105362

It looks like the following option is missing to make sshfs actually work with SSH keys authorization:
-o IdentityFile=hetzner_storage_box

But yeah - it works.

According to the Cloudron logs, the failure is happening not while trying to mount, but at the stage of mounting - as the parser fails to extract 'Where' (instead of just getting it as an input, for example).

[potemkin_ai]

and nc -vv u12121212.your-storagebox.de 23 from the server - does not

@BrutalBirdie , as stupid as it could be - I might get trapped with Hetzner's fail2ban - thanks for pointing that out.

[potemkin_ai]

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.