Looks like rsync should be adapted to a new policy of the Linux kernel. I found a report in the ZFS Github that looks a lot like my problem : https://github.com/openzfs/zfs/issues/10742 But on that page, the suggested solution using /proc/sys/fs/protected_regular doesn't seem to be ideal and instead rsync should be able to figure it out by itself so that users aren't encouraged to keep that security measure turned off (perhaps my idea is bad, but pros and cons have to be figured out).
I'm regularly backing up a remote folder on a machine that has a different user list and that folder has sticky bit set, while being root on both sides. I had no error using Ubuntu 18.04 : it started failing just after upgrading to 20.04. If I try to rsync individual files of that folder, I get error 13 in most cases, but if I chmod -t on that folder, I can rsync them, but if I try rsyncing the folder again (by recursion), rsync does chmod +t on it before rsyncing individual files in the folder, and then it fails again. And of course, to work around the problem, rsync would probably have to catch error 13 and retry after doing chmod -t temporarily on the folder, then schedule a chmod +t after this folder is finished syncing, or at cleanup time (Ctrl+c or SIGTERM).
Thank you for taking the time to report this bug and helping to make Ubuntu better.
This sounds like an upstream bug to me. The best route to getting it fixed in Ubuntu in this case would be to file an bug with the upstream project. Have you tried to reproduce this bug using a newer rsync version? I was not able to find any upstream bug report about this, if you confirm this is affecting the latest version of rsync please report it here:
https:/
Otherwise, if this is fixed in the newer versions we need to find out the appropriate fix to be backported. In this case, some detailed reproduction steps would be valuable.
If you do end up filing an upstream bug, please link to it from here. Thanks!