SSHFS: "failed to mount (inactive): read: Connection reset by peer"

[CRBear]

Thank you for the prompt response.

Which backup method is currently recommended by Cloudron?

Are there any other backup methods planned for future updates?

Alternatively, DIY solutions are possible, such as mounting an FTP storage using curlftpfs, although I would prefer a ready-made solution.

Thank you!

[girish]

@CRBear Ideally , some object storage is the best. Maybe minio is an option ? Note that when using it for backups, you have to host the minio in a separate server (i.e not on the same Cloudron itself).

[CRBear]

Thank you for the quick response. I am familiar with Minio, but as you mentioned, it requires an additional server, which I would prefer not to use for the current project. Therefore, it would be great if the existing web hosting could serve as a (automatic) backup solution.

[girish]

@CRBear One of the goals of a backup is to be able to recover if the server fails. If the backups are on the server itself, you could lose everything.

What did you mean by "existing web hosting" ? Are you refering to Cloudron server here? Of course, you can always use "Filesystem" backend and backup to "/var/backups" of the Cloudron server itself. But please understand the implications above.

[avatar1024]

I hit the same error yesterday when trying to restore the server from backup config file (I moved my Cloudron to a new server).

For it to work I had to connect to CIFS.

Weirdly now, in the restore server, the same storage box connects fine as SSHFS for volumes (and I didn't do anything, Cloudron just restored my Volume config).

So personally, I think there is a bug somewhere in Cloudron that prevents mounting SSHFS for backup on Server restore, because mounting as SSHFS works fine otherwise.

[avatar1024]

Hello, I'm still facing the issue of not being able to mount my storage box via sshfs for backups (still getting the same error). I can't see anything in the logs.

The same box mounts fine with sshfs for Volumes though.

This is now problematic as the box is currently mount via CIFS for backups, and backups are regularly failing. I have to click the remount button (weirdly the light is still green so it still looks connected and functional, but I need to click the remount button nevertheless).

[girish]

@avatar1024 In the next release, we will add a automatic remount before taking a backup. Until then, you have to do this manually.

There is no kernel support to remount automatically afaik. For some reason, the CIFS is not stable on your network, these can be hard to debug but maybe dmesg output has some ideas?

[avatar1024]

@girish Sounds great, thanks Girish. I can live with that until then with the CIFS issue. Next time it happens I will dmesg just in case I see something.

Any idea about the SSH problem though?

[avatar1024]

@girish said in SSHFS: "failed to mount (inactive): read: Connection reset by peer":

For some reason, the CIFS is not stable on your network

While this may be true, the odd thing is that Cloudron seems to think it's fine (green light). Isn't Cloudron supposed to periodically check the support is mounted?

[girish]

@avatar1024 I might have misunderstood the problem then. In the original bug report, which I realize now was not created by you, the user got Connection reset by peer . In your case, it's green light. Did you get that error message then? What was the error message?

[avatar1024]

@girish Sorry issues might be getting mixed up. I'll try to clarify here.

1. when I try to connect by sotrage box for backup using SSHFS I get the same error as in this thread (even though the same box is connected via SSHFS in Volumes, so the issue is only there for backups).

2. Since I cannot backup via SSHFS, I tried mounting with CIFS. With CIFS it works for a few days and then I get backup error message:

Backup failed: copy exited with code 1 signal null.

When I go and check nothing seems wrong, and the storage box still looks mounted (green light) but I still need to press the remount button for backups to work again.

[avatar1024]

As I wrote the above I had a thought. I tried another SSH key to mount the backup storage as SSHFS (one that was also an authorised key in the box) and it worked!

• The key that does not work is in format Ed25519 (weird because that key format is supported but the Storage Box and by the server as I can ssh into both with it). @girish, does Cloudron has issues with Ed25519? Even though I know when you tried here it worked.

• The key that worked was in format RSA

@CRBear what kind of key are you using?

@girish problem solved on my end for SSHFS. The CIFS issue remains a mystery, but who cares

[girish]

@avatar1024 ed25519 support comes from the underlying libraries of Ubuntu. Maybe old versions didn't have support it? I remember they didn't work in ubuntu 18 out of the box atleast. This is why our support keys were using the older format as well. Just a guess, in case you want to track this down.

[girish]

I couldn't find anything specific in upstream sshfs repo atleast - https://github.com/search?q=repo%3Alibfuse%2Fsshfs+ed25519&type=issues

[avatar1024]

Thanks @girish for looking into this. This server is on Ubuntu 20.04.3 (fresh install from Netcup done recently). Also I can directly ssh into both the server and the box using that key, mounting only fails on Cloudron for some reason.

I guess it's not the end of the world and it might be an issue only in my instance, but you know that at least one user has had that problem (though it might have been the issue for the person who created that threat) in case more people report it

[avatar1024]

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:

1. rsa with paraphrase
2. ed25519 with paraphrase
3. rsa without paraphrase
4. 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:

1. and 2. didn't work >> expected as paraphrased is required
2. worked just fine
3. 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