Closed Didel closed 1 year ago
Just started using this add-on, and stuck with exactly the same issue.
Same issue from the container itself:
# docker exec -it bc4a19d237cc bash
root@3490a758-remote-backup:/$ echo bar > foo
root@3490a758-remote-backup:/$ scp foo hass@1.1.1.1:/remote/path
The authenticity of host '1.1.1.1 (1.1.1.1)' can't be established.
ED25519 key fingerprint is SHA256:c+JgqGL6VR//9w8FLgCTVKR4VXMoVh7pviryobBtzyU.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '1.1.1.1' (ED25519) to the list of known hosts.
subsystem request failed on channel 0
scp: Connection closed
Mmm if I add the -O
it works
-O Use the legacy SCP protocol for file transfers instead of the SFTP protocol. Forcing the use of the SCP protocol may be necessary for servers that do not implement SFTP, for backwards-compatibility for particular filename wildcard patterns and for expanding paths with a ‘~’ prefix for older SFTP servers.
Fixed it on the target machine :) My target is a Synology by enabling SFTP it started to work.
Same here with Synology NAS, but SFTP is already activated....
[info] Adding SSH key [info] SSH key added [warn] Creating local backup: "Automated backup 2022-08-13 22-54" [info] Creating full backup [info] Backup created: 143cb85d [warn] Copying 143cb85d.tar to /volume1/homes/XXXXXXX on 10.10.X.X using SCP Warning: Permanently added '10.10.X.X' (ED25519) to the list of known hosts. subsystem request failed on channel 0 scp: Connection closed s6-rc: info: service legacy-services: stopping s6-rc: info: service legacy-services successfully stopped s6-rc: info: service legacy-cont-init: stopping s6-rc: info: service legacy-cont-init successfully stopped s6-rc: info: service fix-attrs: stopping s6-rc: info: service fix-attrs successfully stopped s6-rc: info: service s6rc-oneshot-runner: stopping s6-rc: info: service s6rc-oneshot-runner successfully stopped
I have the same problem and partly fixed it with turning on sftp. The backup now gets transfered, but it doesn't get renamed. i guess it's because it's transfered via sftp (different home/base dir: /Netbackup/hassio) and than it tries to rename it via ssh cmd. The ssh command can't find the file (because its on a different level: /volume1/Netbackup/hassio) Could you please build in a config flag so I can choose if I want to use ssh or sftp ? Thanks :)
You can the latest branch in my fork https://github.com/patman15/remote-backup-addon/tree/improve-error-handling / wait for the PR https://github.com/ikifar2012/remote-backup-addon/pull/59 to be merged. The renaming issue should be fixed there. I tested it with the path /volume1/Netbackup/hassio.
For me (OP) the problem was indeed resolved by enabling SFTP on the NAS. I’m keeping this issue open though, as I feel like it should not be a requirement (it used to work perfectly fine without SFTP enabled) , but more something like an encouraged default setting. #59 appears to contain some good improvement already, many thanks to @patman15 !
I understand the request for supporting SCP (as I have the same issue myself), but the main reason it does not work is a change in the scp
command itself for security reasons toward SFTP as a default. scp
does not receive any security updates starting with e/o 2019. For details, please see Deprecating scp or OpenSSH 8.0.
I wouldn't recommend to implement the -O
option into this add-on for the reason of security as well as there are already plenty of configuration options that are confusing. Anyone who knows what he/she is doing, can still simply add the option in the code as it is a really minor fix. Also I guess that @ikifar2012 is looking into moving over to rclone to support even more methods. Just my 2 cents, last word always has the author of this add-on. :-)
I agree with @patman15 because I did not know that this was a security problem with scp. So ignore the flag idea ;)
I too am having the Synology issue, however unlike @Didel, I already had SFTP enabled on my NAS
I have always seen SCP and SFTP referred to as the same thing, After reading about the deprecation, I do think it is a good idea to switch to SFTP, although I am not 100% certain if that will break anyone's config. However, we do have a ton of changes coming in thanks to @patman15.
I am thinking if SFTP fixes this issue we might want to switch now. I will test it with the SFTP command to see if the issues are resolved
Also I guess that @ikifar2012 is looking into moving over to rclone to support even more methods. Just my 2 cents, last word always has the author of this add-on. :-)
the inclusion of rclone was for offsite backup. I personally backup to my NAS with SCP and use rclone to backup to backblaze. Although it could work for SFTP
I am thinking if SFTP fixes this issue we might want to switch now. I will test it with the SFTP command to see if the issues are resolved
@ikifar2012 you do not have to change the command scp
already uses SFTP by default (so name is actually misleading by now). That's why people had issues when upgrading from one HA version to the next as the default behaviour changed.
I too am having the Synology issue, however unlike @Didel, I already had SFTP enabled on my NAS
@ikifar2012 My NAS is not a Synology one, so it could be that different vendors might require additional steps and/or configuration.
Hi,
A few days ago I updated the addon from version 2022.5 to 2022.7, and it looks like my back-ups haven’t been successful since then. I haven’t changed any configuration for the addon, or on the remote machine (a NAS). The error shown in the logs mentions “subsystem request failed on channel 0”
Log output: