You were on the right track.
Just before dinner I was able to solve the problem via an answer to a post at Stack Exchange.

The problem was in the path for the module/s: it was missing the lowest level.

I had this:

[stuff]
--- snip ---
path = /mnt/sda3
--- snip ---

But it should have been this:

[stuff]
--- snip ---
path = /mnt/sda3/stuff
--- snip ---

ie: /mnt/sda3/stuff instead of /mnt/sda3

After I fixed it and rsync was working properly, I am getting a ~19MiB transfer rate.
It is not much to write about as this NAS would get 2x that with the original firmware, but ~2.5x what I was getting via ssh.

Thank you very much for your input.

Best,

A.

To that end rsync will want a declaration in the applicable rsyncd.conf at the server end which in particular would provide the desired path prefix /stuff for the stuff module, but presumably that doesn't exist. But from the log file, it looks like it results in the /stuff bit (the module bit) is consumed and then a destination path prefix / is used.

In short, you might have some luck using rsync://groucho@192.168.1.3:/stuff/stuff as destination path, on the idea that the first /stuff bit nominates the module and the second /stuff bit nominates the path suffix relative to the default module path prefix, /. Of course, if the server is happy with more random module name, you should use something else than /stuff just to reduce the confusion, maybe rsync://groucho@192.168.1.3:/X/stuff

I may be confusing you as my user groucho gets used everywhere.

My Devuan box:

groucho@devuan:~$ ls -ld /media/
drwxr-xr-x 8 root root 4096 Mar 16 16:38 /media/
groucho@devuan:~$ 

groucho@devuan:~$ ls -ld /media/stuff
drwxr-xr-x 25 groucho groucho 4096 Apr 28 07:32 /media/stuff
groucho@devuan:~$ 

groucho@devuan:~$ touch /media/stuff/test1 

groucho@devuan:~$ ls -ld /media/stuff/test1 
-rw-r--r-- 1 groucho groucho 0 Apr 30 13:42 /media/stuff/test1
groucho@devuan:~$ 

The NAS:

groucho@OpenWrt:~$ ls -ld /mnt/sda3
drwxr-xr-x    5 root     root          4096 Apr 28 17:53 /mnt/sda3
groucho@OpenWrt:~$

groucho@OpenWrt:~$ ls -ld /mnt/sda3/stuff
drwxrwxrwx    2 groucho  groucho       4096 Apr 29 18:47 /mnt/sda3/stuff
groucho@OpenWrt:~$

groucho@OpenWrt:~$ touch /mnt/sda3/stuff/test1

groucho@OpenWrt:~$ ls -ld /mnt/sda3/stuff/test1
-rw-r--r--    1 groucho  groucho          0 Apr 30 13:44 /mnt/sda3/stuff/test1
groucho@OpenWrt:~$ 

No.
The /home/groucho dir on the NAS is very limited, just for admin use.
Actually, OpenWRT (mostly used in routers) by default only has root access, no users.

The /mnt/sda3/ partition (~1TB) is where everything gets sent.

root@OpenWrt:~# blkid
/dev/sda1: UUID="xxx" BLOCK_SIZE="1024" TYPE="ext2" PARTUUID="xxx"
/dev/sda2: LABEL="rootfs" UUID="yyy" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="yyy"
/dev/sda3: LABEL="data" UUID="zzz" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="zzz"
root@OpenWrt:~# 

root@OpenWrt:~# mount
--- snip ---
/dev/sda3 on /mnt/sda3 type ext4 (rw,relatime)
--- snip ---
root@OpenWrt:~# 

Thanks for your input.

Best,

A.

If you want to put things into somewhere under the ID's home directory then try rsync -av /media/stuff/firefox.oldfile  rsync://groucho@192.168.1.3:stuff (assuming stuff is in your home dir on groucho).

Chris

I have discovered that the only way to get a half decent link between my Devuan box (GbE port) and my NAS (GbE port) is to use the rsync protocol.
ie: no compression/no encryption with a daemon ie: rsyncd running on one end.

Anyone curious about the details see Can a pocket router go fast?

The problem is that the now ubiquous ssh is only seen a half of what it is: very secure cryptographic network protocol.
What it really is (YMMV) is a very flexible, efficient and easy to use network protocol which also has the ability to be very secure.

Hence the difficulty of being able to use it without encryption.

But I digress.

After a lot of tinkering I have managed to set up an rsync daemon on the NAS as well as the modules required by what I want to do.

eg:

The user is member of the right groups:

:~$ groups
daemon adm mail ftp users network ntp groucho
:~$ 

The modules relate to the directories receiving the data are all owned by the user:

:/mnt/sda3$ ls -l
drwxrwxrwx    4 groucho  groucho       4096 Apr 25 19:03 bkups
drwxrwxrwx    2 groucho  groucho       4096 Apr 29 18:47 stuff
drwxrwxrwx    2 groucho  groucho       4096 Apr 28 17:53 testdir
:/mnt/sda3$ 

The directories from where the data is sent (Devuan box) are all owned by the user:

groucho@devuan:/media$ ls -l /media
total 24
drwxr-x---   2 groucho groucho 4096 Feb  9 19:46 300Gb
drwxr-x---   5 groucho groucho 4096 Jan 30 18:07 bkups
drwxr-x---+  2 root    root    4096 Apr 21 19:57 groucho
drwxr-xr-x   9 groucho groucho 4096 Apr 28 07:25 storage
drwxr-xr-x  25 groucho groucho 4096 Apr 28 07:32 stuff
groucho@devuan:/media$ 

The daemon is running:

:~# service rsyncd status
running
:~# 

The command line is, as far as I can see, correct:

groucho@devuan:~$ rsync -av /media/stuff/firefox.oldfile  rsync://groucho@192.168.1.3:/stuff

But, much to my chagrin, the result is not the expected one:

groucho@devuan:~$ rsync -av /media/stuff/firefox.oldfile  rsync://groucho@192.168.1.3:/stuff
sending incremental file list
firefox.oldfile
rsync: [receiver] mkstemp "/.firefox.oldfile.pPHKBp" (in stuff) failed: Permission denied (13)

sent 85,833,476 bytes  received 134 bytes   24,523,888.57 bytes/sec
total size is 85,812,416  speedup is 1.00
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1207) [sender=3.1.3]
groucho@devuan:~$ 

But not all is bad news:  24,523,888.57 bytes/sec is 3.5x what I was getting using the NAS's native dropbear application.

The /var/log/rsyncd.log file on the NAS reads:

groucho@OpenWrt:~$ cat /var/log/rsyncd.log
2022/04/29 21:35:42 [2557] connect from UNDETERMINED (192.168.1.2)
2022/04/29 21:35:42 [2557] rsync allowed access on module stuff from UNDETERMINED (192.168.1.2)
2022/04/30 00:35:42 [2557] rsync to stuff/ from UNDETERMINED (192.168.1.2)
2022/04/30 00:35:42 [2557] receiving file list
2022/04/30 00:35:42 [2557] rsync: [receiver] mkstemp "/.firefox.oldfile.lNbFmM" (in stuff) failed: Permission denied (13)
groucho@OpenWrt:~$ 

The connection is established, rsync is allowed access to the target folder but when rsync attempts to (having received the file) write a temporary copy at destination, for some reason it it fails and the link is cut

Funny that it does not do a premission check before actually sending the file.

In any case, this seems to be a premission issue, probably the most common one rsync can have.
But I have not been able to find a solution.

Could someone shed some light on this for me?

Thanks in advance.

Best,

A.