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
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Reply via email to