Just a version problem. My linux box has version 5.2.6 (latest
debian version apparently) and the 7.4.3 windows version does not
like it. Wind the windows version back to 5.2.6. and it works OK.
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:
Hello,
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,
Kern
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
Steve
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 AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
--