Re: [Bacula-users] Windows fd unable to communicate with linux sd

[Sven Hartge]

On 26.09.2016 00:09, Hodges wrote:

> 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.
> 
> Anyone know why the Debian stable version is stuck at 5.2.6?

Debian Stable never gets new upstream versions after release (with the
exception of some special packages). This is the Debian Release
philosophy (which is not very different from other Enterprise-Class
distributions).

But you can get a very recent version (7.4.3) of Bacula from the
backports archive.

Grüße,
Sven Hartge.




signature.asc
Description: OpenPGP digital signature
--
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Windows fd unable to communicate with linux sd

[Kern Sibbald]

  
  
Hello,
  
  Bacula version 5.2.6 was released 2 June 2012.  That is a *very*
  old version.  Since then, there have been many equally (or more)
  stable versions.  Debian does have their particular ways of doing
  things, but this is a bit sad for Bacula users, because although
  the project can answer general questions about it, it has been a
  long time since it has been officially supported.
  
  Perhaps the advice from Michael Munger would be a good solution.
  The major problem with upgrading one's self is that there are
  database upgrades that in those old days had to be applied one at
  a time.  
  
  My project to provide Bacula project binaries for the community is
  very close to fruition.  Many binaries for the popular platforms
  are now built, it is just a matter of getting them posted on the
  web site (in itself a rather time consuming task).  There will be
  many advantages of using Bacula project binaries (e.g. they are
  test, which is not the case for most distros, the upgrade will be
  much easier, and going back will be quite easy too, more recent
  binaries, ...)
  
  Best regards,
  Kern
  
  On 09/26/2016 12:09 AM, Hodges wrote:


  
  Solved
  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.
  Anyone know why the Debian stable version is stuck at 5.2.6?
  
  
  On 16/09/2016 12:04, Hodges wrote:
  
  

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 

Re: [Bacula-users] Windows fd unable to communicate with linux sd

[Michael Munger]

Reverting to older versions is sub optimal.

Instead, (generically) do this:

1. apt-get install build-dep bacula
2. Download and install the latest version to /usr/src/
3. tar xf  bacula.7.x.x.tar.gz
4. cd bacula-xxx
5. ./configure && make && make install

Debian repositories generally have very very very stable binaries in them. 
Because of the Debian philosophy of having extremely stable binaries, they 
don't like to change things very often. Thus, Debian is usually several 
versions behind the latest and greatest curve. In most cases, this is 
sufficient. However, for applications that you're actively using, need bug 
fixes for, etc... You can utilize the extremely stable environment, and then 
compile the application that you really need from source.


Get Outlook for Android



On Sun, Sep 25, 2016 at 6:14 PM -0400, "Hodges" 
> wrote:


Solved

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.

Anyone know why the Debian stable version is stuck at 5.2.6?

On 16/09/2016 12:04, Hodges wrote:

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.


--
[cid:part1.0900F4B5.CA717D33@sloth.demon.co.uk]



--




___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users



--
[cid:part4.355DE0CB.E0103F4A@sloth.demon.co.uk]

--
[cid:part5.3F9920D6.3461E5E8@sloth.demon.co.uk]
--
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Windows fd unable to communicate with linux sd

[Hodges]

Solved

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.


Anyone know why the Debian stable version is stuck at 5.2.6?


On 16/09/2016 12:04, Hodges wrote:


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





--


--
--
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Windows fd unable to communicate with linux sd

[Ana Emília M . Arruda]

Hello Hoges,

You can find how to start the windows file daemon in debug mode in the main
manual:
http://www.bacula.org/7.4.x-manuals/en/main/Windows_Version_Bacula.html#SECTION00374
.

You are trying to install the 32-bit version. Is your Windows system a
32-bit or 64-bit one? Please take care to install the correct bacula client
version (there is one for 32-bit and another one for 64-bit systems).

Best regards,
Ana

On Fri, Sep 16, 2016 at 1:04 PM, Hodges  wrote:

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

Re: [Bacula-users] Windows fd unable to communicate with linux sd

[Hodges]

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





--
--
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Windows fd unable to communicate with linux sd

[Kern Sibbald]

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




  

--
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Windows fd unable to communicate with linux sd

[Ralf Brinkmann]

Am 07.09.2016 um 11:12 schrieb Hodges:
> Ralf,
>
> Thanks for this idea. I have installed netcat on the windows box, and of
> course it is already on the linux box. Am struggling at the moment with
> how to use it, but will persvere

