As I mentioned above, adding an entry
--verbose to the Extra Options field of the Rsync Task gets me more diagnostics. It is worth reading the
rsync command documentation (man page) about the
--info and
--debug options. In principle you make
rsync be both more selective and more detailed in the diagnostics it puts out to the log file and to the console. However, in my case I got worse results, and returned to using
--verbose . The problem may have been that the
rsync software at the destination was a slightly older version (protocol 30 vs protocol 31 on my FreeNAS system), and that might have reduced the quality of my results.
I felt like I got much better access to diagnostics when I opened up a separate terminal window to ssh in to a shell command line on my FreeNAS server. I was able to use commands like
tail -10 /var/log/messages and
tail -10 /var/log/rsync.log to see the console and the rsync log respectively. And using
tail -f with either of these files let me see messages as they were added to the file. My previous access to the command line was via the Shell option in the FreeNAS admin UI. This forced me to close the Rsync Task dialogue in order to see the results of my actions, and it was cumbersome. Having a separate shell window was much better.
It looks like there are no diagnostics if you may a syntax error in the Extra Options field of the Rsync Task. When you run the job, apparently nothing happens. The answer seems to be, don't make mistakes. Alternately, check the Extra Options carefully for syntax errors. You can also construct an rsync --dry-run command in the shell, and paste in the Extra Options you are using. This showed me helpful syntax error messages sometimes.
From the list of Rsync Tasks, you can click on the three-dot icon at the right, and select Run Now from the menu there. This lets you try different settings without waiting for the scheduled time to occur. I have set all my Rsync Tasks to run once a year, or even less often, and unchecked the Enabled checkbox. I run them only from the Run Now menu item. Once I get the tasks working, I will schedule them.
One of the problems I have had with my Rsync Tasks was timeouts before a task was complete. Because I kept the default setting of "Delay Updates", this meant that rsync left my copied files in temporary directories ".~tmp~" throughout the destination. I found that I was able to use rsync's filter rules in the Extra Options of the Rsync Task. By excluding most of the source directory, and including only a few top-level directories at at time, I was able to finish smaller rsync tasks before the timeout occurred, so the files got out of their temp directories and into the right locations. Reducing the scope this way has a double benefit: not only does it reduce the amount of data to copy, it reduces the time rsync requires up front to make a list of files to examine. That list was taking tens of minutes to an hour in my case. I expect that, once most of the files are copied, I can run an Rsync Task over the entire directory, and it will be able to update the few changes without timing out.
Also, let me go a little off-topic to report one success. I realised that I was getting tunnel vision around rsync, and that my top-level goal was to get the files copied regardless of the method. I was able to copy 1TB of files using the macOS Finder. It took 10 hours, but it completed. I will then go back over it with rsync to see if rsync is happy with the result. This may be a useful way to make an end run around rsync failures.