trying to backup from Ultra 6+ to new 316

Could you post the backup configuration as you have set it up.
The 2 units are on the same LAN?
What is the IP address of the 316?

Have you tried it after removing the rsync credentials from the source, does it still not work?

I back up my pro-6 to various NAS using this method, including the RN102. Though I use the pro-6 admin credentials on the RN102 backup jobs.

You might also try running the backup job on the ultra (with the RN316 as the destination) and see what happens.

to vandermerwe: yes, they are on the same lan, the 316 is statically assigned 192.168.1.98; the network configuration seems correct (the subnet mask is 255.255.255.0).

to stephen B: Is your source device configured to require an rsync username and password? My Ultra, the backup source, is configured to require an rsync username and password, and I have provided these credentials to the backup job running on the destination NV+ (the rsync jobs for the NV+ run on the NV+, not the source device, which is my ultra).

The documentation for both OS6 and the OS 4.x suggests that I use an rsync user and password for security, and even though both systems are on my LAN, I feel better doing this. The documentation also says the credentials for rsync are completely different from those for other user accounts. That seems to be the case for the Ultra and NV+. Are you saying things are different for the 316 running OS 6.x? Do you think I need to remove the rsync credentials on my source (the Ultra) and instead supply credentials for the source admin account to my destination 316 device (i.e., username admin, password is the system login password). This seems contrary to the system documentation, and would also make my source device, the ultra, insecure for most purposes, since it would be running a non-password-protected rsync service.

I have not configured rsync user names on my pro nor my RN102. As far as security goes, I don't think they add any real security for backup unless you are running rsync over ssh. (why bother if all the files are backed up in the clear?) I also see no compelling reason to avoid using user accounts, the documentation just says it doesn't matter, not that it increases security. Just my opinions though.

There are ten basic combinations here
One should fail:
-no user credentials specified in the backup job, but credentials configured for rsync at the remote share
(there are other combinations that ought to fail that I am ignoring).

The other 9 should work:
-no user credentials specified in the backup job, and none configured for rsync at the remote share
-user credentials specified in the backup job that exist only on the remote machine, but no rsync users configured at the remote share
-user credentials specified in the backup job that exist only on the remote machine, and only that user configured for rsync at the remote share
-user credentials specified in the backup job that exist only on the local machine, but no rsync users configured at the remote share
-user credentials specified in the backup job that exist only on the local machine, and only that user configured for rsync at the remote share
-user credentials specified in the backup job that exist on neither machine, and only that user configured for rsync at the remote share
-user credentials specified in the backup job that exist on neither machine, but no rsync users configured at the remote share
-user credentials specified in the backup job that exist on both machines, and only that user configured for rsync at the remote share
-user credentials specified in the backup job that exist on both machines, but no rsync users configured at the remote share

Since this is a bug, behavior might depend on which machine is running the backup job - so really there are 20 basic combinations total.

In my own backup jobs, the RN102 uses the pro admin credentials in the rsync backup job, even though there is no rsync user configured on the pro for that share. The RN102 admin credentials are also the same as the pro's, so that would be the last combination above.

Maybe try some (or all) of the above combinations on a small test share, and see which work. It should give you a better handle on your options (and perhaps something specific to put into your support request).

BTW, what firmware are you running on the RN316?

I think the firmware is 6.1.8, but I'm not where I can check right now.

One thing I did do: if I omit the "path" field when defining the backup job on the 316, but do define the remaining fields properly, using the rsync username and password, the "test connection" will succeed.

When I defined the source path on the backup job on my NV+, I would simply give the share name (which in my case is "fileserver") and the backup job would work. Perhaps on the 316 I have to give the full path name - do you happen to know what that is for a share located on an Ultra 6+? (I'm sure I can figure this out myself by enabling ssh on my Ultra 6+, but this must be common knowledge). If this doesn't work, I will try the various options you suggested in your email

Thanks again!

ON OS6 it is also just the share name.

Of course if you omit the path field altogether, the ultra won't try to check the rsync user credentials (because that is share specific).

OK, thanks very much to all!!!

I have gotten this working, but can't really say why. I deleted and reentered the shares and backup job, and it works now. I assume I had a Dumb Typo somewhere.

Thanks again!