>> some years ago I made some tests with netcat to verify the network speed
>> between certain servers and the bacula host.
>>
>> I'm not familiar with Bacula issues on Windows but there is a netcat
>> Windows version that might help:

Hello Steve, just looked into my elder notes:

> Receiver
> =
>  netcat -v -v -l -n  -p 9104 >  /dev/null

> Sender
> ==
> dd count=1000 < /dev/zero | netcat -v -v -n  192.6.3.21  9104  > /dev/null

On finish "dd" will tell the transfer rate.

-- 
Ralf Brinkmann
DV / Organisation

--
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Windows fd unable to communicate with linux sd

[Hodges]

Ralf,

Thanks for this idea. I have installed netcat on the windows box, and of 
course it is already on the linux box. Am struggling at the moment with 
how to use it, but will persvere


Steve


On 06/09/2016 12:13, Ralf Brinkmann wrote:

Am 06.09.2016 um 11:49 schrieb Hodges:

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


hello Steve,

some years ago I made some tests with netcat to verify the network speed
between certain servers and the bacula host.

I'm not familiar with Bacula issues on Windows but there is a netcat
Windows version that might help:

https://joncraton.org/blog/46/netcat-for-windows/


 # netcat -h
[v1.10]
connect to somewhere:   netcat [-options] hostname port[s] [ports] ...
listen for inbound: netcat -l -p port [-options] [hostname] [port]
options:
-g gateway  source-routing hop point[s], up to 8
-G num  source-routing pointer: 4, 8, 12, ...
-h  this cruft
 -i secs delay interval for lines sent, ports 
scanned

-l  listen mode, for inbound connects
-n  numeric-only IP addresses, no DNS
-o file hex dump of traffic
-p port local port number
-r  randomize local and remote ports
-s addr local source address
-t  answer TELNET negotiation
-u  UDP mode
-v  verbose [use twice to be more verbose]
-w secs timeout for connects and final net reads
-z  zero-I/O mode [used for scanning]
port numbers can be individual or ranges: lo-hi [inclusive]




--
--
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Windows fd unable to communicate with linux sd

[Ralf Brinkmann]

Am 06.09.2016 um 11:49 schrieb Hodges:
> Anyway I set the firewall open to any machine on the local network when
> I first hit the problem

hello Steve,

some years ago I made some tests with netcat to verify the network speed
between certain servers and the bacula host.

I'm not familiar with Bacula issues on Windows but there is a netcat
Windows version that might help:

https://joncraton.org/blog/46/netcat-for-windows/

>  # netcat -h
> [v1.10]
> connect to somewhere:   netcat [-options] hostname port[s] [ports] ...
> listen for inbound: netcat -l -p port [-options] [hostname] [port]
> options:
> -g gateway  source-routing hop point[s], up to 8
> -G num  source-routing pointer: 4, 8, 12, ...
> -h  this cruft
>  -i secs delay interval for lines sent, ports scanned
> -l  listen mode, for inbound connects
> -n  numeric-only IP addresses, no DNS
> -o file hex dump of traffic
> -p port local port number
> -r  randomize local and remote ports
> -s addr local source address
> -t  answer TELNET negotiation
> -u  UDP mode
> -v  verbose [use twice to be more verbose]
> -w secs timeout for connects and final net reads
> -z  zero-I/O mode [used for scanning]
> port numbers can be individual or ranges: lo-hi [inclusive]

-- 
Ralf Brinkmann




--
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Windows fd unable to communicate with linux sd

[Hodges]

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

Re: [Bacula-users] Windows fd unable to communicate with linux sd

[Ralf Brinkmann]

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.

-- 
Ralf Brinkmann


--
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

[Bacula-users] Windows fd unable to communicate with linux sd

[Hodges]

I have working bacula set-up on my linux box, which backs up to a 
network drive  which is permanently mounted on the linux box where the 
director runs .
When I try to get the fd on my windows 10 box (where it is running fine, 
as a service) to backup to the same network drive mounted on the linux 
box  (but to a different folder) I get


04-Sep 11:58 mailserver-dir JobId 1711: Start Backup JobId 1711, 
Job=studydata.2016-09-04_11.58.35_16
04-Sep 11:58 mailserver-dir JobId 1711: Using Device "StudyStorage"
04-Sep 11:58 study-fd JobId 1711: Fatal error: Authorization key rejected by 
Storage daemon.

It is not the key that is at fault, as they are all the same in my 
setup. 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


Any suggestions gratefully received. At present I back up the windows 
boxes with Genie, but I find it clunky and would like to standardise on 
bacula


Steve Hodge
--
--
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users