I have answered my own question. My error was to set the fdaddress directive in the fd(s) to the remote hostname(s). My /etc/hosts files have the line
127.0.1.1 <hostname> The fdaddress directives did exactly that. This is a typical /etc/hosts on Debian and derivative systems I understand. This directive should be omitted to force the fd to bind to address 0.0.0.0. With that change port 9102 is open and the remote client backup is working again. I can't think of a situation where you would not want the fd to bind to <any> address. On Sat, 7 Sep 2024, 13:02 Chris Wilkinson, <winstonia...@gmail.com> wrote: > I have a remote client whose backup is now failing because the FD doesn't > return a status. Till now it was OK. > > 2024-09-07 06:09:28 raspberrypi-dir JobId 7330: Error: Bacula > raspberrypi-dir 11.0.6 (10Mar22): > Build OS: aarch64-unknown-linux-gnu debian 11.3 > JobId: 7330 Job: nuc2.2024-09-07_06.04.16_55 > Backup Level: Incremental, since=2024-09-06 03:50:03 > Client: "nuc2" 11.0.6 (10Mar22) x86_64-pc-linux-gnu,debian,12.1 > FileSet: "nuc2" 2023-09-26 03:50:00 > Pool: "nuc2-incremental" (From Job IncPool override) > Catalog: "MyCatalog" (From Pool resource) > Storage: "remote-clients" (From Command input) > Scheduled time: 07-Sep-2024 06:04:16 > Start time: 07-Sep-2024 06:04:18 > End time: 07-Sep-2024 06:09:28 > Elapsed time: 5 mins 10 secs > Priority: 10 > FD Files Written: 0 > SD Files Written: 0 > FD Bytes Written: 0 (0 B) > SD Bytes Written: 0 (0 B) > Rate: 0.0 KB/s > Software Compression: None > Comm Line Compression: None > Snapshot/VSS: no > Encryption: no > Accurate: no > Volume name(s): > Volume Session Id: 205 > Volume Session Time: 1724622798 > Last Volume Bytes: 156,319,421 (156.3 MB) > Non-fatal FD errors: 1 > SD Errors: 0 > FD termination status: Error > SD termination status: Waiting on FD > Termination: *** Backup Error *** > 2024-09-07 06:09:28 raspberrypi-dir JobId 7330: Fatal error: No Job > status returned from FD. > 2024-09-07 06:04:18 raspberrypi-dir JobId 7330: Using Device "qnap-usb3" > to write. > 2024-09-07 06:04:18 raspberrypi-dir JobId 7330: Start Backup JobId 7330 > Job=nuc2.2024-09-07_06.04.16_55 > > I have port 9102 (FD) open on the remote router but when I look at netstat > on the remote client I see the local address is 127.0.1.1 for port 9102 > whereas it is 0.0.0.0 for other ports. > > ~$ netstat -tln > Active Internet connections (only servers) > Proto Recv-Q Send-Q Local Address Foreign Address State > tcp 0 0 127.0.0.1:61209 0.0.0.0:* LISTEN > tcp 0 0 0.0.0.0:8088 0.0.0.0:* LISTEN > tcp 0 0 0.0.0.0:10000 0.0.0.0:* LISTEN > tcp 0 0 0.0.0.0:5201 0.0.0.0:* LISTEN > tcp 0 0 0.0.0.0:22000 0.0.0.0:* LISTEN > tcp 0 0 127.0.1.1:9102 0.0.0.0:* LISTEN > tcp 0 0 0.0.0.0:631 0.0.0.0:* LISTEN > tcp 0 0 0.0.0.0:12865 0.0.0.0:* LISTEN > tcp 0 0 0.0.0.0:873 0.0.0.0:* LISTEN > tcp 0 0 0.0.0.0:8384 0.0.0.0:* LISTEN > tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN > tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN > tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN > > The other data point is that pointing a port open tool at the public IP of > the client comes back as 9102 closed which explains the failure. The other > opened ports are correctly showing as open. I'm guessing that the reason > for that is the 127.0.1.1. > > This all came about after the remote client router was changed from an > ADSL one to VDSL. I haven't been able to figure out why this one port would > have a different local address than the others. > > This is probably more of a networking question but perhaps someone here > might have an insight. > > Many Thanks > > -Chris Wilkinson > -Chris Wilkinson
_______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
