Applying the retention staregy on a destination where ssh as root is not permitted

[prontog]

Hello,

It seems that when you push a backup to a host that you cannot ssh as root the retention strategy fails since you have not enough permissions to remove files. The actuall backup works since rsync--path can be set up as sudo rsync but what about the part before rsync when the strategy is applied?

Regards,

Panos

[reactive-firewall]

:+1: good catch

[reactive-firewall]

this probable means testing hard-links as part of #190 could be impacted in adition to https://github.com/laurent22/rsync-time-backup/blob/88db869fe7a52864e18afc7e16a971499f79e830/rsync_tmbackup.sh#L249-L251

adding a function like:

fn_test_file_removable() {
     fn_run_cmd "test -w '$1'"
 } 

might be of use for this

[filippocarletti]

The permission problem when logging in as non-root can be solved adding "-M--fake-super" to ssh options.

[reactive-firewall]

The permission problem when logging in as non-root can be solved adding "-M--fake-super" to ssh options.

🎉 ...Nice! ...um 😕... how? pretend I'm an idiot linux kernel ... just walk me through this with some code

[prontog]

The permission problem when logging in as non-root can be solved adding "-M--fake-super" to ssh options.

I didn't know about this option. I add rsync to sudoers with NOPASSWD to handle this case. Of course I am not talking about permission issues using rsync but permission issues applying the strategy. The expiration strategy is not using rsync!