Hi everyone,
I’m trying to pull a ZFS dataset from an Ubuntu system to TrueNas Scale (25.10.4 - Goldeye) via ssh with public key authentication.
Authentication is working fine, that can also be seen on the target side in the audit log. With authentication working, I’d suppose that it’s not a network configuration nor dns issue. The TrueNAS system “sees” the snapshots on the remote system and displays it properly when setting up the replication task.
Upon replication, the following error message is shown in GUI:
[Errno 101] Network is unreachable
However, doing a tcpdump shows that the ssh connection is being setup and closed properly from TrueNAS sending TCP/FIN package.
From the zettarepl logs that error is shown as:
For task ‘task_3’ unhandled replication error ExecException(255, ‘ssh: connect to host ###ip-address### port 2222: Connection refused\ncannot receive: failed to read from stream\n’) @cee:{“TNLOG”: {“exception”: “Traceback (most recent call last):\n File \”/usr/lib/python3/dist-packages/zettarepl/replication/run.py\“, line 181, in run_replication_tasks\n retry_contains_partially_complete_state(\n File \”/usr/lib/python3/dist-packages/zettarepl/replication/partially_complete_state.py\“, line 16, in retry_contains_partially_complete_state\n return func()\n ^^^^^^\n File \”/usr/lib/python3/dist-packages/zettarepl/replication/run.py\“, line 182, in \n lambda: run_replication_task_part(replication_task, source_dataset, src_context, dst_context,\n ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n File \”/usr/lib/python3/dist-packages/zettarepl/replication/run.py\“, line 277, in run_replication_task_part\n run_replication_steps(step_templates, observer)\n File \”/usr/lib/python3/dist-packages/zettarepl/replication/run.py\“, line 674, in run_replication_steps\n replicate_snapshots(step_template, incremental_base, snapshots, include_intermediate, encryption, observer)\n File \”/usr/lib/python3/dist-packages/zettarepl/replication/run.py\“, line 738, in replicate_snapshots\n run_replication_step(step, observer)\n File \”/usr/lib/python3/dist-packages/zettarepl/replication/run.py\“, line 819, in run_replication_step\n ReplicationProcessRunner(process, monitor).run()\n File \”/usr/lib/python3/dist-packages/zettarepl/replication/process_runner.py\“, line 22, in run\n self.replication_process.run()\n File \”/usr/lib/python3/dist-packages/zettarepl/transport/ssh.py\“, line 155, in run\n self._start_progress_observer()\n File \”/usr/lib/python3/dist-packages/zettarepl/transport/progress_report_mixin.py\“, line 76, in _start_progress_observer\n pid = self.async_exec.head(self._get_zettarepl_pid, 10)\n ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n File \”/usr/lib/python3/dist-packages/zettarepl/transport/async_exec_tee.py\“, line 70, in head\n raise ExecException(event.returncode, self.output)\nzettarepl.transport.interface.ExecException: ssh: connect to host 94.16.107.9 port 2222: Connection refused\ncannot receive: failed to read from stream”, “type”: “PYTHON_EXCEPTION”, “time”: “2026-07-20 16:59:59.036541”}}
[2026/07/20 18:59:59] WARNING [retention] [zettarepl.zettarepl] Local retention failed: error listing snapshots on <SSH Transport(backup@###ip-address###)>: NoValidConnectionsError(None, ‘Unable to connect to port 2222 on ###ip-address###’)
However, from the TrueNAS system:
root@hostname[~]# nc -zv ###ip-address### 2222
Connection to ###ip-address### 2222 port [tcp/*] succeeded!
Also, a manual zfs replication works from truenas logging in as root via ssh and using the following command:
“ssh -i .ssh/backup backup@###hostname retracted### -p 2222 “sudo zfs send -p -L -c -i www@zfs-auto-snap_daily-2026-08-03-0625 -R www@zfs-auto-snap_daily-2026-08-10-0625” | zfs receive ###target dataset retracted### -F”
(for initial sync, the -i option needs to be removed, of course)
Some newer hosts allow for the -V flag to be used in the zfs send command, some older don’t. That seems to be a related issue.
Has anyone ever tried to sync from a non-truenas-system like this and has received similiar errors?
Unfortunately, the bug report got closed as the Bug AI nailed the issue down to some network misconfigurations that are inevident. That bug clerk is quite annoying imho.
Any ideas from community?