rsync uid 4294967295 (-1) is impossible to set on...

This happens due to an additional check that was introduced with rsync 3.0.8 which is included in RAIDiator 4.2.17. RAIDiator 4.2.16 contained rsync 3.0.7 which doesn't have that check and thus doesn't complain.
As far as I can see in the rsync source code, the error is non fatal, so the backup job should proceed as planned - just the uid can't be set as there aren't uids that high on Linux based systems. Can you check whether all files were copied?

-Stefan

Hi Stefan.

Thanks for your reply.

All the files are copied, so the backup works.

But the job returns failed as a result of this check, and the backup logs get very large very quickly, as it is a check performed on every file, not just the ones backup up by the incremental job.

/Beack

FWIW, I can confirm this behavior. A log full of "uid is impossible to set" and "gid is impossible to set"....

It does look like the files in the backup are being copied and pruned properly, so hopefully this is merely a cosmetic issue, and there will be no nasty fallout later...

brad

Having exactly the same issue here.... all of our Windows RSync jobs come back with the error. Rsync jobs from RNP to RNP return clean success emails.

It's great that the jobs do look like they are actually running and completing successfully, but we have MANY of these jobs running daily and rely on the emails to monitor backups for DR. We've tried modifying the deltacopy conf file and placing fake-super, setting the uid and gid manually etc... but no joy.

The fake-super has to be set on the device initiating the rsync.. so that would probably be the ReadyNAS.
We had the same problem. We resolved it using the fake-super on the ReadyNAS.
Unfortunately, we were only able to do this because we had enabled SSH on the ReadyNAS and were able to modify the rsync conf file directly.
I think this is definitely an option that should be available on Front-View interface for the ReadyNAS.

Same problem here,.
what file to edit and a example please.
tia
a

I do have ssh access btw.

I too would like to see an example of setting up the "--fake-super" setting for rsync on the ReadyNAS. I've got SSH enabled, and I've had a look around.

I've found where the backup jobs seems to be placed.
/etc/cron.d/frontview-backup

However, I can't seem to find a place to add the "--fake-super" command line option. Since the ReadyNAS is acting as the "client/destination" in my backup job, I'm looking for the command line option, as opposed to setting it in a daemon configuration file. Unless the client rsync also uses a configuration file.

Anyone have advice on where to add this setting?

I've got the same problem - so I tried the --fake-super option (via ssh and editing /frontview/bin/backup to add the option in).

I don't get the impossoble to set error now, but instead I get

rsync: set_acl: sys_acl_delete_def_file(.): No data available (111)

on every file.

I'm contemplating going back to the previous firmware version. Or, has anyone got the previous version of rsync I can get a copy of the downgrade just that?

any solution found to this yet? I have the same issue on my NVX.

TNX to user WhoCares which has compiled rsync 3.0.7, here is a solution:

1. I did stop the RSYNC in frontview, under SERVICES > STANDARD FILE PROTOCOLS
2. with program like putty I connected to my NAS using SSH
3. write the the following commands:

Code:
wget http://whocares.de/rpro/rsync_3.0.7-1~bpo50+1_i386.deb
dpkg -i rsync_3.0.7-1~bpo50+1_i386.deb

4. start RSYNC again, , under SERVICES > STANDARD FILE PROTOCOLS
5. do the backup job

After all, the backups under 4.2.19 working again