Yes, I always remove that /etc/hosts line on Debian. There is usually no need to specify fdaddress. It could be useful for security, e.g. on a machine with multiple network cards or set to localhost if you are also running the Director and Storage Daemon on the same machine.
__Martin >>>>> On Sun, 8 Sep 2024 03:41:17 +0100, Chris Wilkinson said: > > 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
