Been struggling with this for the last week or so, with no real success.

The Console program on the windows box works very nicely, so no communications problems there. I can run the whole system on the linux box from the windows machine

Cannot get any debug information from the windows client. Looked at from the linux box the windows jobs seem to fail because the storage daemon does not get a resonse from windows client - it terminates after 'waiting on the windows fd' for a while. Nor can I get status information on the windows client from either box

I am now wondering whether the windows client has installed properly at all. It did not seem to finish completely when I first installed it and today reinstalled it. It stopped with a nearly blank window, with a just a 'finish' box in it which did not respond to a click. Had to crash it to get going

bacula is running as a service, and as instructed it was installed by the Administrator account. Maybe I am using the wrong version or something - the file I am using is called bacula-enterprise-win-32 -7.4.0

Steve Hodge

On 09/09/2016 10:55, Kern Sibbald wrote:

Probably the best source of information for how to "debug" problems such as you are having is the Windows chapter of the manual. Specifically it tells you how to get debug output, and for connection problems you should invoke the command line with -d50 or greater. For SD problems, you will, of course, have to run a backup job from the Director while this debug trace is turned on.
You can also turn on trace output for the SD, which is *much* simpler.

The manual is a bit old and out of date, but what is written is still valid. That said, for getting trace output, it is probably easier to turn on as well as turn on output to a trace file by using the bconsole "setdebug" command. Again the manual (Console manual) explains the setdebug command in more detail.

Best regards,

On 09/06/2016 11:49 AM, Hodges wrote:

Thanks for the idea Ralf, but no, I don't think its the firewall.

The system reports that port 9102, used by the windows-fd client, is open. Don't know how to confirm this absolutely. Could one telnet 9102 from the linux box or something similar??

Anyway I set the firewall open to any machine on the local network when I first hit the problem

On 06/09/2016 07:42, Ralf Brinkmann wrote:
Am 04.09.2016 um 13:58 schrieb Hodges:
> I have read somewhere that when the the windows box cannot
> communicate for some other reason this error gets generated, but I
> have no idea how to trace what is going on and still less how to
> correct it

I suppose the Windows firewall blocks your required port.



Bacula-users mailing list

Bacula-users mailing list

Reply via email to