SSHFS: "failed to mount (inactive): read: Connection reset by peer"
-
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).
@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
dmesgoutput has some ideas? -
@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
dmesgoutput has some ideas?@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 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
dmesgoutput has some ideas?@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 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?
@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 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?@girish Sorry issues might be getting mixed up. I'll try to clarify here.
-
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).
-
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.
-
-
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
-
-
@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.
-
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
-
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
