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