Comment 6 for bug 1888685

Thanks Cliff!
Note: the server question you wondered would have been the details how exactly (commands&config( you do "syncd is enabled and started at boot with the rsyncd.conf". Because in that might lay the details we need.

I was setting up a server on my own aligned to your config.
The following makes it easy for everyone to try to re-create as it is just copy&paste to get it working - it will work on a fresh install of any Ubuntu with rsync installed.

Summary:
Host 20.10 - Rsync 3.2.1
Client 20.04 - Rsync 3.1.3

#1 Setup on the Host to prep, config and debug-start rsyncd as demon:

# Something to sync
mkdir /mnt/testrsync
touch /mnt/testrsync/testfile
mkdir /mnt/testrsync/testdir
touch /mnt/testrsync/testdir/testfile2

# Config
cat << EOF > /etc/rsyncd.conf
pid file = /var/run/rsyncd.pid
lock file = /var/run/rsync.lock

[test_dir]
path = /mnt/testrsync
comment = Test Directory
uid = ubuntu
gid = ubuntu
read only = no
list = yes
hosts allow = 10.253.194.0/24
auth users = ubuntu
secrets file = /etc/rsyncd.scrt
strict modes = false
EOF
cat << EOF > /etc/rsyncd.scrt
ubuntu:ubuntu
EOF

# Start with max debug in local console
rsync -vv --daemon --config /etc/rsyncd.conf --no-detach

#2 Then on the client try to connect

mkdir /mnt/client
export RSYNC_PASSWORD=ubuntu
rsync -vurptC rsync://ubuntu@10.253.194.39/test_dir /mnt/client
receiving incremental file list
./
testfile
testdir/
testdir/testfile2

sent 77 bytes received 218 bytes 590.00 bytes/sec
total size is 0 speedup is 0.00

Works just fine, at the same time the server says:

$ rsync -vv --daemon --config /etc/rsyncd.conf --no-detach --log-file=/dev/stdout
2020/07/28 05:55:52 [7940] rsyncd version 3.2.1 starting, listening on port 873
2020/07/28 05:56:21 [7942] connect from f.lxd (10.253.194.30)
2020/07/28 05:56:21 [7942] rsync allowed access on module test_dir from f.lxd (10.253.194.30)

In my case (just like in yours) it recognizes the configured module "test_dir" in my case "Bin_dir" in yours. From there it finds all the content and syncs it.

Your error suggests a chroot issue that I can't reproduce even with that setup close to yours.
I added "use chroot = yes" to the daemon config but it behaves the same.

Might on your upgrade anything else have changed that influences this - like under which user the daemon runs?