On 06/12/2014 05:38 PM, Thomas Lohman wrote:
> I've seen this error before on and off on one particular client.
> Nothing changes with regard to the configuration and yet the error will
> crop up. Usually a combination of the following "fixes" it -
> cancel/restart the job, restart the Bacula c
I've seen this error before on and off on one particular client.
Nothing changes with regard to the configuration and yet the error will
crop up. Usually a combination of the following "fixes" it -
cancel/restart the job, restart the Bacula client, or restart the Bacula
storage daemon. Since
Hi Benjamin,
Do you have localhost in any of your bacula conf files?
Regards,
Ana
On Tue, Jun 3, 2014 at 11:48 AM, benji49320
wrote:
> Hi,
>
> I've problem with my Bacula server and my FD on my client-test server
> (centos6-fd). When I try to run a job with BAT I've the following error :
>
>
Hi,
I've problem with my Bacula server and my FD on my client-test server
(centos6-fd). When I try to run a job with BAT I've the following error :
centos6-fd Fatal error: Authorization key rejected by Storage daemon.
Please see
http://www.bacula.org/en/rel-manual/Bacula_Freque_Asked_Questi.htm
Hi Ana -
Thanks for your reply.
What we discovered was the implementation of rp_filter in Ubuntu 12.04
prevented packets from flowing like we expected. While this behavior is
good in general, it stopped traffic from going through where we wanted
it. Once that was disabled, things started wo
Hi Kevin,
Yes, that´s the way bacula works. It "ties" volumes to devices. But you´re
having this behaviour because of your configuration. Maybe you should take
a look at vchanger. There is a very good discussion about vchanger and
bacula disk-changer:
http://www.mail-archive.com/bacula-users@lists
Hi Ana -
Thanks for responding.
I currently have no issues communicating between the public-fd client
and the storage daemon at 192.168.120.35. I'm able to connect between
both addresses on ports 9102 and 9103.
As far as the JobID, I pass the specific job to the console during the
restore.
Hi Kevin,
Just trying to understand... The error bellow:
Restore-public-Disk.2013-09-20_12.43.48_32 is waiting
for Client to connect to Storage daemon
...
20-Sep 12:19 public-fd JobId 19084: Fatal error: Authorization key rejected
by Storage daemon.
Please seehttp://www.bacula.org/rel-manual/faq.
Greetings -
I'm running Bacula 5.2.5 on an Ubuntu 12.04.3 server, with about 61TB of
disk storage and an attached Dell PVTL2000 tape library. Backups are
working great, but restores are presenting a problem.
Here's my dilemma:
When attempting to restore a file, I get this status for about 10 m
Hi,
So having quite a frustrating issue with bacula on one of our CentOS hosts.
Without pattern, I will receive this error on some days:
12-Oct 09:13 dir JobId 24468: Start Backup JobId 24468, Job=
12-Oct 09:13 dir JobId 24468: Using Device "chg0_drive0"
12-Oct 09:46 fd JobId 24468: Fatal error:
yeah, the same config for nightly run is the exact same as the one for manual
run,
only difference is that it's scheduled.
ssh tunnel is opened for each job.
as additional info, I have multiple jobs, but it's only the SSH jobs that fail.
+---
just noticed there is this following error in addition to the above
Fatal error: Bad response to Storage command: wanted 2000 OK storage, got 2902
Bad storage
+--
|This was sent by to...@tomse.dk via Backup Central.
|Forward SPA
> On Tue, 12 Jun 2012 00:11:53 -0700, tomse said:
>
> The above message is now shown after upgrading from 5.1.x to 5.2.6
>
> Doing a manual backup using same jobs etc it works perfectly.
> So keys are good.
>
> This only occurs with the automatic backup running through a SSH Tunnel
> (foll
On Tue, Jun 12, 2012 at 12:11:53AM -0700, tomse wrote:
> The above message is now shown after upgrading from 5.1.x to 5.2.6
>
> Doing a manual backup using same jobs etc it works perfectly.
> So keys are good.
>
> This only occurs with the automatic backup running through a SSH
> Tunnel (followi
The above message is now shown after upgrading from 5.1.x to 5.2.6
Doing a manual backup using same jobs etc it works perfectly.
So keys are good.
This only occurs with the automatic backup running through a SSH Tunnel
(following the ssh tunnel guide in the manual)
anyone has any ideas to fix t
: bacula-users@lists.sourceforge.net
Asunto: [Bacula-users] Fatal error: Authorization key rejected by Storage
daemon
Hi guys,
I recently have this error with one of my Windows 2003 servers. (log pasted
at the end) The configuration has no changes and it fails since one month
ago.
Nothing
--Duilio Poggi OnetoEnviado usando Nextel EmailFrom: "Arnau Coll" Date: Tue May 08 10:51:16 GMT 2012To: "bacula-users@lists.sourceforge.net" Subject: [Bacula-users] Fatal error: Authorization key rejected by Storage daemon
Hi guys,
I recently have this error with one of my
Hi guys,
I recently have this error with one of my Windows 2003 servers. (log pasted at
the end) The configuration has no changes and it fails since one month ago.
Nothing changed, the authentication keys are the same and that backup worked
about one year without any problem.
I tried to restart
Solved :)
I found the problem. It was my tcp wrapper rules -- as earlier I didn't
realize the storage daemon communicated directly with the file daemon. (As
I thought all traffic went though director.) A reply on this thread
clarified this for me. (Thanks!) But I didn't fix my /etc/hosts.allow
Now that debugging is working (see my patch in other thread), I have some
more details:
a1-fd: filed.c:238 filed: listening on port 9102
a1-fd: cram-md5.c:52 send: auth cram-md5
<[EMAIL PROTECTED]> ssl=0
a1-fd: cram-md5.c:68 Authenticate OK Q2thJ6+M/8ICB4g41H+BoB
a1-fd: cram-md5.c:114 sending re
My bacula-sd.conf only has one password defined in a Director container.
This is the same password as in my Storage container in my
bacula-dir.conf. I have a Client container that has the password that
matches the password in the Directory container in the client's
bacula-fd.conf.
I just look
On 11/28/06, Jeremy C. Reed <[EMAIL PROTECTED]> wrote:
On Tue, 28 Nov 2006, John Drescher wrote:
> > > 28-Nov 08:14 a1-fd: a1.2006-11-28_08.10.43 Fatal error:
Authorization
> > > key
> > > rejected by Storage daemon. Please see
> > > http://www.bacula.org/rel-manual/faq.html#AuthorizationErrors
On Tue, 28 Nov 2006, John Drescher wrote:
> > > 28-Nov 08:14 a1-fd: a1.2006-11-28_08.10.43 Fatal error: Authorization
> > > key
> > > rejected by Storage daemon. Please see
> > > http://www.bacula.org/rel-manual/faq.html#AuthorizationErrors for help.
> > > 28-Nov 08:14 a1-fd: a1.2006-11-28_08.10.4
On 11/28/06, John Drescher <[EMAIL PROTECTED]> wrote:
On 11/28/06, Jeremy C. Reed <[EMAIL PROTECTED]> wrote:
>
> I am using bacula version 1.38.11 on CentOS.
>
> I have a server that is running bacula-dir, bacula-sd and bacula-fd.
> As far as I can tell the default bacula backups are working f
> What is this "Authorization key"? It is not mentioned in the manual. And I
> don't see anything related in the "Storage Configuration Daemon" chapter.
>
> I am still reading the very long manual :)
I found this in the source at authenticate_storagedaemon() in
src/filed/authenticate.c. It says
I am using bacula version 1.38.11 on CentOS.
I have a server that is running bacula-dir, bacula-sd and bacula-fd.
As far as I can tell the default bacula backups are working fine there.
I have another system I need to back up. I only have the bacula-fd
installed and running there (and also have
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I am getting this message from most of the clients. The backup server is
version 1.36.2 while those clients which I have problem with, are 1.38.5
or later. Nearly all of the clients are FreeBSD machines. They have been
working for many months when the
27 matches
Mail list logo
