Re: Remote Client Backup Failing

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, <[email protected]> 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
>