subject:"\[Bacula\-users\] Packet size too big"

Thanks Bill, you nailed it.

04-Jan-2022 16:13:52 FD: backup.c:1356-884680
fname=/Users/USER/Library/Containers/com.apple.Safari.CacheDeleteExtension
snap=/Users/USER/Library/Containers/com.apple.Safari.CacheDeleteExtension link=/Users/USER/Library/Containers/com.apple.Safari.CacheDeleteExtension/

Last file before error is thrown and job craps out.

I would if that's the only file, will try to exclude and see how far the
job can go.

Also, note a debug level of 150 is way more than needed to troubleshoot
this and I canceled attempt after trace file was 60G. level=10 was
enough to log which files were being backedup as well as the error that
terminated job.

Stephen

On 1/4/22 12:03 PM, Bill Arlofski via Bacula-users wrote:

On 1/4/22 12:26, Stephen Thompson wrote:

Yes, backing up a single file on my problem hosts does succeed.

H...

Stephen

Hello Stephen,

This issue looked familiar to me, so I checked internally and I think I found
something.

I am pretty sure that this is an issue due to the larger possible size of
extended attributes that Big Sur uses.

From what I can gather, this has been addressed and fixed in Bacula
Enterprise, and the fix will appear in the next Bacula
Community release. (no ETA that I am aware of yet, but I assume very soon)

In the case I found, running the FD in debug mode, level=150 revealed there was
an issue with one specific file:
8<
/Users//Library/Containers/com.apple.Safari.CacheDeleteExtension
8<

The temporary workaround at the time (Sept 2021) was to omit this file (or
whichever file your system is working on when the
job fails) from the backups.

No idea if this means much, but there was also a mention made: "this seems to be
related to Time Machine"

Setting the FD in debug mode:

* setdebug level=150 options=tc trace=1 client=

Then, run the backup until it fails, and stop debugging:

* setdebug level=0 trace=0 client=

In /opt/bacula/working on the FD (or wherever "WorkingDirectory" is set to),
there will be a *.trace file. You will be
looking for the file mentioned before the error:
8<
bxattr.c:310-69825 Network send error to SD. ERR=Broken pipe
8<

Hope this helps.
Bill

--
Bill Arlofski
w...@protonmail.com

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

--
Stephen Thompson Berkeley Seismology Lab
stephen.thomp...@berkeley.edu 307 McCone Hall
Office: 510.664.9177 University of California
Remote: 510.214.6506 (Tue) Berkeley, CA 94720-4760

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

Re: [Bacula-users] Packet size too big (NOT a version mismatch)

Sorry for giving the wrong path--I did mean the 'bacula_config' file in './etc'.

Large file support is off on my client too, so ignore me.

Just read the message from Bill, and that's all sounding plausible (I don't 
enable xattrs in the FileSet I back up, and local snapshots taken by Time 
Machine do add attributes to files).

Many thanks to Bill for showing how additional debugging can be used too.  I'm 
sure that will come in handy!

-- 
Graham Sparks


From: Graham Sparks 
Sent: 04 January 2022 19:55
To: bacula-users@lists.sourceforge.net 
Subject: Re: [Bacula-users] Packet size too big (NOT a version mismatch) 
 
I'm afraid I don't enable encryption in my backup jobs (I know I should ) so I 
don't know if that causes an issue.  I'll have a quick look some time to see 
what happens when I enable encryption.

I think I've reached my limit here, but it might be worth checking the 
following file to make sure all the compilation options took successfully 
(thinking aloud here, but "Large File Support" caught my attention):

$BHOME/bin/bacula_config

Thanks.
-- 
Graham Sparks


From: Stephen Thompson 
Sent: 04 January 2022 19:33
To: Martin Simmons
Cc: g...@hotmail.co.uk; bacula-users@lists.sourceforge.net 

Subject: Re: [Bacula-users] Packet size too big (NOT a version mismatch) 
 


However, even just backing up /Users results in...

04-Jan 11:31 SD JobId 88: Fatal error: bsock.c:530 Packet 
size=1387166 too big from "client:1.2.3.4:9103". Maximum permitted 
100. Terminating connection.


Stephen




On 1/4/22 11:26 AM, Stephen Thompson wrote:
> 
> 
> 
> Yes, backing up a single file on my problem hosts does succeed.
> 
> H...
> 
> Stephen
> 
> 
> 
> On 1/4/22 11:23 AM, Stephen Thompson wrote:
>>
>>
>> That's a good test, which I apparently have not tried.  I will do so.
>>
>> thanks,
>> Stephen
>>
>>
>> On 1/4/22 11:20 AM, Martin Simmons wrote:
>>> Is this happening for all backups?
>>>
>>> What happens if you run a backup with a minimal fileset that lists 
>>> just one
>>> small file?
>>>
>>> __Martin
>>>
>>>
>>>>>>>> On Tue, 4 Jan 2022 08:13:46 -0800, Stephen Thompson said:
>>>>
>>>> I am still seeing the same issue on Monterey as on Big Sur with 11.0.5
>>>> compiled from source and CoreFoundation linked in.
>>>>
>>>> 04-Jan 07:56 SD JobId 88: Fatal error: bsock.c:530 Packet 
>>>> size=1387165
>>>> too big from "client:1.2.3.4:9103". Maximum permitted 100. 
>>>> Terminating
>>>> connection.
>>>>
>>>>
>>>>
>>>> Stephen
>>>>
>>>> On Tue, Jan 4, 2022 at 7:02 AM Stephen Thompson <
>>>> stephen.thomp...@berkeley.edu> wrote:
>>>>
>>>>>
>>>>> Graham,
>>>>>
>>>>> Thanks for presenting Monterey as a possibility!  I am seeing the same
>>>>> issue under Monterrey as I have under Big Sur, but to know someone 
>>>>> else
>>>>> does not means that it's possible.  I should double check that I am 
>>>>> using a
>>>>> freshly compiled client on Monterey and not just the one that I 
>>>>> compiled on
>>>>> Big Sur.
>>>>>
>>>>> I am backing up Macs with bacula, but not really for system 
>>>>> recovery, more
>>>>> to backup user files/documents that they may not be backing up 
>>>>> themselves.
>>>>> I do note a number of Mac system files that refuse to be backed up, 
>>>>> but
>>>>> again for my purposes, I do not care too much.  It would be nice to 
>>>>> be able
>>>>> to BMR a Mac, but not a requirement where I am at, being 
>>>>> operationally a
>>>>> Linux shop.
>>>>>
>>>>> Stephen
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Jan 4, 2022 at 6:20 AM Graham Sparks  
>>>>> wrote:
>>>>>
>>>>>> Hi David,
>>>>>>
>>>>>> I use Time Machine (for the System disk) as well as Bacula on my 
>>>>>> Mac, as
>>>>>> I'd still need the Time Machine backup to do a bare-metal restore 
>>>>>> (with
>>>>>> Apps). I use Bacula to back up this and an external data drive.
>>>>>>
>>>>>> Rather than purchasing a separate "Time Capsule", I set up Samb

Re: [Bacula-users] Packet size too big (NOT a version mismatch)

I'm afraid I don't enable encryption in my backup jobs (I know I should ) so I 
don't know if that causes an issue.  I'll have a quick look some time to see 
what happens when I enable encryption.

I think I've reached my limit here, but it might be worth checking the 
following file to make sure all the compilation options took successfully 
(thinking aloud here, but "Large File Support" caught my attention):

$BHOME/bin/bacula_config

Thanks.
-- 
Graham Sparks


From: Stephen Thompson 
Sent: 04 January 2022 19:33
To: Martin Simmons
Cc: g...@hotmail.co.uk; bacula-users@lists.sourceforge.net 

Subject: Re: [Bacula-users] Packet size too big (NOT a version mismatch) 
 


However, even just backing up /Users results in...

04-Jan 11:31 SD JobId 88: Fatal error: bsock.c:530 Packet 
size=1387166 too big from "client:1.2.3.4:9103". Maximum permitted 
100. Terminating connection.


Stephen




On 1/4/22 11:26 AM, Stephen Thompson wrote:
> 
> 
> 
> Yes, backing up a single file on my problem hosts does succeed.
> 
> H...
> 
> Stephen
> 
> 
> 
> On 1/4/22 11:23 AM, Stephen Thompson wrote:
>>
>>
>> That's a good test, which I apparently have not tried.  I will do so.
>>
>> thanks,
>> Stephen
>>
>>
>> On 1/4/22 11:20 AM, Martin Simmons wrote:
>>> Is this happening for all backups?
>>>
>>> What happens if you run a backup with a minimal fileset that lists 
>>> just one
>>> small file?
>>>
>>> __Martin
>>>
>>>
>>>>>>>> On Tue, 4 Jan 2022 08:13:46 -0800, Stephen Thompson said:
>>>>
>>>> I am still seeing the same issue on Monterey as on Big Sur with 11.0.5
>>>> compiled from source and CoreFoundation linked in.
>>>>
>>>> 04-Jan 07:56 SD JobId 88: Fatal error: bsock.c:530 Packet 
>>>> size=1387165
>>>> too big from "client:1.2.3.4:9103". Maximum permitted 100. 
>>>> Terminating
>>>> connection.
>>>>
>>>>
>>>>
>>>> Stephen
>>>>
>>>> On Tue, Jan 4, 2022 at 7:02 AM Stephen Thompson <
>>>> stephen.thomp...@berkeley.edu> wrote:
>>>>
>>>>>
>>>>> Graham,
>>>>>
>>>>> Thanks for presenting Monterey as a possibility!  I am seeing the same
>>>>> issue under Monterrey as I have under Big Sur, but to know someone 
>>>>> else
>>>>> does not means that it's possible.  I should double check that I am 
>>>>> using a
>>>>> freshly compiled client on Monterey and not just the one that I 
>>>>> compiled on
>>>>> Big Sur.
>>>>>
>>>>> I am backing up Macs with bacula, but not really for system 
>>>>> recovery, more
>>>>> to backup user files/documents that they may not be backing up 
>>>>> themselves.
>>>>> I do note a number of Mac system files that refuse to be backed up, 
>>>>> but
>>>>> again for my purposes, I do not care too much.  It would be nice to 
>>>>> be able
>>>>> to BMR a Mac, but not a requirement where I am at, being 
>>>>> operationally a
>>>>> Linux shop.
>>>>>
>>>>> Stephen
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Jan 4, 2022 at 6:20 AM Graham Sparks  
>>>>> wrote:
>>>>>
>>>>>> Hi David,
>>>>>>
>>>>>> I use Time Machine (for the System disk) as well as Bacula on my 
>>>>>> Mac, as
>>>>>> I'd still need the Time Machine backup to do a bare-metal restore 
>>>>>> (with
>>>>>> Apps). I use Bacula to back up this and an external data drive.
>>>>>>
>>>>>> Rather than purchasing a separate "Time Capsule", I set up Samba on a
>>>>>> Linux VM to expose an SMB share that the Mac sees as a Time 
>>>>>> Capsule drive (
>>>>>> https://wiki.samba.org/index.php/Configure_Samba_to_Work_Better_with_Mac_OS_X
>>>>>>  
>>>>>>
>>>>>> ).
>>>>>>
>>>>>> I had one problem with Time Machine a few months ago, where it 
>>>>>> stopped
>>>>>> backing up data and insisted on starting the backup 'chain' from 
>>>>>> scratch
>>>>>> again.  I was a lit

Re: [Bacula-users] Packet size too big (NOT a version mismatch)

2022-01-04 Thread Bill Arlofski via Bacula-users

On 1/4/22 12:26, Stephen Thompson wrote:
>
> Yes, backing up a single file on my problem hosts does succeed.
>
> H...
>
> Stephen

Hello Stephen,

This issue looked familiar to me, so I checked internally and I think I found 
something.

I am pretty sure that this is an issue due to the larger possible size of 
extended attributes that Big Sur uses.

 From what I can gather, this has been addressed and fixed in Bacula 
Enterprise, and the fix will appear in the next Bacula
Community release. (no ETA that I am aware of yet, but I assume very soon)

In the case I found, running the FD in debug mode, level=150 revealed there was 
an issue with one specific file:
8<
/Users//Library/Containers/com.apple.Safari.CacheDeleteExtension
8<

The temporary workaround at the time (Sept 2021) was to omit this file (or 
whichever file your system is working on when the
job fails) from the backups.

No idea if this means much, but there was also a mention made: "this seems to 
be related to Time Machine"

Setting the FD in debug mode:

* setdebug level=150 options=tc trace=1 client=

Then, run the backup until it fails, and stop debugging:

* setdebug level=0 trace=0 client=

In /opt/bacula/working on the FD (or wherever "WorkingDirectory" is set to), 
there will be a *.trace file. You will be
looking for the file mentioned before the error:
8<
bxattr.c:310-69825 Network send error to SD. ERR=Broken pipe
8<

Hope this helps.
Bill

--
Bill Arlofski
w...@protonmail.com

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

Re: [Bacula-users] Packet size too big (NOT a version mismatch)




Thanks.
I have large file support off, though I am not sure that's intentional. 
 I will double check that.



On 1/4/22 11:55 AM, Graham Sparks wrote:

I'm afraid I don't enable encryption in my backup jobs (I know I should ) so I 
don't know if that causes an issue.  I'll have a quick look some time to see 
what happens when I enable encryption.

I think I've reached my limit here, but it might be worth checking the following file to 
make sure all the compilation options took successfully (thinking aloud here, but 
"Large File Support" caught my attention):

$BHOME/bin/bacula_config

Thanks.


--
Stephen Thompson   Berkeley Seismology Lab
stephen.thomp...@berkeley.edu  307 McCone Hall
Office: 510.664.9177   University of California
Remote: 510.214.6506 (Tue) Berkeley, CA 94720-4760


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

Re: [Bacula-users] Packet size too big (NOT a version mismatch)




However, even just backing up /Users results in...

04-Jan 11:31 SD JobId 88: Fatal error: bsock.c:530 Packet 
size=1387166 too big from "client:1.2.3.4:9103". Maximum permitted 
100. Terminating connection.



Stephen




On 1/4/22 11:26 AM, Stephen Thompson wrote:




Yes, backing up a single file on my problem hosts does succeed.

H...

Stephen



On 1/4/22 11:23 AM, Stephen Thompson wrote:



That's a good test, which I apparently have not tried.  I will do so.

thanks,
Stephen


On 1/4/22 11:20 AM, Martin Simmons wrote:

Is this happening for all backups?

What happens if you run a backup with a minimal fileset that lists 
just one

small file?

__Martin



On Tue, 4 Jan 2022 08:13:46 -0800, Stephen Thompson said:


I am still seeing the same issue on Monterey as on Big Sur with 11.0.5
compiled from source and CoreFoundation linked in.

04-Jan 07:56 SD JobId 88: Fatal error: bsock.c:530 Packet 
size=1387165
too big from "client:1.2.3.4:9103". Maximum permitted 100. 
Terminating

connection.



Stephen

On Tue, Jan 4, 2022 at 7:02 AM Stephen Thompson <
stephen.thomp...@berkeley.edu> wrote:



Graham,

Thanks for presenting Monterey as a possibility!  I am seeing the same
issue under Monterrey as I have under Big Sur, but to know someone 
else
does not means that it's possible.  I should double check that I am 
using a
freshly compiled client on Monterey and not just the one that I 
compiled on

Big Sur.

I am backing up Macs with bacula, but not really for system 
recovery, more
to backup user files/documents that they may not be backing up 
themselves.
I do note a number of Mac system files that refuse to be backed up, 
but
again for my purposes, I do not care too much.  It would be nice to 
be able
to BMR a Mac, but not a requirement where I am at, being 
operationally a

Linux shop.

Stephen




On Tue, Jan 4, 2022 at 6:20 AM Graham Sparks  
wrote:



Hi David,

I use Time Machine (for the System disk) as well as Bacula on my 
Mac, as
I'd still need the Time Machine backup to do a bare-metal restore 
(with

Apps). I use Bacula to back up this and an external data drive.

Rather than purchasing a separate "Time Capsule", I set up Samba on a
Linux VM to expose an SMB share that the Mac sees as a Time 
Capsule drive (
https://wiki.samba.org/index.php/Configure_Samba_to_Work_Better_with_Mac_OS_X 


).

I had one problem with Time Machine a few months ago, where it 
stopped
backing up data and insisted on starting the backup 'chain' from 
scratch

again.  I was a little miffed .

I'm afraid I can only confirm that the Bacula v9.6 and v11 file 
daemons
worked for me under macOS Catalina and Monetery (I skipped Big 
Sur.  Not
for good reason---just laziness).  Both v9 and v11 clients were 
compiled
from source (setting the linker flags to "-framework 
CoreFoundation" as

already suggested).

I've personally not run in to problems with System Integrity 
Protection,

although I do give the bacula-fd executable "Full Disk" permissions.

Thanks.
--
Graham Sparks



From: David Brodbeck 
Sent: 03 January 2022 18:36
Cc: bacula-users@lists.sourceforge.net <
bacula-users@lists.sourceforge.net>
Subject: Re: [Bacula-users] Packet size too big (NOT a version 
mismatch)


I'm curious if anyone has moved away from Bacula on macOS and what
alternatives they're using. Even before this, it was getting more 
and more
awkward to set up -- bacula really doesn't play well with SIP, for 
example,

and running "csrutil disable" on every system is not a security best
practice.

On Wed, Dec 8, 2021 at 4:46 PM Stephen Thompson <
stephen.thomp...@berkeley.edu> wrote:


Disappointing...  I am having the same issue on BigSur with the 
11.0.5

release as I had with 9x.

08-Dec 15:42 SD JobId 878266: Fatal error: bsock.c:530 Packet
size=1387166 too big from "client:1.2.3.4:8103". Maximum permitted
100. Terminating connection.


Setting 'Maximum Network Buffer Size' does not appear to solve issue.
Are there users out there successfully running a bacula client on Big
Sur??
Stephen



On Wed, Dec 1, 2021 at 3:25 PM Stephen Thompson <
stephen.thomp...@berkeley.edu> wrote:

Not sure if this is correct, but I've been able to at least compile
bacula client 11.0.5 on Big Sur by doing before configure step:

LDFLAGS='-framework CoreFoundation'

We'll see next up whether it runs and whether it exhibits the 
issue seen

under Big Sur for 9x client.

Stephen

On Tue, Nov 23, 2021 at 7:32 AM Stephen Thompson <
stephen.thomp...@berkeley.edu> wrote:

Josh,

Thanks for the tip.  That did not appear to be the cause of this 
issue,
though perhaps it will fix a yet to be found issue that I would 
have run

into after I get past this compilation error.

Stephen



On Mon, Nov 22, 2021 at 9:22 AM Josh Fisher  
wrote:


On 11/22/21 10:46, Stephen Thompson wrote:

All,

I too was having the issue with running a 9x client on Big

Re: [Bacula-users] Packet size too big (NOT a version mismatch)

Graham,

Thanks.

I am confident that it's not a networking issue (at least one external
to the Macs). The new problem only shows on hosts that have been
updated to Big Sur or Monterey (with or without rebuilt client, both 9x
and 11s). High Sierra and earlier hosts never yield the 'too big...
Maximum permitted 100' error, but Big Sur/Monterey always do.

I use xcode along with homebrew openssl 1.1.

To further describe, the BigSur/Monterrey host jobs do partially
complete, successfully sending many GBs of data and files, including a
few warnings about unreadable system files, but ultimately the jobs crap
out with the same error.

My build options...

BHOME=/Users/bacula
EMAIL=bacula@DOMAINNAME

env CFLAGS='-g -O2' LDFLAGS='-framework CoreFoundation' \
./configure \
--prefix=$BHOME \
--sbindir=$BHOME/bin \
--sysconfdir=$BHOME/conf \
--with-working-dir=$BHOME/work \
--with-archivedir=$BHOME/archive \
--with-bsrdir=$BHOME/log \
--with-logdir=$BHOME/log \
--with-pid-dir=/var/run \
--with-subsys-dir=/var/run \
--with-basename=SERVER \
--with-hostname=SERVER.DOMAINNAME \
--with-dump-email=$EMAIL \
--with-openssl=/usr/local/opt/openssl\@1.1 \
--enable-smartalloc \
--disable-readline \
--enable-conio \
--enable-client-only \
| tee configure.out

thanks again,
Stephen

On 1/4/22 10:54 AM, Graham Sparks wrote:

Hi Stephen,

I've had a quick read of the archive (I'm late to the mailing list party) and
see you've tried lots, so I'll try to say something constructive.

I tried to recreate the packet size error, crudely, by directing the Bacula server to a
web page instead of the client FD (incidentally, this recreates it well). Therefore, I
think it's worth making sure the server and client are communicating without
interruption, just in case something else is being returned (perhaps a transparent
proxy/firewall/web filter "blocked" message, or similar).

Maybe try:

1. "status client=" in bconsole to check Bacula can communicate
with the client.
2. If not, issue "lsof -i -P | grep 9102" at the terminal on the client, to
make sure 'bacula-fd' is running (on the default port).
3. If 'bacula-fd' is listed as running, stop the Bacula File Daemon on the client to free port 9102,
then run "nc -l 9102" to open a listener on the same port the file daemon uses, and send some
text from the Bacula server using "nc 9102". If TCP communications are
good, you should see exactly the text you type on the server appear on the Mac's terminal after pressing
return.

Sorry in advance if this is stuff you've already tried.

Just for completeness, one of the few things I have done to the Mac in question
is install Xcode (I think it replaces the shipped installation of 'make', so
there's a chance it affects compilation).

I'm not a big Mac user, I'm afraid. It seems that just owning a Mac automatically makes
one the "Mac guy" .

Thanks.

--
Stephen Thompson Berkeley Seismology Lab
stephen.thomp...@berkeley.edu 307 McCone Hall
Office: 510.664.9177 University of California
Remote: 510.214.6506 (Tue) Berkeley, CA 94720-4760

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

Re: [Bacula-users] Packet size too big (NOT a version mismatch)





Yes, backing up a single file on my problem hosts does succeed.

H...

Stephen



On 1/4/22 11:23 AM, Stephen Thompson wrote:



That's a good test, which I apparently have not tried.  I will do so.

thanks,
Stephen


On 1/4/22 11:20 AM, Martin Simmons wrote:

Is this happening for all backups?

What happens if you run a backup with a minimal fileset that lists 
just one

small file?

__Martin



On Tue, 4 Jan 2022 08:13:46 -0800, Stephen Thompson said:


I am still seeing the same issue on Monterey as on Big Sur with 11.0.5
compiled from source and CoreFoundation linked in.

04-Jan 07:56 SD JobId 88: Fatal error: bsock.c:530 Packet 
size=1387165
too big from "client:1.2.3.4:9103". Maximum permitted 100. 
Terminating

connection.



Stephen

On Tue, Jan 4, 2022 at 7:02 AM Stephen Thompson <
stephen.thomp...@berkeley.edu> wrote:



Graham,

Thanks for presenting Monterey as a possibility!  I am seeing the same
issue under Monterrey as I have under Big Sur, but to know someone else
does not means that it's possible.  I should double check that I am 
using a
freshly compiled client on Monterey and not just the one that I 
compiled on

Big Sur.

I am backing up Macs with bacula, but not really for system 
recovery, more
to backup user files/documents that they may not be backing up 
themselves.

I do note a number of Mac system files that refuse to be backed up, but
again for my purposes, I do not care too much.  It would be nice to 
be able
to BMR a Mac, but not a requirement where I am at, being 
operationally a

Linux shop.

Stephen




On Tue, Jan 4, 2022 at 6:20 AM Graham Sparks  
wrote:



Hi David,

I use Time Machine (for the System disk) as well as Bacula on my 
Mac, as
I'd still need the Time Machine backup to do a bare-metal restore 
(with

Apps). I use Bacula to back up this and an external data drive.

Rather than purchasing a separate "Time Capsule", I set up Samba on a
Linux VM to expose an SMB share that the Mac sees as a Time Capsule 
drive (
https://wiki.samba.org/index.php/Configure_Samba_to_Work_Better_with_Mac_OS_X 


).

I had one problem with Time Machine a few months ago, where it stopped
backing up data and insisted on starting the backup 'chain' from 
scratch

again.  I was a little miffed .

I'm afraid I can only confirm that the Bacula v9.6 and v11 file 
daemons
worked for me under macOS Catalina and Monetery (I skipped Big 
Sur.  Not
for good reason---just laziness).  Both v9 and v11 clients were 
compiled
from source (setting the linker flags to "-framework 
CoreFoundation" as

already suggested).

I've personally not run in to problems with System Integrity 
Protection,

although I do give the bacula-fd executable "Full Disk" permissions.

Thanks.
--
Graham Sparks



From: David Brodbeck 
Sent: 03 January 2022 18:36
Cc: bacula-users@lists.sourceforge.net <
bacula-users@lists.sourceforge.net>
Subject: Re: [Bacula-users] Packet size too big (NOT a version 
mismatch)


I'm curious if anyone has moved away from Bacula on macOS and what
alternatives they're using. Even before this, it was getting more 
and more
awkward to set up -- bacula really doesn't play well with SIP, for 
example,

and running "csrutil disable" on every system is not a security best
practice.

On Wed, Dec 8, 2021 at 4:46 PM Stephen Thompson <
stephen.thomp...@berkeley.edu> wrote:


Disappointing...  I am having the same issue on BigSur with the 11.0.5
release as I had with 9x.

08-Dec 15:42 SD JobId 878266: Fatal error: bsock.c:530 Packet
size=1387166 too big from "client:1.2.3.4:8103". Maximum permitted
100. Terminating connection.


Setting 'Maximum Network Buffer Size' does not appear to solve issue.
Are there users out there successfully running a bacula client on Big
Sur??
Stephen



On Wed, Dec 1, 2021 at 3:25 PM Stephen Thompson <
stephen.thomp...@berkeley.edu> wrote:

Not sure if this is correct, but I've been able to at least compile
bacula client 11.0.5 on Big Sur by doing before configure step:

LDFLAGS='-framework CoreFoundation'

We'll see next up whether it runs and whether it exhibits the issue 
seen

under Big Sur for 9x client.

Stephen

On Tue, Nov 23, 2021 at 7:32 AM Stephen Thompson <
stephen.thomp...@berkeley.edu> wrote:

Josh,

Thanks for the tip.  That did not appear to be the cause of this 
issue,
though perhaps it will fix a yet to be found issue that I would 
have run

into after I get past this compilation error.

Stephen



On Mon, Nov 22, 2021 at 9:22 AM Josh Fisher  
wrote:


On 11/22/21 10:46, Stephen Thompson wrote:

All,

I too was having the issue with running a 9x client on Big Sur.  I've
tried compiling 11.0.5 but have not found my way past:

This might be due to a libtool.m4 bug having to do with MacOS changing
the major Darwin version from 19.x to 20.x. There is a patch at
https://www.mail-archive.com/libtool-patches@gnu.org/msg07396.html


Linking bacula-fd ...
/U

Re: [Bacula-users] Packet size too big (NOT a version mismatch)




That's a good test, which I apparently have not tried.  I will do so.

thanks,
Stephen


On 1/4/22 11:20 AM, Martin Simmons wrote:

Is this happening for all backups?

What happens if you run a backup with a minimal fileset that lists just one
small file?

__Martin



On Tue, 4 Jan 2022 08:13:46 -0800, Stephen Thompson said:


I am still seeing the same issue on Monterey as on Big Sur with 11.0.5
compiled from source and CoreFoundation linked in.

04-Jan 07:56 SD JobId 88: Fatal error: bsock.c:530 Packet size=1387165
too big from "client:1.2.3.4:9103". Maximum permitted 100. Terminating
connection.



Stephen

On Tue, Jan 4, 2022 at 7:02 AM Stephen Thompson <
stephen.thomp...@berkeley.edu> wrote:



Graham,

Thanks for presenting Monterey as a possibility!  I am seeing the same
issue under Monterrey as I have under Big Sur, but to know someone else
does not means that it's possible.  I should double check that I am using a
freshly compiled client on Monterey and not just the one that I compiled on
Big Sur.

I am backing up Macs with bacula, but not really for system recovery, more
to backup user files/documents that they may not be backing up themselves.
I do note a number of Mac system files that refuse to be backed up, but
again for my purposes, I do not care too much.  It would be nice to be able
to BMR a Mac, but not a requirement where I am at, being operationally a
Linux shop.

Stephen




On Tue, Jan 4, 2022 at 6:20 AM Graham Sparks  wrote:


Hi David,

I use Time Machine (for the System disk) as well as Bacula on my Mac, as
I'd still need the Time Machine backup to do a bare-metal restore (with
Apps). I use Bacula to back up this and an external data drive.

Rather than purchasing a separate "Time Capsule", I set up Samba on a
Linux VM to expose an SMB share that the Mac sees as a Time Capsule drive (
https://wiki.samba.org/index.php/Configure_Samba_to_Work_Better_with_Mac_OS_X
).

I had one problem with Time Machine a few months ago, where it stopped
backing up data and insisted on starting the backup 'chain' from scratch
again.  I was a little miffed .

I'm afraid I can only confirm that the Bacula v9.6 and v11 file daemons
worked for me under macOS Catalina and Monetery (I skipped Big Sur.  Not
for good reason---just laziness).  Both v9 and v11 clients were compiled
from source (setting the linker flags to "-framework CoreFoundation" as
already suggested).

I've personally not run in to problems with System Integrity Protection,
although I do give the bacula-fd executable "Full Disk" permissions.

Thanks.
--
Graham Sparks



From: David Brodbeck 
Sent: 03 January 2022 18:36
Cc: bacula-users@lists.sourceforge.net <
bacula-users@lists.sourceforge.net>
Subject: Re: [Bacula-users] Packet size too big (NOT a version mismatch)

I'm curious if anyone has moved away from Bacula on macOS and what
alternatives they're using. Even before this, it was getting more and more
awkward to set up -- bacula really doesn't play well with SIP, for example,
and running "csrutil disable" on every system is not a security best
practice.

On Wed, Dec 8, 2021 at 4:46 PM Stephen Thompson <
stephen.thomp...@berkeley.edu> wrote:


Disappointing...  I am having the same issue on BigSur with the 11.0.5
release as I had with 9x.

08-Dec 15:42 SD JobId 878266: Fatal error: bsock.c:530 Packet
size=1387166 too big from "client:1.2.3.4:8103". Maximum permitted
100. Terminating connection.


Setting 'Maximum Network Buffer Size' does not appear to solve issue.
Are there users out there successfully running a bacula client on Big
Sur??
Stephen



On Wed, Dec 1, 2021 at 3:25 PM Stephen Thompson <
stephen.thomp...@berkeley.edu> wrote:

Not sure if this is correct, but I've been able to at least compile
bacula client 11.0.5 on Big Sur by doing before configure step:

LDFLAGS='-framework CoreFoundation'

We'll see next up whether it runs and whether it exhibits the issue seen
under Big Sur for 9x client.

Stephen

On Tue, Nov 23, 2021 at 7:32 AM Stephen Thompson <
stephen.thomp...@berkeley.edu> wrote:

Josh,

Thanks for the tip.  That did not appear to be the cause of this issue,
though perhaps it will fix a yet to be found issue that I would have run
into after I get past this compilation error.

Stephen



On Mon, Nov 22, 2021 at 9:22 AM Josh Fisher  wrote:

On 11/22/21 10:46, Stephen Thompson wrote:

All,

I too was having the issue with running a 9x client on Big Sur.  I've
tried compiling 11.0.5 but have not found my way past:

This might be due to a libtool.m4 bug having to do with MacOS changing
the major Darwin version from 19.x to 20.x. There is a patch at
https://www.mail-archive.com/libtool-patches@gnu.org/msg07396.html


Linking bacula-fd ...
/Users/bacula/src/bacula-11.0.5-CLIENT.MAC/libtool --silent --tag=CXX
--mode=link /usr/bin/g++   -L../lib -L../findlib -o bacula-fd filed.o
authenticate.o backup.o crypto.o win

Re: [Bacula-users] Packet size too big (NOT a version mismatch)

2022-01-04 Thread Martin Simmons

Is this happening for all backups?

What happens if you run a backup with a minimal fileset that lists just one
small file?

__Martin


>>>>> On Tue, 4 Jan 2022 08:13:46 -0800, Stephen Thompson said:
> 
> I am still seeing the same issue on Monterey as on Big Sur with 11.0.5
> compiled from source and CoreFoundation linked in.
> 
> 04-Jan 07:56 SD JobId 88: Fatal error: bsock.c:530 Packet size=1387165
> too big from "client:1.2.3.4:9103". Maximum permitted 100. Terminating
> connection.
> 
> 
> 
> Stephen
> 
> On Tue, Jan 4, 2022 at 7:02 AM Stephen Thompson <
> stephen.thomp...@berkeley.edu> wrote:
> 
> >
> > Graham,
> >
> > Thanks for presenting Monterey as a possibility!  I am seeing the same
> > issue under Monterrey as I have under Big Sur, but to know someone else
> > does not means that it's possible.  I should double check that I am using a
> > freshly compiled client on Monterey and not just the one that I compiled on
> > Big Sur.
> >
> > I am backing up Macs with bacula, but not really for system recovery, more
> > to backup user files/documents that they may not be backing up themselves.
> > I do note a number of Mac system files that refuse to be backed up, but
> > again for my purposes, I do not care too much.  It would be nice to be able
> > to BMR a Mac, but not a requirement where I am at, being operationally a
> > Linux shop.
> >
> > Stephen
> >
> >
> >
> >
> > On Tue, Jan 4, 2022 at 6:20 AM Graham Sparks  wrote:
> >
> >> Hi David,
> >>
> >> I use Time Machine (for the System disk) as well as Bacula on my Mac, as
> >> I'd still need the Time Machine backup to do a bare-metal restore (with
> >> Apps). I use Bacula to back up this and an external data drive.
> >>
> >> Rather than purchasing a separate "Time Capsule", I set up Samba on a
> >> Linux VM to expose an SMB share that the Mac sees as a Time Capsule drive (
> >> https://wiki.samba.org/index.php/Configure_Samba_to_Work_Better_with_Mac_OS_X
> >> ).
> >>
> >> I had one problem with Time Machine a few months ago, where it stopped
> >> backing up data and insisted on starting the backup 'chain' from scratch
> >> again.  I was a little miffed .
> >>
> >> I'm afraid I can only confirm that the Bacula v9.6 and v11 file daemons
> >> worked for me under macOS Catalina and Monetery (I skipped Big Sur.  Not
> >> for good reason---just laziness).  Both v9 and v11 clients were compiled
> >> from source (setting the linker flags to "-framework CoreFoundation" as
> >> already suggested).
> >>
> >> I've personally not run in to problems with System Integrity Protection,
> >> although I do give the bacula-fd executable "Full Disk" permissions.
> >>
> >> Thanks.
> >> --
> >> Graham Sparks
> >>
> >>
> >>
> >> From: David Brodbeck 
> >> Sent: 03 January 2022 18:36
> >> Cc: bacula-users@lists.sourceforge.net <
> >> bacula-users@lists.sourceforge.net>
> >> Subject: Re: [Bacula-users] Packet size too big (NOT a version mismatch)
> >>
> >> I'm curious if anyone has moved away from Bacula on macOS and what
> >> alternatives they're using. Even before this, it was getting more and more
> >> awkward to set up -- bacula really doesn't play well with SIP, for example,
> >> and running "csrutil disable" on every system is not a security best
> >> practice.
> >>
> >> On Wed, Dec 8, 2021 at 4:46 PM Stephen Thompson <
> >> stephen.thomp...@berkeley.edu> wrote:
> >>
> >>
> >> Disappointing...  I am having the same issue on BigSur with the 11.0.5
> >> release as I had with 9x.
> >>
> >> 08-Dec 15:42 SD JobId 878266: Fatal error: bsock.c:530 Packet
> >> size=1387166 too big from "client:1.2.3.4:8103". Maximum permitted
> >> 100. Terminating connection.
> >>
> >>
> >> Setting 'Maximum Network Buffer Size' does not appear to solve issue.
> >> Are there users out there successfully running a bacula client on Big
> >> Sur??
> >> Stephen
> >>
> >>
> >>
> >> On Wed, Dec 1, 2021 at 3:25 PM Stephen Thompson <
> >> stephen.thomp...@berkeley.edu> wrote:
> >>
> >> Not sure if this is correct, but I've been able to at least compile
> >> bacula client 11.0.5 on Big Sur by doing before configure step:
>

Re: [Bacula-users] Packet size too big (NOT a version mismatch)

Hi Stephen,

I've had a quick read of the archive (I'm late to the mailing list party) and 
see you've tried lots, so I'll try to say something constructive.

I tried to recreate the packet size error, crudely, by directing the Bacula 
server to a web page instead of the client FD (incidentally, this recreates it 
well).  Therefore, I think it's worth making sure the server and client are 
communicating without interruption, just in case something else is being 
returned (perhaps a transparent proxy/firewall/web filter "blocked" message, or 
similar).

Maybe try:

1.  "status client=" in bconsole to check Bacula can communicate 
with the client.
2.  If not, issue "lsof -i -P | grep 9102" at the terminal on the client, to 
make sure 'bacula-fd' is running (on the default port).
3.  If 'bacula-fd' is listed as running, stop the Bacula File Daemon on the 
client to free port 9102, then run "nc -l 9102" to open a listener on the same 
port the file daemon uses, and send some text from the Bacula server using "nc 
 9102".  If TCP communications are good, you should see exactly 
the text you type on the server appear on the Mac's terminal after pressing 
return.

Sorry in advance if this is stuff you've already tried.

Just for completeness, one of the few things I have done to the Mac in question 
is install Xcode (I think it replaces the shipped installation of 'make', so 
there's a chance it affects compilation).

I'm not a big Mac user, I'm afraid.  It seems that just owning a Mac 
automatically makes one the "Mac guy" .

Thanks.
-- 
Graham Sparks


From: Stephen Thompson
Sent: 04 January 2022 16:13
To: Graham Sparks 
Cc: bacula-users@lists.sourceforge.net 
Subject: Re: [Bacula-users] Packet size too big (NOT a version mismatch) 
 

I am still seeing the same issue on Monterey as on Big Sur with 11.0.5 compiled 
from source and CoreFoundation linked in.

04-Jan 07:56 SD JobId 88: Fatal error: bsock.c:530 Packet size=1387165 too 
big from "client:1.2.3.4:9103". Maximum permitted 100. Terminating 
connection.


Stephen

On Tue, Jan 4, 2022 at 7:02 AM Stephen Thompson  
wrote:

Graham,

Thanks for presenting Monterey as a possibility!  I am seeing the same issue 
under Monterrey as I have under Big Sur, but to know someone else does not 
means that it's possible.  I should double check that I am using a freshly 
compiled client on Monterey and not just the one that I compiled on Big Sur.

I am backing up Macs with bacula, but not really for system recovery, more to 
backup user files/documents that they may not be backing up themselves.  I do 
note a number of Mac system files that refuse to be backed up, but again for my 
purposes, I do not care too much.  It would be nice to be able to BMR a Mac, 
but not a requirement where I am at, being operationally a Linux shop.

Stephen




On Tue, Jan 4, 2022 at 6:20 AM Graham Sparks  wrote:
Hi David,

I use Time Machine (for the System disk) as well as Bacula on my Mac, as I'd 
still need the Time Machine backup to do a bare-metal restore (with Apps). I 
use Bacula to back up this and an external data drive.

Rather than purchasing a separate "Time Capsule", I set up Samba on a Linux VM 
to expose an SMB share that the Mac sees as a Time Capsule drive 
(https://wiki.samba.org/index.php/Configure_Samba_to_Work_Better_with_Mac_OS_X).

I had one problem with Time Machine a few months ago, where it stopped backing 
up data and insisted on starting the backup 'chain' from scratch again.  I was 
a little miffed .

I'm afraid I can only confirm that the Bacula v9.6 and v11 file daemons worked 
for me under macOS Catalina and Monetery (I skipped Big Sur.  Not for good 
reason---just laziness).  Both v9 and v11 clients were compiled from source 
(setting the linker flags to "-framework CoreFoundation" as already suggested).

I've personally not run in to problems with System Integrity Protection, 
although I do give the bacula-fd executable "Full Disk" permissions.

Thanks.
-- 
Graham Sparks



From: David Brodbeck 
Sent: 03 January 2022 18:36
Cc: bacula-users@lists.sourceforge.net 
Subject: Re: [Bacula-users] Packet size too big (NOT a version mismatch) 
 
I'm curious if anyone has moved away from Bacula on macOS and what alternatives 
they're using. Even before this, it was getting more and more awkward to set up 
-- bacula really doesn't play well with SIP, for example, and running "csrutil 
disable" on every system is not a security best practice.

On Wed, Dec 8, 2021 at 4:46 PM Stephen Thompson  
wrote:


Disappointing...  I am having the same issue on BigSur with the 11.0.5 release 
as I had with 9x.

08-Dec 15:42 SD JobId 878266: Fatal error: bsock.c:530 Packet size=1387166 too 
big from "client:1.2.3.4:8103". Maximum permitted 100. Terminating 
connection.


Setting 'Maximum Network Buffer Size' does not appear to solve issue.
Are t

Re: [Bacula-users] Packet size too big (NOT a version mismatch)

Hi David,

I use Time Machine (for the System disk) as well as Bacula on my Mac, as I'd 
still need the Time Machine backup to do a bare-metal restore (with Apps). I 
use Bacula to back up this and an external data drive.

Rather than purchasing a separate "Time Capsule", I set up Samba on a Linux VM 
to expose an SMB share that the Mac sees as a Time Capsule drive 
(https://wiki.samba.org/index.php/Configure_Samba_to_Work_Better_with_Mac_OS_X).

I had one problem with Time Machine a few months ago, where it stopped backing 
up data and insisted on starting the backup 'chain' from scratch again.  I was 
a little miffed .

I'm afraid I can only confirm that the Bacula v9.6 and v11 file daemons worked 
for me under macOS Catalina and Monetery (I skipped Big Sur.  Not for good 
reason---just laziness).  Both v9 and v11 clients were compiled from source 
(setting the linker flags to "-framework CoreFoundation" as already suggested).

I've personally not run in to problems with System Integrity Protection, 
although I do give the bacula-fd executable "Full Disk" permissions.

Thanks.
-- 
Graham Sparks

From: David Brodbeck 
Sent: 03 January 2022 18:36
Cc: bacula-users@lists.sourceforge.net 
Subject: Re: [Bacula-users] Packet size too big (NOT a version mismatch) 

I'm curious if anyone has moved away from Bacula on macOS and what alternatives 
they're using. Even before this, it was getting more and more awkward to set up 
-- bacula really doesn't play well with SIP, for example, and running "csrutil 
disable" on every system is not a security best practice.

On Wed, Dec 8, 2021 at 4:46 PM Stephen Thompson  
wrote:

Disappointing...  I am having the same issue on BigSur with the 11.0.5 release 
as I had with 9x.

08-Dec 15:42 SD JobId 878266: Fatal error: bsock.c:530 Packet size=1387166 too 
big from "client:1.2.3.4:8103". Maximum permitted 100. Terminating 
connection.

Setting 'Maximum Network Buffer Size' does not appear to solve issue.
Are there users out there successfully running a bacula client on Big Sur??
Stephen

On Wed, Dec 1, 2021 at 3:25 PM Stephen Thompson  
wrote:

Not sure if this is correct, but I've been able to at least compile bacula 
client 11.0.5 on Big Sur by doing before configure step:

LDFLAGS='-framework CoreFoundation'

We'll see next up whether it runs and whether it exhibits the issue seen under 
Big Sur for 9x client.

Stephen

On Tue, Nov 23, 2021 at 7:32 AM Stephen Thompson 
 wrote:

Josh,

Thanks for the tip.  That did not appear to be the cause of this issue, though 
perhaps it will fix a yet to be found issue that I would have run into after I 
get past this compilation error.

Stephen

On Mon, Nov 22, 2021 at 9:22 AM Josh Fisher  wrote:

On 11/22/21 10:46, Stephen Thompson wrote:

All,

I too was having the issue with running a 9x client on Big Sur.  I've tried 
compiling 11.0.5 but have not found my way past:

This might be due to a libtool.m4 bug having to do with MacOS changing the 
major Darwin version from 19.x to 20.x. There is a patch at 
https://www.mail-archive.com/libtool-patches@gnu.org/msg07396.html

Linking bacula-fd ...
/Users/bacula/src/bacula-11.0.5-CLIENT.MAC/libtool --silent --tag=CXX 
--mode=link /usr/bin/g++   -L../lib -L../findlib -o bacula-fd filed.o 
authenticate.o backup.o crypto.o win_efs.o estimate.o fdcollect.o fd_plugins.o 
accurate.o bacgpfs.o filed_conf.o runres_conf.o heartbeat.o hello.o job.o 
fd_snapshot.o restore.o status.o verify.o verify_vol.o fdcallsdir.o suspend.o 
org_filed_dedup.o bacl.o bacl_osx.o bxattr.o bxattr_osx.o \
    -lz -lbacfind -lbaccfg -lbac -lm -lpthread  \
    -L/usr/local/opt/openssl@1.1/lib -lssl -lcrypto    -framework IOKit
Undefined symbols for architecture x86_64:
  "___CFConstantStringClassReference", referenced from:
      CFString in suspend.o
      CFString in suspend.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [bacula-fd] Error 1

Seems like this might have something to do with the expection of headers being 
here:
/System/Library/Frameworks/CoreFoundation.framework/Headers
when they are here:
/Library/Developer/CommandLineTools/SDKs/MacOSX11.0.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/
but that may be a red herring.

There also appears to be a 'clang' in two locations on OS X, /usr and xcode 
subdir.  Hmm

Stephen

On Tue, Nov 16, 2021 at 12:00 AM Eric Bollengier via Bacula-users 
 wrote:
Hello,

On 11/15/21 21:46, David Brodbeck wrote:
> To do that I'd have to upgrade the director and the storage first, right?
> (Director can't be an earlier version than the FD, and the SD must have the
> same version as the director.)

In general yes, the code is designed to support Old FDs but can have problems
with newer FDs. In your case it may work.

At least, you can try a status client to see if the problem i

Re: [Bacula-users] Packet size too big (NOT a version mismatch)

I am still seeing the same issue on Monterey as on Big Sur with 11.0.5
compiled from source and CoreFoundation linked in.

04-Jan 07:56 SD JobId 88: Fatal error: bsock.c:530 Packet size=1387165
too big from "client:1.2.3.4:9103". Maximum permitted 100. Terminating
connection.



Stephen

On Tue, Jan 4, 2022 at 7:02 AM Stephen Thompson <
stephen.thomp...@berkeley.edu> wrote:

>
> Graham,
>
> Thanks for presenting Monterey as a possibility!  I am seeing the same
> issue under Monterrey as I have under Big Sur, but to know someone else
> does not means that it's possible.  I should double check that I am using a
> freshly compiled client on Monterey and not just the one that I compiled on
> Big Sur.
>
> I am backing up Macs with bacula, but not really for system recovery, more
> to backup user files/documents that they may not be backing up themselves.
> I do note a number of Mac system files that refuse to be backed up, but
> again for my purposes, I do not care too much.  It would be nice to be able
> to BMR a Mac, but not a requirement where I am at, being operationally a
> Linux shop.
>
> Stephen
>
>
>
>
> On Tue, Jan 4, 2022 at 6:20 AM Graham Sparks  wrote:
>
>> Hi David,
>>
>> I use Time Machine (for the System disk) as well as Bacula on my Mac, as
>> I'd still need the Time Machine backup to do a bare-metal restore (with
>> Apps). I use Bacula to back up this and an external data drive.
>>
>> Rather than purchasing a separate "Time Capsule", I set up Samba on a
>> Linux VM to expose an SMB share that the Mac sees as a Time Capsule drive (
>> https://wiki.samba.org/index.php/Configure_Samba_to_Work_Better_with_Mac_OS_X
>> ).
>>
>> I had one problem with Time Machine a few months ago, where it stopped
>> backing up data and insisted on starting the backup 'chain' from scratch
>> again.  I was a little miffed .
>>
>> I'm afraid I can only confirm that the Bacula v9.6 and v11 file daemons
>> worked for me under macOS Catalina and Monetery (I skipped Big Sur.  Not
>> for good reason---just laziness).  Both v9 and v11 clients were compiled
>> from source (setting the linker flags to "-framework CoreFoundation" as
>> already suggested).
>>
>> I've personally not run in to problems with System Integrity Protection,
>> although I do give the bacula-fd executable "Full Disk" permissions.
>>
>> Thanks.
>> --
>> Graham Sparks
>>
>>
>>
>> From: David Brodbeck 
>> Sent: 03 January 2022 18:36
>> Cc: bacula-users@lists.sourceforge.net <
>> bacula-users@lists.sourceforge.net>
>> Subject: Re: [Bacula-users] Packet size too big (NOT a version mismatch)
>>
>> I'm curious if anyone has moved away from Bacula on macOS and what
>> alternatives they're using. Even before this, it was getting more and more
>> awkward to set up -- bacula really doesn't play well with SIP, for example,
>> and running "csrutil disable" on every system is not a security best
>> practice.
>>
>> On Wed, Dec 8, 2021 at 4:46 PM Stephen Thompson <
>> stephen.thomp...@berkeley.edu> wrote:
>>
>>
>> Disappointing...  I am having the same issue on BigSur with the 11.0.5
>> release as I had with 9x.
>>
>> 08-Dec 15:42 SD JobId 878266: Fatal error: bsock.c:530 Packet
>> size=1387166 too big from "client:1.2.3.4:8103". Maximum permitted
>> 100. Terminating connection.
>>
>>
>> Setting 'Maximum Network Buffer Size' does not appear to solve issue.
>> Are there users out there successfully running a bacula client on Big
>> Sur??
>> Stephen
>>
>>
>>
>> On Wed, Dec 1, 2021 at 3:25 PM Stephen Thompson <
>> stephen.thomp...@berkeley.edu> wrote:
>>
>> Not sure if this is correct, but I've been able to at least compile
>> bacula client 11.0.5 on Big Sur by doing before configure step:
>>
>> LDFLAGS='-framework CoreFoundation'
>>
>> We'll see next up whether it runs and whether it exhibits the issue seen
>> under Big Sur for 9x client.
>>
>> Stephen
>>
>> On Tue, Nov 23, 2021 at 7:32 AM Stephen Thompson <
>> stephen.thomp...@berkeley.edu> wrote:
>>
>> Josh,
>>
>> Thanks for the tip.  That did not appear to be the cause of this issue,
>> though perhaps it will fix a yet to be found issue that I would have run
>> into after I get past this compilation error.
>>
>> Stephen
>>
>>
>>
>> On Mon, Nov 22, 2021 at 9:22 AM Josh Fisher  wrote:
>>
>> On 11/22/21 10:46, Steph

Re: [Bacula-users] Packet size too big (NOT a version mismatch)

Graham,

Thanks for presenting Monterey as a possibility!  I am seeing the same
issue under Monterrey as I have under Big Sur, but to know someone else
does not means that it's possible.  I should double check that I am using a
freshly compiled client on Monterey and not just the one that I compiled on
Big Sur.

I am backing up Macs with bacula, but not really for system recovery, more
to backup user files/documents that they may not be backing up themselves.
I do note a number of Mac system files that refuse to be backed up, but
again for my purposes, I do not care too much.  It would be nice to be able
to BMR a Mac, but not a requirement where I am at, being operationally a
Linux shop.

Stephen




On Tue, Jan 4, 2022 at 6:20 AM Graham Sparks  wrote:

> Hi David,
>
> I use Time Machine (for the System disk) as well as Bacula on my Mac, as
> I'd still need the Time Machine backup to do a bare-metal restore (with
> Apps). I use Bacula to back up this and an external data drive.
>
> Rather than purchasing a separate "Time Capsule", I set up Samba on a
> Linux VM to expose an SMB share that the Mac sees as a Time Capsule drive (
> https://wiki.samba.org/index.php/Configure_Samba_to_Work_Better_with_Mac_OS_X
> ).
>
> I had one problem with Time Machine a few months ago, where it stopped
> backing up data and insisted on starting the backup 'chain' from scratch
> again.  I was a little miffed .
>
> I'm afraid I can only confirm that the Bacula v9.6 and v11 file daemons
> worked for me under macOS Catalina and Monetery (I skipped Big Sur.  Not
> for good reason---just laziness).  Both v9 and v11 clients were compiled
> from source (setting the linker flags to "-framework CoreFoundation" as
> already suggested).
>
> I've personally not run in to problems with System Integrity Protection,
> although I do give the bacula-fd executable "Full Disk" permissions.
>
> Thanks.
> --
> Graham Sparks
>
>
>
> From: David Brodbeck 
> Sent: 03 January 2022 18:36
> Cc: bacula-users@lists.sourceforge.net  >
> Subject: Re: [Bacula-users] Packet size too big (NOT a version mismatch)
>
> I'm curious if anyone has moved away from Bacula on macOS and what
> alternatives they're using. Even before this, it was getting more and more
> awkward to set up -- bacula really doesn't play well with SIP, for example,
> and running "csrutil disable" on every system is not a security best
> practice.
>
> On Wed, Dec 8, 2021 at 4:46 PM Stephen Thompson <
> stephen.thomp...@berkeley.edu> wrote:
>
>
> Disappointing...  I am having the same issue on BigSur with the 11.0.5
> release as I had with 9x.
>
> 08-Dec 15:42 SD JobId 878266: Fatal error: bsock.c:530 Packet size=1387166
> too big from "client:1.2.3.4:8103". Maximum permitted 100.
> Terminating connection.
>
>
> Setting 'Maximum Network Buffer Size' does not appear to solve issue.
> Are there users out there successfully running a bacula client on Big Sur??
> Stephen
>
>
>
> On Wed, Dec 1, 2021 at 3:25 PM Stephen Thompson <
> stephen.thomp...@berkeley.edu> wrote:
>
> Not sure if this is correct, but I've been able to at least compile bacula
> client 11.0.5 on Big Sur by doing before configure step:
>
> LDFLAGS='-framework CoreFoundation'
>
> We'll see next up whether it runs and whether it exhibits the issue seen
> under Big Sur for 9x client.
>
> Stephen
>
> On Tue, Nov 23, 2021 at 7:32 AM Stephen Thompson <
> stephen.thomp...@berkeley.edu> wrote:
>
> Josh,
>
> Thanks for the tip.  That did not appear to be the cause of this issue,
> though perhaps it will fix a yet to be found issue that I would have run
> into after I get past this compilation error.
>
> Stephen
>
>
>
> On Mon, Nov 22, 2021 at 9:22 AM Josh Fisher  wrote:
>
> On 11/22/21 10:46, Stephen Thompson wrote:
>
> All,
>
> I too was having the issue with running a 9x client on Big Sur.  I've
> tried compiling 11.0.5 but have not found my way past:
>
> This might be due to a libtool.m4 bug having to do with MacOS changing the
> major Darwin version from 19.x to 20.x. There is a patch at
> https://www.mail-archive.com/libtool-patches@gnu.org/msg07396.html
>
>
> Linking bacula-fd ...
> /Users/bacula/src/bacula-11.0.5-CLIENT.MAC/libtool --silent --tag=CXX
> --mode=link /usr/bin/g++   -L../lib -L../findlib -o bacula-fd filed.o
> authenticate.o backup.o crypto.o win_efs.o estimate.o fdcollect.o
> fd_plugins.o accurate.o bacgpfs.o filed_conf.o runres_conf.o heartbeat.o
> hello.o job.o fd_snapshot.o restore.o status.o verify.o verify_vol.o
> fdcallsdir.o suspend.o org_filed_dedup.o bacl.o bacl_osx.o bxattr.o
> bxattr_osx.o \
> -lz -lb

Re: [Bacula-users] Packet size too big (NOT a version mismatch)

Hi David,

I use Time Machine (for the System disk) as well as Bacula on my Mac, as I'd 
still need the Time Machine backup to do a bare-metal restore (with Apps). I 
use Bacula to back up this and an external data drive.

Rather than purchasing a separate "Time Capsule", I set up Samba on a Linux VM 
to expose an SMB share that the Mac sees as a Time Capsule drive 
(https://wiki.samba.org/index.php/Configure_Samba_to_Work_Better_with_Mac_OS_X).

I had one problem with Time Machine a few months ago, where it stopped backing 
up data and insisted on starting the backup 'chain' from scratch again.  I was 
a little miffed .

I'm afraid I can only confirm that the Bacula v9.6 and v11 file daemons worked 
for me under macOS Catalina and Monetery (I skipped Big Sur.  Not for good 
reason---just laziness).  Both v9 and v11 clients were compiled from source 
(setting the linker flags to "-framework CoreFoundation" as already suggested).

I've personally not run in to problems with System Integrity Protection, 
although I do give the bacula-fd executable "Full Disk" permissions.

Thanks.
-- 
Graham Sparks

From: David Brodbeck 
Sent: 03 January 2022 18:36
Cc: bacula-users@lists.sourceforge.net 
Subject: Re: [Bacula-users] Packet size too big (NOT a version mismatch) 

I'm curious if anyone has moved away from Bacula on macOS and what alternatives 
they're using. Even before this, it was getting more and more awkward to set up 
-- bacula really doesn't play well with SIP, for example, and running "csrutil 
disable" on every system is not a security best practice.

On Wed, Dec 8, 2021 at 4:46 PM Stephen Thompson  
wrote:

Disappointing...  I am having the same issue on BigSur with the 11.0.5 release 
as I had with 9x.

08-Dec 15:42 SD JobId 878266: Fatal error: bsock.c:530 Packet size=1387166 too 
big from "client:1.2.3.4:8103". Maximum permitted 100. Terminating 
connection.

Setting 'Maximum Network Buffer Size' does not appear to solve issue.
Are there users out there successfully running a bacula client on Big Sur??
Stephen

On Wed, Dec 1, 2021 at 3:25 PM Stephen Thompson  
wrote:

Not sure if this is correct, but I've been able to at least compile bacula 
client 11.0.5 on Big Sur by doing before configure step:

LDFLAGS='-framework CoreFoundation'

We'll see next up whether it runs and whether it exhibits the issue seen under 
Big Sur for 9x client.

Stephen

On Tue, Nov 23, 2021 at 7:32 AM Stephen Thompson 
 wrote:

Josh,

Thanks for the tip.  That did not appear to be the cause of this issue, though 
perhaps it will fix a yet to be found issue that I would have run into after I 
get past this compilation error.

Stephen

On Mon, Nov 22, 2021 at 9:22 AM Josh Fisher  wrote:

On 11/22/21 10:46, Stephen Thompson wrote:

All,

I too was having the issue with running a 9x client on Big Sur.  I've tried 
compiling 11.0.5 but have not found my way past:

This might be due to a libtool.m4 bug having to do with MacOS changing the 
major Darwin version from 19.x to 20.x. There is a patch at 
https://www.mail-archive.com/libtool-patches@gnu.org/msg07396.html

Linking bacula-fd ...
/Users/bacula/src/bacula-11.0.5-CLIENT.MAC/libtool --silent --tag=CXX 
--mode=link /usr/bin/g++   -L../lib -L../findlib -o bacula-fd filed.o 
authenticate.o backup.o crypto.o win_efs.o estimate.o fdcollect.o fd_plugins.o 
accurate.o bacgpfs.o filed_conf.o runres_conf.o heartbeat.o hello.o job.o 
fd_snapshot.o restore.o status.o verify.o verify_vol.o fdcallsdir.o suspend.o 
org_filed_dedup.o bacl.o bacl_osx.o bxattr.o bxattr_osx.o \
    -lz -lbacfind -lbaccfg -lbac -lm -lpthread  \
    -L/usr/local/opt/openssl@1.1/lib -lssl -lcrypto    -framework IOKit
Undefined symbols for architecture x86_64:
  "___CFConstantStringClassReference", referenced from:
      CFString in suspend.o
      CFString in suspend.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [bacula-fd] Error 1

Seems like this might have something to do with the expection of headers being 
here:
/System/Library/Frameworks/CoreFoundation.framework/Headers
when they are here:
/Library/Developer/CommandLineTools/SDKs/MacOSX11.0.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/
but that may be a red herring.

There also appears to be a 'clang' in two locations on OS X, /usr and xcode 
subdir.  Hmm

Stephen

On Tue, Nov 16, 2021 at 12:00 AM Eric Bollengier via Bacula-users 
 wrote:
Hello,

On 11/15/21 21:46, David Brodbeck wrote:
> To do that I'd have to upgrade the director and the storage first, right?
> (Director can't be an earlier version than the FD, and the SD must have the
> same version as the director.)

In general yes, the code is designed to support Old FDs but can have problems
with newer FDs. In your case it may work.

At least, you can try a status client to see if the problem i

Re: [Bacula-users] Packet size too big (NOT a version mismatch)

2022-01-03 Thread David Brodbeck

I'm curious if anyone has moved away from Bacula on macOS and what
alternatives they're using. Even before this, it was getting more and more
awkward to set up -- bacula really doesn't play well with SIP, for example,
and running "csrutil disable" on every system is not a security best
practice.

On Wed, Dec 8, 2021 at 4:46 PM Stephen Thompson <
stephen.thomp...@berkeley.edu> wrote:

>
>
> Disappointing...  I am having the same issue on BigSur with the 11.0.5
> release as I had with 9x.
>
> 08-Dec 15:42 SD JobId 878266: Fatal error: bsock.c:530 Packet size=1387166 
> too big from "client:1.2.3.4:8103". Maximum permitted 100. Terminating 
> connection.
>
>
>
> Setting 'Maximum Network Buffer Size' does not appear to solve issue.
>
> Are there users out there successfully running a bacula client on Big Sur??
>
> Stephen
>
>
>
>
> On Wed, Dec 1, 2021 at 3:25 PM Stephen Thompson <
> stephen.thomp...@berkeley.edu> wrote:
>
>>
>> Not sure if this is correct, but I've been able to at least compile
>> bacula client 11.0.5 on Big Sur by doing before configure step:
>>
>> LDFLAGS='-framework CoreFoundation'
>>
>> We'll see next up whether it runs and whether it exhibits the issue seen
>> under Big Sur for 9x client.
>>
>> Stephen
>>
>> On Tue, Nov 23, 2021 at 7:32 AM Stephen Thompson <
>> stephen.thomp...@berkeley.edu> wrote:
>>
>>>
>>> Josh,
>>>
>>> Thanks for the tip.  That did not appear to be the cause of this issue,
>>> though perhaps it will fix a yet to be found issue that I would have run
>>> into after I get past this compilation error.
>>>
>>> Stephen
>>>
>>>
>>>
>>> On Mon, Nov 22, 2021 at 9:22 AM Josh Fisher  wrote:
>>>

 On 11/22/21 10:46, Stephen Thompson wrote:


 All,

 I too was having the issue with running a 9x client on Big Sur.  I've
 tried compiling 11.0.5 but have not found my way past:


 This might be due to a libtool.m4 bug having to do with MacOS changing
 the major Darwin version from 19.x to 20.x. There is a patch at
 https://www.mail-archive.com/libtool-patches@gnu.org/msg07396.html



 Linking bacula-fd ...

 /Users/bacula/src/bacula-11.0.5-CLIENT.MAC/libtool --silent --tag=CXX
 --mode=link /usr/bin/g++   -L../lib -L../findlib -o bacula-fd filed.o
 authenticate.o backup.o crypto.o win_efs.o estimate.o fdcollect.o
 fd_plugins.o accurate.o bacgpfs.o filed_conf.o runres_conf.o heartbeat.o
 hello.o job.o fd_snapshot.o restore.o status.o verify.o verify_vol.o
 fdcallsdir.o suspend.o org_filed_dedup.o bacl.o bacl_osx.o bxattr.o
 bxattr_osx.o \

 -lz -lbacfind -lbaccfg -lbac -lm -lpthread  \

 -L/usr/local/opt/openssl@1.1/lib -lssl -lcrypto-framework IOKit

 Undefined symbols for architecture x86_64:

   "___CFConstantStringClassReference", referenced from:

   CFString in suspend.o

   CFString in suspend.o

 ld: symbol(s) not found for architecture x86_64

 clang: error: linker command failed with exit code 1 (use -v to see
 invocation)

 make[1]: *** [bacula-fd] Error 1



 Seems like this might have something to do with the expection of
 headers being here:

 /System/Library/Frameworks/CoreFoundation.framework/Headers

 when they are here:


 /Library/Developer/CommandLineTools/SDKs/MacOSX11.0.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/
 but that may be a red herring.

 There also appears to be a 'clang' in two locations on OS X, /usr and
 xcode subdir.  Hmm

 Stephen

 On Tue, Nov 16, 2021 at 12:00 AM Eric Bollengier via Bacula-users <
 bacula-users@lists.sourceforge.net> wrote:

> Hello,
>
> On 11/15/21 21:46, David Brodbeck wrote:
> > To do that I'd have to upgrade the director and the storage first,
> right?
> > (Director can't be an earlier version than the FD, and the SD must
> have the
> > same version as the director.)
>
> In general yes, the code is designed to support Old FDs but can have
> problems
> with newer FDs. In your case it may work.
>
> At least, you can try a status client to see if the problem is solved
> and
> if you can run a backup & a restore.
>
> Best Regards,
> Eric
>
>
> ___
> Bacula-users mailing list
> Bacula-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bacula-users
>


 --
 Stephen Thompson   Berkeley Seismology Lab
 stephen.thomp...@berkeley.edu  307 McCone Hall
 Office: 510.664.9177   University of California
 Remote: 510.214.6506 (Tue) Berkeley, CA 94720-4760


 ___
 Bacula-users mailing

Re: [Bacula-users] Packet size too big (NOT a version mismatch)

2021-12-08 Thread Stephen Thompson

Disappointing...  I am having the same issue on BigSur with the 11.0.5
release as I had with 9x.

08-Dec 15:42 SD JobId 878266: Fatal error: bsock.c:530 Packet
size=1387166 too big from "client:1.2.3.4:8103". Maximum permitted
100. Terminating connection.



Setting 'Maximum Network Buffer Size' does not appear to solve issue.

Are there users out there successfully running a bacula client on Big Sur??

Stephen




On Wed, Dec 1, 2021 at 3:25 PM Stephen Thompson <
stephen.thomp...@berkeley.edu> wrote:

>
> Not sure if this is correct, but I've been able to at least compile bacula
> client 11.0.5 on Big Sur by doing before configure step:
>
> LDFLAGS='-framework CoreFoundation'
>
> We'll see next up whether it runs and whether it exhibits the issue seen
> under Big Sur for 9x client.
>
> Stephen
>
> On Tue, Nov 23, 2021 at 7:32 AM Stephen Thompson <
> stephen.thomp...@berkeley.edu> wrote:
>
>>
>> Josh,
>>
>> Thanks for the tip.  That did not appear to be the cause of this issue,
>> though perhaps it will fix a yet to be found issue that I would have run
>> into after I get past this compilation error.
>>
>> Stephen
>>
>>
>>
>> On Mon, Nov 22, 2021 at 9:22 AM Josh Fisher  wrote:
>>
>>>
>>> On 11/22/21 10:46, Stephen Thompson wrote:
>>>
>>>
>>> All,
>>>
>>> I too was having the issue with running a 9x client on Big Sur.  I've
>>> tried compiling 11.0.5 but have not found my way past:
>>>
>>>
>>> This might be due to a libtool.m4 bug having to do with MacOS changing
>>> the major Darwin version from 19.x to 20.x. There is a patch at
>>> https://www.mail-archive.com/libtool-patches@gnu.org/msg07396.html
>>>
>>>
>>>
>>> Linking bacula-fd ...
>>>
>>> /Users/bacula/src/bacula-11.0.5-CLIENT.MAC/libtool --silent --tag=CXX
>>> --mode=link /usr/bin/g++   -L../lib -L../findlib -o bacula-fd filed.o
>>> authenticate.o backup.o crypto.o win_efs.o estimate.o fdcollect.o
>>> fd_plugins.o accurate.o bacgpfs.o filed_conf.o runres_conf.o heartbeat.o
>>> hello.o job.o fd_snapshot.o restore.o status.o verify.o verify_vol.o
>>> fdcallsdir.o suspend.o org_filed_dedup.o bacl.o bacl_osx.o bxattr.o
>>> bxattr_osx.o \
>>>
>>> -lz -lbacfind -lbaccfg -lbac -lm -lpthread  \
>>>
>>> -L/usr/local/opt/openssl@1.1/lib -lssl -lcrypto-framework IOKit
>>>
>>> Undefined symbols for architecture x86_64:
>>>
>>>   "___CFConstantStringClassReference", referenced from:
>>>
>>>   CFString in suspend.o
>>>
>>>   CFString in suspend.o
>>>
>>> ld: symbol(s) not found for architecture x86_64
>>>
>>> clang: error: linker command failed with exit code 1 (use -v to see
>>> invocation)
>>>
>>> make[1]: *** [bacula-fd] Error 1
>>>
>>>
>>>
>>> Seems like this might have something to do with the expection of headers
>>> being here:
>>>
>>> /System/Library/Frameworks/CoreFoundation.framework/Headers
>>>
>>> when they are here:
>>>
>>>
>>> /Library/Developer/CommandLineTools/SDKs/MacOSX11.0.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/
>>> but that may be a red herring.
>>>
>>> There also appears to be a 'clang' in two locations on OS X, /usr and
>>> xcode subdir.  Hmm
>>>
>>> Stephen
>>>
>>> On Tue, Nov 16, 2021 at 12:00 AM Eric Bollengier via Bacula-users <
>>> bacula-users@lists.sourceforge.net> wrote:
>>>
 Hello,

 On 11/15/21 21:46, David Brodbeck wrote:
 > To do that I'd have to upgrade the director and the storage first,
 right?
 > (Director can't be an earlier version than the FD, and the SD must
 have the
 > same version as the director.)

 In general yes, the code is designed to support Old FDs but can have
 problems
 with newer FDs. In your case it may work.

 At least, you can try a status client to see if the problem is solved
 and
 if you can run a backup & a restore.

 Best Regards,
 Eric


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

>>>
>>>
>>> --
>>> Stephen Thompson   Berkeley Seismology Lab
>>> stephen.thomp...@berkeley.edu  307 McCone Hall
>>> Office: 510.664.9177   University of California
>>> Remote: 510.214.6506 (Tue) Berkeley, CA 94720-4760
>>>
>>>
>>> ___
>>> Bacula-users mailing 
>>> listBacula-users@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/bacula-users
>>>
>>>
>>
>> --
>> Stephen Thompson   Berkeley Seismology Lab
>> stephen.thomp...@berkeley.edu  307 McCone Hall
>> Office: 510.664.9177   University of California
>> Remote: 510.214.6506 (Tue) Berkeley, CA 94720-4760
>>
>
>
> --
> Stephen Thompson   Berkeley Seismology Lab
> stephen.thomp...@berkeley.edu  307 McCone Hall
> Office: 510.664.9177   University of California
> Remote: 510.214.6506 (Tue) Berkeley, CA 94720-4760
>


-- 
Stephen Thompson   Berkeley

Re: [Bacula-users] Packet size too big (NOT a version mismatch)

2021-12-01 Thread Stephen Thompson

Not sure if this is correct, but I've been able to at least compile bacula
client 11.0.5 on Big Sur by doing before configure step:

LDFLAGS='-framework CoreFoundation'

We'll see next up whether it runs and whether it exhibits the issue seen
under Big Sur for 9x client.

Stephen

On Tue, Nov 23, 2021 at 7:32 AM Stephen Thompson <
stephen.thomp...@berkeley.edu> wrote:

>
> Josh,
>
> Thanks for the tip.  That did not appear to be the cause of this issue,
> though perhaps it will fix a yet to be found issue that I would have run
> into after I get past this compilation error.
>
> Stephen
>
>
>
> On Mon, Nov 22, 2021 at 9:22 AM Josh Fisher  wrote:
>
>>
>> On 11/22/21 10:46, Stephen Thompson wrote:
>>
>>
>> All,
>>
>> I too was having the issue with running a 9x client on Big Sur.  I've
>> tried compiling 11.0.5 but have not found my way past:
>>
>>
>> This might be due to a libtool.m4 bug having to do with MacOS changing
>> the major Darwin version from 19.x to 20.x. There is a patch at
>> https://www.mail-archive.com/libtool-patches@gnu.org/msg07396.html
>>
>>
>>
>> Linking bacula-fd ...
>>
>> /Users/bacula/src/bacula-11.0.5-CLIENT.MAC/libtool --silent --tag=CXX
>> --mode=link /usr/bin/g++   -L../lib -L../findlib -o bacula-fd filed.o
>> authenticate.o backup.o crypto.o win_efs.o estimate.o fdcollect.o
>> fd_plugins.o accurate.o bacgpfs.o filed_conf.o runres_conf.o heartbeat.o
>> hello.o job.o fd_snapshot.o restore.o status.o verify.o verify_vol.o
>> fdcallsdir.o suspend.o org_filed_dedup.o bacl.o bacl_osx.o bxattr.o
>> bxattr_osx.o \
>>
>> -lz -lbacfind -lbaccfg -lbac -lm -lpthread  \
>>
>> -L/usr/local/opt/openssl@1.1/lib -lssl -lcrypto-framework IOKit
>>
>> Undefined symbols for architecture x86_64:
>>
>>   "___CFConstantStringClassReference", referenced from:
>>
>>   CFString in suspend.o
>>
>>   CFString in suspend.o
>>
>> ld: symbol(s) not found for architecture x86_64
>>
>> clang: error: linker command failed with exit code 1 (use -v to see
>> invocation)
>>
>> make[1]: *** [bacula-fd] Error 1
>>
>>
>>
>> Seems like this might have something to do with the expection of headers
>> being here:
>>
>> /System/Library/Frameworks/CoreFoundation.framework/Headers
>>
>> when they are here:
>>
>>
>> /Library/Developer/CommandLineTools/SDKs/MacOSX11.0.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/
>> but that may be a red herring.
>>
>> There also appears to be a 'clang' in two locations on OS X, /usr and
>> xcode subdir.  Hmm
>>
>> Stephen
>>
>> On Tue, Nov 16, 2021 at 12:00 AM Eric Bollengier via Bacula-users <
>> bacula-users@lists.sourceforge.net> wrote:
>>
>>> Hello,
>>>
>>> On 11/15/21 21:46, David Brodbeck wrote:
>>> > To do that I'd have to upgrade the director and the storage first,
>>> right?
>>> > (Director can't be an earlier version than the FD, and the SD must
>>> have the
>>> > same version as the director.)
>>>
>>> In general yes, the code is designed to support Old FDs but can have
>>> problems
>>> with newer FDs. In your case it may work.
>>>
>>> At least, you can try a status client to see if the problem is solved and
>>> if you can run a backup & a restore.
>>>
>>> Best Regards,
>>> Eric
>>>
>>>
>>> ___
>>> Bacula-users mailing list
>>> Bacula-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bacula-users
>>>
>>
>>
>> --
>> Stephen Thompson   Berkeley Seismology Lab
>> stephen.thomp...@berkeley.edu  307 McCone Hall
>> Office: 510.664.9177   University of California
>> Remote: 510.214.6506 (Tue) Berkeley, CA 94720-4760
>>
>>
>> ___
>> Bacula-users mailing 
>> listBacula-users@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/bacula-users
>>
>>
>
> --
> Stephen Thompson   Berkeley Seismology Lab
> stephen.thomp...@berkeley.edu  307 McCone Hall
> Office: 510.664.9177   University of California
> Remote: 510.214.6506 (Tue) Berkeley, CA 94720-4760
>


-- 
Stephen Thompson   Berkeley Seismology Lab
stephen.thomp...@berkeley.edu  307 McCone Hall
Office: 510.664.9177   University of California
Remote: 510.214.6506 (Tue) Berkeley, CA 94720-4760
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Packet size too big (NOT a version mismatch)

2021-11-23 Thread Stephen Thompson

Josh,

Thanks for the tip.  That did not appear to be the cause of this issue,
though perhaps it will fix a yet to be found issue that I would have run
into after I get past this compilation error.

Stephen



On Mon, Nov 22, 2021 at 9:22 AM Josh Fisher  wrote:

>
> On 11/22/21 10:46, Stephen Thompson wrote:
>
>
> All,
>
> I too was having the issue with running a 9x client on Big Sur.  I've
> tried compiling 11.0.5 but have not found my way past:
>
>
> This might be due to a libtool.m4 bug having to do with MacOS changing the
> major Darwin version from 19.x to 20.x. There is a patch at
> https://www.mail-archive.com/libtool-patches@gnu.org/msg07396.html
>
>
>
> Linking bacula-fd ...
>
> /Users/bacula/src/bacula-11.0.5-CLIENT.MAC/libtool --silent --tag=CXX
> --mode=link /usr/bin/g++   -L../lib -L../findlib -o bacula-fd filed.o
> authenticate.o backup.o crypto.o win_efs.o estimate.o fdcollect.o
> fd_plugins.o accurate.o bacgpfs.o filed_conf.o runres_conf.o heartbeat.o
> hello.o job.o fd_snapshot.o restore.o status.o verify.o verify_vol.o
> fdcallsdir.o suspend.o org_filed_dedup.o bacl.o bacl_osx.o bxattr.o
> bxattr_osx.o \
>
> -lz -lbacfind -lbaccfg -lbac -lm -lpthread  \
>
> -L/usr/local/opt/openssl@1.1/lib -lssl -lcrypto-framework IOKit
>
> Undefined symbols for architecture x86_64:
>
>   "___CFConstantStringClassReference", referenced from:
>
>   CFString in suspend.o
>
>   CFString in suspend.o
>
> ld: symbol(s) not found for architecture x86_64
>
> clang: error: linker command failed with exit code 1 (use -v to see
> invocation)
>
> make[1]: *** [bacula-fd] Error 1
>
>
>
> Seems like this might have something to do with the expection of headers
> being here:
>
> /System/Library/Frameworks/CoreFoundation.framework/Headers
>
> when they are here:
>
>
> /Library/Developer/CommandLineTools/SDKs/MacOSX11.0.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/
> but that may be a red herring.
>
> There also appears to be a 'clang' in two locations on OS X, /usr and
> xcode subdir.  Hmm
>
> Stephen
>
> On Tue, Nov 16, 2021 at 12:00 AM Eric Bollengier via Bacula-users <
> bacula-users@lists.sourceforge.net> wrote:
>
>> Hello,
>>
>> On 11/15/21 21:46, David Brodbeck wrote:
>> > To do that I'd have to upgrade the director and the storage first,
>> right?
>> > (Director can't be an earlier version than the FD, and the SD must have
>> the
>> > same version as the director.)
>>
>> In general yes, the code is designed to support Old FDs but can have
>> problems
>> with newer FDs. In your case it may work.
>>
>> At least, you can try a status client to see if the problem is solved and
>> if you can run a backup & a restore.
>>
>> Best Regards,
>> Eric
>>
>>
>> ___
>> Bacula-users mailing list
>> Bacula-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bacula-users
>>
>
>
> --
> Stephen Thompson   Berkeley Seismology Lab
> stephen.thomp...@berkeley.edu  307 McCone Hall
> Office: 510.664.9177   University of California
> Remote: 510.214.6506 (Tue) Berkeley, CA 94720-4760
>
>
> ___
> Bacula-users mailing 
> listBacula-users@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/bacula-users
>
>

-- 
Stephen Thompson   Berkeley Seismology Lab
stephen.thomp...@berkeley.edu  307 McCone Hall
Office: 510.664.9177   University of California
Remote: 510.214.6506 (Tue) Berkeley, CA 94720-4760
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Packet size too big (NOT a version mismatch)

2021-11-22 Thread Josh Fisher



On 11/22/21 10:46, Stephen Thompson wrote:


All,

I too was having the issue with running a 9x client on Big Sur.  I've 
tried compiling 11.0.5 but have not found my way past:



This might be due to a libtool.m4 bug having to do with MacOS changing 
the major Darwin version from 19.x to 20.x. There is a patch at 
https://www.mail-archive.com/libtool-patches@gnu.org/msg07396.html





Linking bacula-fd ...

/Users/bacula/src/bacula-11.0.5-CLIENT.MAC/libtool --silent --tag=CXX 
--mode=link /usr/bin/g++ -L../lib -L../findlib -o bacula-fd filed.o 
authenticate.o backup.o crypto.o win_efs.o estimate.o fdcollect.o 
fd_plugins.o accurate.o bacgpfs.o filed_conf.o runres_conf.o 
heartbeat.o hello.o job.o fd_snapshot.o restore.o status.o verify.o 
verify_vol.o fdcallsdir.o suspend.o org_filed_dedup.o bacl.o 
bacl_osx.o bxattr.o bxattr_osx.o \


-lz -lbacfind -lbaccfg -lbac -lm -lpthread\

-L/usr/local/opt/openssl@1.1/lib -lssl -lcrypto-framework IOKit

Undefined symbols for architecture x86_64:

"___CFConstantStringClassReference", referenced from:

CFString in suspend.o

CFString in suspend.o

ld: symbol(s) not found for architecture x86_64

clang: error: linker command failed with exit code 1 (use -v to see 
invocation)


make[1]: *** [bacula-fd] Error 1



Seems like this might have something to do with the expection of 
headers being here:


/System/Library/Frameworks/CoreFoundation.framework/Headers

when they are here:

/Library/Developer/CommandLineTools/SDKs/MacOSX11.0.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/

but that may be a red herring.

There also appears to be a 'clang' in two locations on OS X, /usr and 
xcode subdir.  Hmm


Stephen

On Tue, Nov 16, 2021 at 12:00 AM Eric Bollengier via Bacula-users 
 wrote:


Hello,

On 11/15/21 21:46, David Brodbeck wrote:
> To do that I'd have to upgrade the director and the storage
first, right?
> (Director can't be an earlier version than the FD, and the SD
must have the
> same version as the director.)

In general yes, the code is designed to support Old FDs but can
have problems
with newer FDs. In your case it may work.

At least, you can try a status client to see if the problem is
solved and
if you can run a backup & a restore.

Best Regards,
Eric


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



--
Stephen Thompson               Berkeley Seismology Lab
stephen.thomp...@berkeley.edu 307 McCone Hall
Office: 510.664.9177           University of California
Remote: 510.214.6506 (Tue)     Berkeley, CA 94720-4760


___
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] Packet size too big (NOT a version mismatch)

2021-11-22 Thread Stephen Thompson

All,

I too was having the issue with running a 9x client on Big Sur.  I've tried
compiling 11.0.5 but have not found my way past:

Linking bacula-fd ...

/Users/bacula/src/bacula-11.0.5-CLIENT.MAC/libtool --silent --tag=CXX
--mode=link /usr/bin/g++   -L../lib -L../findlib -o bacula-fd filed.o
authenticate.o backup.o crypto.o win_efs.o estimate.o fdcollect.o
fd_plugins.o accurate.o bacgpfs.o filed_conf.o runres_conf.o heartbeat.o
hello.o job.o fd_snapshot.o restore.o status.o verify.o verify_vol.o
fdcallsdir.o suspend.o org_filed_dedup.o bacl.o bacl_osx.o bxattr.o
bxattr_osx.o \

-lz -lbacfind -lbaccfg -lbac -lm -lpthread  \

-L/usr/local/opt/openssl@1.1/lib -lssl -lcrypto-framework IOKit

Undefined symbols for architecture x86_64:

  "___CFConstantStringClassReference", referenced from:

  CFString in suspend.o

  CFString in suspend.o

ld: symbol(s) not found for architecture x86_64

clang: error: linker command failed with exit code 1 (use -v to see
invocation)

make[1]: *** [bacula-fd] Error 1



Seems like this might have something to do with the expection of headers
being here:

/System/Library/Frameworks/CoreFoundation.framework/Headers

when they are here:

/Library/Developer/CommandLineTools/SDKs/MacOSX11.0.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/
but that may be a red herring.

There also appears to be a 'clang' in two locations on OS X, /usr and xcode
subdir.  Hmm

Stephen

On Tue, Nov 16, 2021 at 12:00 AM Eric Bollengier via Bacula-users <
bacula-users@lists.sourceforge.net> wrote:

> Hello,
>
> On 11/15/21 21:46, David Brodbeck wrote:
> > To do that I'd have to upgrade the director and the storage first, right?
> > (Director can't be an earlier version than the FD, and the SD must have
> the
> > same version as the director.)
>
> In general yes, the code is designed to support Old FDs but can have
> problems
> with newer FDs. In your case it may work.
>
> At least, you can try a status client to see if the problem is solved and
> if you can run a backup & a restore.
>
> Best Regards,
> Eric
>
>
> ___
> Bacula-users mailing list
> Bacula-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bacula-users
>


-- 
Stephen Thompson   Berkeley Seismology Lab
stephen.thomp...@berkeley.edu  307 McCone Hall
Office: 510.664.9177   University of California
Remote: 510.214.6506 (Tue) Berkeley, CA 94720-4760
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Packet size too big (NOT a version mismatch)

2021-11-16 Thread Eric Bollengier via Bacula-users


Hello,

On 11/15/21 21:46, David Brodbeck wrote:

To do that I'd have to upgrade the director and the storage first, right?
(Director can't be an earlier version than the FD, and the SD must have the
same version as the director.)


In general yes, the code is designed to support Old FDs but can have problems
with newer FDs. In your case it may work.

At least, you can try a status client to see if the problem is solved and
if you can run a backup & a restore.

Best Regards,
Eric


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

Re: [Bacula-users] Packet size too big (NOT a version mismatch)

2021-11-15 Thread David Brodbeck

To do that I'd have to upgrade the director and the storage first, right?
(Director can't be an earlier version than the FD, and the SD must have the
same version as the director.)

On Mon, Nov 15, 2021 at 12:16 AM Eric Bollengier via Bacula-users <
bacula-users@lists.sourceforge.net> wrote:

> Hello David,
>
> On 11/12/21 23:14, David Brodbeck wrote:
> > I'm getting this error trying to back up a macOS client. I recently
> > re-installed bacula from macports on this client, after an upgrade to
> macOS
> > Big Sur.
> >
> > | russell.math.ucsb.edu-sd JobId 80985: Fatal error: bsock.c:520 Packet
> > size=1387166 too big from "client:128.111.88.29:62571". Maximum
> permitted
> > 100. Terminating connection. |
> >
> > Normally when I've seen this it's because of a version mismatch between
> the
> > client and the director or storage daemon, but that's not the case here;
> > the director, sd, and fd are all running the same version:
> >
> > 1000 OK: 103 self-help.math.ucsb.edu-dir Version: 9.4.4 (28 May 2019)
> > russell.math.ucsb.edu-sd Version: 9.4.4 (28 May 2019) x86_64-pc-linux-gnu
> > redhat (Core)
> > noether.math.ucsb.edu-fd Version: 9.4.4 (28 May 2019)
> >   x86_64-apple-darwin20.6.0 osx 20.6.0
>
> I would recommend to retry with a more recent version of the FD, I remember
> to have seen something similar to that in the past.
>
> Best Regards,
> Eric
>
>
> ___
> Bacula-users mailing list
> Bacula-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bacula-users
>


-- 
David Brodbeck (they/them)
System Administrator, Department of Mathematics
University of California, Santa Barbara
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Packet size too big (NOT a version mismatch)

2021-11-15 Thread Eric Bollengier via Bacula-users


Hello David,

On 11/12/21 23:14, David Brodbeck wrote:

I'm getting this error trying to back up a macOS client. I recently
re-installed bacula from macports on this client, after an upgrade to macOS
Big Sur.

| russell.math.ucsb.edu-sd JobId 80985: Fatal error: bsock.c:520 Packet
size=1387166 too big from "client:128.111.88.29:62571". Maximum permitted
100. Terminating connection. |

Normally when I've seen this it's because of a version mismatch between the
client and the director or storage daemon, but that's not the case here;
the director, sd, and fd are all running the same version:

1000 OK: 103 self-help.math.ucsb.edu-dir Version: 9.4.4 (28 May 2019)
russell.math.ucsb.edu-sd Version: 9.4.4 (28 May 2019) x86_64-pc-linux-gnu
redhat (Core)
noether.math.ucsb.edu-fd Version: 9.4.4 (28 May 2019)
  x86_64-apple-darwin20.6.0 osx 20.6.0


I would recommend to retry with a more recent version of the FD, I remember
to have seen something similar to that in the past.

Best Regards,
Eric


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

Re: [Bacula-users] Packet size too big (NOT a version mismatch)

2021-11-12 Thread David Brodbeck

On Fri, Nov 12, 2021 at 3:16 PM Heitor Faria  wrote:

> Hello They,
>
> Are all the NICs using the same MTU?
>
Yes, all have an MTU of 1500.

> Have you checked for network layer problems?
>
None of the machines involved show any network errors. The network in
between is out of my hands, but it's fully switched and no other clients
are having problems, so I have no reason to suspect issues. File transfers
to/from the affected client seem to work fine.

> I have no clue regarding your error, but I would try to limit the packet
> size with the following FD directive:
>
> Maximum Network Buffer Size = 
>
This had no effect. The default is 65,536, less than the limit of 100,
so I guess that makes sense.

-- 
David Brodbeck (they/them)
System Administrator, Department of Mathematics
University of California, Santa Barbara
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Packet size too big (NOT a version mismatch)

2021-11-12 Thread Stephen Thompson




David,

Sorry I can't offer a solution, but I can report that am I getting the 
same error when trying to run bacula-fd 9.x on Big Sur (hand compiled).


I've tried the other suggestion of Maximum Network Buffer Size to no avail.

Stephen



On 11/12/21 2:14 PM, David Brodbeck wrote:
I'm getting this error trying to back up a macOS client. I recently 
re-installed bacula from macports on this client, after an upgrade to 
macOS Big Sur.


| russell.math.ucsb.edu-sd JobId 80985: Fatal error: bsock.c:520 Packet 
size=1387166 too big from "client:128.111.88.29:62571 
". Maximum permitted 100. Terminating 
connection. |


Normally when I've seen this it's because of a version mismatch between 
the client and the director or storage daemon, but that's not the case 
here; the director, sd, and fd are all running the same version:


1000 OK: 103 self-help.math.ucsb.edu-dir Version: 9.4.4 (28 May 2019)
russell.math.ucsb.edu-sd Version: 9.4.4 (28 May 2019) 
x86_64-pc-linux-gnu redhat (Core)
noether.math.ucsb.edu-fd Version: 9.4.4 (28 May 2019) 
  x86_64-apple-darwin20.6.0 osx 20.6.0


All except the fd are built directly from bacula source. (The fd was 
built with macports.)


Any suggestions on where to look? Other clients are backing up fine to 
the same sd, so I feel like it must be a client configuration issue, but 
I can't figure out how.


--
David Brodbeck (they/them)
System Administrator, Department of Mathematics
University of California, Santa Barbara



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



--
Stephen Thompson   Berkeley Seismology Lab
stephen.thomp...@berkeley.edu  307 McCone Hall
Office: 510.664.9177   University of California
Remote: 510.214.6506 (Tue) Berkeley, CA 94720-4760


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

Re: [Bacula-users] Packet size too big (NOT a version mismatch)

2021-11-12 Thread Heitor Faria

Hello They,

Are all the NICs using the same MTU?
Have you checked for network layer problems?
I have no clue regarding your error, but I would try to limit the packet size 
with the following FD directive:

Maximum Network Buffer Size = 

Rgds.
--
MSc Heitor Faria (Miami/USA)
CEO Bacula LatAm
mobile1: + 1 909 655-8971
mobile2: + 55 61 98268-4220

América Latina
[ http://bacula.lat/]___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

[Bacula-users] Packet size too big (NOT a version mismatch)

2021-11-12 Thread David Brodbeck

I'm getting this error trying to back up a macOS client. I recently
re-installed bacula from macports on this client, after an upgrade to macOS
Big Sur.

| russell.math.ucsb.edu-sd JobId 80985: Fatal error: bsock.c:520 Packet
size=1387166 too big from "client:128.111.88.29:62571". Maximum permitted
100. Terminating connection. |

Normally when I've seen this it's because of a version mismatch between the
client and the director or storage daemon, but that's not the case here;
the director, sd, and fd are all running the same version:

1000 OK: 103 self-help.math.ucsb.edu-dir Version: 9.4.4 (28 May 2019)
russell.math.ucsb.edu-sd Version: 9.4.4 (28 May 2019) x86_64-pc-linux-gnu
redhat (Core)
noether.math.ucsb.edu-fd Version: 9.4.4 (28 May 2019)
 x86_64-apple-darwin20.6.0 osx 20.6.0

All except the fd are built directly from bacula source. (The fd was built
with macports.)

Any suggestions on where to look? Other clients are backing up fine to the
same sd, so I feel like it must be a client configuration issue, but I
can't figure out how.

-- 
David Brodbeck (they/them)
System Administrator, Department of Mathematics
University of California, Santa Barbara
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Packet Size too big from client

2018-05-02 Thread Bill Arlofski

On 05/01/2018 04:58 PM, Alan Li wrote:
> Hello Bacula Users:
> 
> We have a Bacula backup server on a Debian 9 machine with both bacula-director
> and bacula-fd version 7.4.4. It backs up other Debian hosts that have
> bacula-fd version 7.4.4 just fine. Today we bring up another Debian host that
> runs bacula-fd version 9.0.7 and when we try to back this new machine up, we
> get the error:
> 
> Fatal error: bsock.c:569 Packet size=1073741936 too big from "Client:
> viaduct-fd:10.155.60.19:9102. Terminating connection.
> 
> This happens to any number of files we try to backup. The only difference we
> can see on this new host from the others is the newer version of bacula-fd.
> 
> Is the error due to version incompatibility?
> 
> Thanks,
> 
> Alan


Hello Alan,

Yes, the problem is due to versions.

The rule with Bacula daemon versions is: (DIR = SD) => FD

You will need to downgrade your FD to 7.4.4 (or lower), or upgrade your DIR
and SD to 9.0.7

Best regards,

Bill


-- 
Bill Arlofski
http://www.revpol.com/bacula
-- Not responsible for anything below this line --

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

[Bacula-users] Packet Size too big from client

2018-05-02 Thread Alan Li


Hello Bacula Users:

We have a Bacula backup server on a Debian 9 machine with both 
bacula-director and bacula-fd version 7.4.4. It backs up other Debian 
hosts that have bacula-fd version 7.4.4 just fine. Today we bring up 
another Debian host that runs bacula-fd version 9.0.7 and when we try to 
back this new machine up, we get the error:


Fatal error: bsock.c:569 Packet size=1073741936 too big from "Client: 
viaduct-fd:10.155.60.19:9102. Terminating connection.


This happens to any number of files we try to backup. The only 
difference we can see on this new host from the others is the newer 
version of bacula-fd.


Is the error due to version incompatibility?

Thanks,

Alan


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Packet size too big errors

2018-04-01 Thread Kern Sibbald

Hmm.  The fact that the error message is reported with JobId 113 is 
actually a bug in new code that I implemented in version 9.0.x.  I 
didn't notice it in my first response, so must admit that yes it is 
confusing.  The reason for this problem is that error messages are 
reported by any currently running job because a communications illegal 
probe as you experienced has no job associated with it and thus has no 
connection from the daemon to a running job that can log error 
messages.  This was an attempt to fix the problem of the message being 
discarded but in fact it lead to a misleading error message.

The fix to the problem is a bit invasive and much more important than I 
had originally planned so it will come in a future release, where all 
error messages will be properly reported and each daemon will have its 
own separate log so that daemon messages (those generated with no 
running job such as connections) can be logged in the appropriate daemon 
log (a new concept to Bacula).

Actually, I would appreciate it if you would submit a but report on this 
indicating that a network connection failure is reported under an 
incorrect jobid.  This will ensure that the problem really is corrected 
and then properly reported.

Best regards,

Kern

On 03/05/2018 11:19 PM, Shawn Rappaport wrote:

On 3/5/18, 2:37 PM, "Josip Deanovic"  wrote:

 Josip DeanovicOn Monday 2018-03-05 22:23:08  wrote:
 > On Monday 2018-03-05 14:38:07 Dimitri Maziuk wrote:
 > > On 03/05/2018 02:27 PM, Josip Deanovic wrote:
 > > > On Monday 2018-03-05 14:16:34 Dimitri Maziuk wrote:
 > > >> That's not an error if a security op's workstation is also a backup
 > > >> client.
 > > >
> > > > Yes, and I would like to know if that was the case.
> > >
> > > I tend to have a blanket iptables rule allowing local subnet traffic.
> > > Our security nazis live in a separate subnet so their scans get
> > > blocked
> > > by that. If I were running portscans from inside my netblock I expect
> > > I'd get the same log entries. That's anther other option for it being
> > > legit.
> >
> > I have additional backup interfaces and completely separated backup
> > network where no other two backup clients can see or reach each other.
> >
> > Where there is no additional network card available there is a VLAN.
> >
> > But all of that is not important here.
> > What is important is the case where if you can reach bacula services
> > you could potentially break backup jobs and thus effectively produce
> > a bacula denial of service.
> >
> > If I understood correctly that's what happened to Shawn.
>
> Actually Shawn didn't say that the backup failed.
> He just said that when he manually started the backup job the next day,
> it finished successfully, without errors.
>
   >  Shawn, can you confirm that both backups were successfully completed?
   >

Despite seeing those errors in the log, the catalog backup appears to have been 
successful. So, yes, both the scheduled and manual backup of my catalog 
completed successfully.  Here is what the full log looks like from March 3rd:

xbacdirector01-lv.internal.shutterfly.com-dir JobId 113: shell command: run BeforeJob 
"/etc/bacula/make_catalog_backup.pl MyCatalog"
xbacdirector01-lv.internal.shutterfly.com-dir JobId 113: Start Backup JobId 
113, Job=BackupCatalog.2018-03-03_23.10.00_10
xbacdirector01-lv.internal.shutterfly.com-dir JobId 113: Error: getmsg.c:209 Malformed 
message: bsock.c:819 Packet size=121984032 too big from 
"client:10.32.12.18:9103". Maximum permitted 100. Terminating connection.
xbacdirector01-lv.internal.shutterfly.com-dir JobId 113: Error: getmsg.c:209 Malformed 
message: bsock.c:819 Packet size=138759248 too big from 
"client:10.32.12.18:9103". Maximum permitted 100. Terminating connection.
xbacdirector01-lv.internal.shutterfly.com-dir JobId 113: Error: getmsg.c:209 Malformed 
message: bsock.c:819 Packet size=50331667 too big from 
"client:10.32.12.18:9103". Maximum permitted 100. Terminating connection.
xbacdirector01-lv.internal.shutterfly.com-dir JobId 113: Using Device 
"FileChgr1-Dev2" to write.
xbacdirector01-lv.internal.shutterfly.com-dir JobId 113: Error: getmsg.c:209 Malformed 
message: bsock.c:819 Packet size=121984032 too big from 
"client:10.32.12.18:9102". Maximum permitted 100. Terminating connection.
xbacdirector01-lv.internal.shutterfly.com-dir JobId 113: Error: getmsg.c:209 Malformed 
message: bsock.c:819 Packet size=138759248 too big from 
"client:10.32.12.18:9102". Maximum permitted 100. Terminating connection.
xbacdirector01-lv.internal.shutterfly.com-dir JobId 113: Error: getmsg.c:209 Malformed 
message: bsock.c:819 Packet size=50331667 too big from 
"client:10.32.12.18:9102". Maximum permitted 100. Terminating connection.
xbacdirector01-lv.internal.shutterfly.com-sd JobId 113: Volume

Re: [Bacula-users] Packet size too big errors

2018-04-01 Thread Kern Sibbald


Hello,

The error in question is simply because some program other than one 
furnished by Bacula or using the Bacula protocol has tried to connect to 
Bacula.  Bacula reports that and in my view what is reports is very 
clear (at least for a technical person).


To alleviate your concerns, I cannot imagine that such probes other than 
producing an error message (good practice) could in any way cause 
another Job to fail.  Each job is totally separate, and just because 
there is an invalid probe will not affect the jobs that connect correctly.


Best regards,

Kern


On 03/05/2018 10:23 PM, Josip Deanovic wrote:

On Monday 2018-03-05 14:38:07 Dimitri Maziuk wrote:

On 03/05/2018 02:27 PM, Josip Deanovic wrote:

On Monday 2018-03-05 14:16:34 Dimitri Maziuk wrote:

That's not an error if a security op's workstation is also a backup
client.

Yes, and I would like to know if that was the case.

I tend to have a blanket iptables rule allowing local subnet traffic.
Our security nazis live in a separate subnet so their scans get blocked
by that. If I were running portscans from inside my netblock I expect
I'd get the same log entries. That's anther other option for it being
legit.

I have additional backup interfaces and completely separated backup
network where no other two backup clients can see or reach each other.

Where there is no additional network card available there is a VLAN.

But all of that is not important here.
What is important is the case where if you can reach bacula services
you could potentially break backup jobs and thus effectively produce
a bacula denial of service.

If I understood correctly that's what happened to Shawn.




--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Packet size too big errors

2018-03-06 Thread Martin Simmons

> On Mon, 5 Mar 2018 22:19:14 +, Shawn Rappaport said:
> Content-ID: 
> 
> On 3/5/18, 2:37 PM, "Josip Deanovic"  wrote:
> 
> Josip DeanovicOn Monday 2018-03-05 22:23:08  wrote:
> > On Monday 2018-03-05 14:38:07 Dimitri Maziuk wrote:
> > > On 03/05/2018 02:27 PM, Josip Deanovic wrote:
> > > > On Monday 2018-03-05 14:16:34 Dimitri Maziuk wrote:
> > > >> That's not an error if a security op's workstation is also a backup
> > > >> client.
> > > > 
>> > > > Yes, and I would like to know if that was the case.
>> > > 
>> > > I tend to have a blanket iptables rule allowing local subnet traffic.
>> > > Our security nazis live in a separate subnet so their scans get
>> > > blocked
>> > > by that. If I were running portscans from inside my netblock I expect
>> > > I'd get the same log entries. That's anther other option for it being
>> > > legit.
>> > 
>> > I have additional backup interfaces and completely separated backup
>> > network where no other two backup clients can see or reach each other.
>> > 
>> > Where there is no additional network card available there is a VLAN.
>> > 
>> > But all of that is not important here.
>> > What is important is the case where if you can reach bacula services
>> > you could potentially break backup jobs and thus effectively produce
>> > a bacula denial of service.
>> > 
>> > If I understood correctly that's what happened to Shawn.
>> 
>> Actually Shawn didn't say that the backup failed.
>> He just said that when he manually started the backup job the next day,
>> it finished successfully, without errors.
>> 
>   >  Shawn, can you confirm that both backups were successfully completed?
>   >  
> 
> Despite seeing those errors in the log, the catalog backup appears to have 
> been successful. So, yes, both the scheduled and manual backup of my catalog 
> completed successfully.  Here is what the full log looks like from March 3rd:
> 
> xbacdirector01-lv.internal.shutterfly.com-dir JobId 113: shell command: run 
> BeforeJob "/etc/bacula/make_catalog_backup.pl MyCatalog"
> xbacdirector01-lv.internal.shutterfly.com-dir JobId 113: Start Backup JobId 
> 113, Job=BackupCatalog.2018-03-03_23.10.00_10
> xbacdirector01-lv.internal.shutterfly.com-dir JobId 113: Error: getmsg.c:209 
> Malformed message: bsock.c:819 Packet size=121984032 too big from 
> "client:10.32.12.18:9103". Maximum permitted 100. Terminating connection.
> xbacdirector01-lv.internal.shutterfly.com-dir JobId 113: Error: getmsg.c:209 
> Malformed message: bsock.c:819 Packet size=138759248 too big from 
> "client:10.32.12.18:9103". Maximum permitted 100. Terminating connection.
> xbacdirector01-lv.internal.shutterfly.com-dir JobId 113: Error: getmsg.c:209 
> Malformed message: bsock.c:819 Packet size=50331667 too big from 
> "client:10.32.12.18:9103". Maximum permitted 100. Terminating connection.
> xbacdirector01-lv.internal.shutterfly.com-dir JobId 113: Using Device 
> "FileChgr1-Dev2" to write.
> xbacdirector01-lv.internal.shutterfly.com-dir JobId 113: Error: getmsg.c:209 
> Malformed message: bsock.c:819 Packet size=121984032 too big from 
> "client:10.32.12.18:9102". Maximum permitted 100. Terminating connection.
> xbacdirector01-lv.internal.shutterfly.com-dir JobId 113: Error: getmsg.c:209 
> Malformed message: bsock.c:819 Packet size=138759248 too big from 
> "client:10.32.12.18:9102". Maximum permitted 100. Terminating connection.
> xbacdirector01-lv.internal.shutterfly.com-dir JobId 113: Error: getmsg.c:209 
> Malformed message: bsock.c:819 Packet size=50331667 too big from 
> "client:10.32.12.18:9102". Maximum permitted 100. Terminating connection.
> xbacdirector01-lv.internal.shutterfly.com-sd JobId 113: Volume "daily-0" 
> previously written, moving to end of data.
> xbacdirector01-lv.internal.shutterfly.com-sd JobId 113: Elapsed 
> time=00:00:02, Transfer rate=11.07 M Bytes/second
> xbacdirector01-lv.internal.shutterfly.com-sd JobId 113: Sending spooled attrs 
> to the Director. Despooling 225 bytes ...
> xbacdirector01-lv.internal.shutterfly.com-dir JobId 113: Bacula 
> xbacdirector01-lv.internal.shutterfly.com-dir 9.0.6 (20Nov17):
>   Build OS:   x86_64-pc-linux-gnu redhat (Core)
>   JobId:  113
>   Job:BackupCatalog.2018-03-03_23.10.00_10
>   Backup Level:   Full
>   Client: "xbacdirector01-lv.internal.shutterfly.com-fd" 
> 9.0.6 (20Nov17) x86_64-pc-linux-gnu,redhat,(Core)
>   FileSet:"Catalog" 2018-02-08 23:10:00
>   Pool:   "Daily" (From Job resource)
>   Catalog:"MyCatalog" (From Client resource)
>   Storage:"File1" (From Pool resource)
>   Scheduled time: 03-Mar-2018 23:10:00
>   Start time: 03-Mar-2018

Re: [Bacula-users] Packet size too big errors

On Monday 2018-03-05 22:19:14 Shawn Rappaport wrote:
> On 3/5/18, 2:37 PM, "Josip Deanovic"  wrote:
> > Actually Shawn didn't say that the backup failed.
> > He just said that when he manually started the backup job the next
> > day, it finished successfully, without errors.
> > 
> >  Shawn, can you confirm that both backups were successfully
> > completed?
> 
> Despite seeing those errors in the log, the catalog backup appears to
> have been successful. So, yes, both the scheduled and manual backup of
> my catalog completed successfully.  Here is what the full log looks
> like from March 3rd:


In that case everything is in order.

Thank you.

-- 
Josip Deanovic

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Packet size too big errors

On 3/5/18, 2:37 PM, "Josip Deanovic"  wrote:

Josip DeanovicOn Monday 2018-03-05 22:23:08  wrote:
> On Monday 2018-03-05 14:38:07 Dimitri Maziuk wrote:
> > On 03/05/2018 02:27 PM, Josip Deanovic wrote:
> > > On Monday 2018-03-05 14:16:34 Dimitri Maziuk wrote:
> > >> That's not an error if a security op's workstation is also a backup
> > >> client.
> > > 
   > > > > Yes, and I would like to know if that was the case.
   > > > 
   > > > I tend to have a blanket iptables rule allowing local subnet traffic.
   > > > Our security nazis live in a separate subnet so their scans get
   > > > blocked
   > > > by that. If I were running portscans from inside my netblock I expect
   > > > I'd get the same log entries. That's anther other option for it being
   > > > legit.
   > > 
   > > I have additional backup interfaces and completely separated backup
   > > network where no other two backup clients can see or reach each other.
   > > 
   > > Where there is no additional network card available there is a VLAN.
   > > 
   > > But all of that is not important here.
   > > What is important is the case where if you can reach bacula services
   > > you could potentially break backup jobs and thus effectively produce
   > > a bacula denial of service.
   > > 
   > > If I understood correctly that's what happened to Shawn.
   > 
   > Actually Shawn didn't say that the backup failed.
   > He just said that when he manually started the backup job the next day,
   > it finished successfully, without errors.
   > 
  >  Shawn, can you confirm that both backups were successfully completed?
  >  

Despite seeing those errors in the log, the catalog backup appears to have been 
successful. So, yes, both the scheduled and manual backup of my catalog 
completed successfully.  Here is what the full log looks like from March 3rd:

xbacdirector01-lv.internal.shutterfly.com-dir JobId 113: shell command: run 
BeforeJob "/etc/bacula/make_catalog_backup.pl MyCatalog"
xbacdirector01-lv.internal.shutterfly.com-dir JobId 113: Start Backup JobId 
113, Job=BackupCatalog.2018-03-03_23.10.00_10
xbacdirector01-lv.internal.shutterfly.com-dir JobId 113: Error: getmsg.c:209 
Malformed message: bsock.c:819 Packet size=121984032 too big from 
"client:10.32.12.18:9103". Maximum permitted 100. Terminating connection.
xbacdirector01-lv.internal.shutterfly.com-dir JobId 113: Error: getmsg.c:209 
Malformed message: bsock.c:819 Packet size=138759248 too big from 
"client:10.32.12.18:9103". Maximum permitted 100. Terminating connection.
xbacdirector01-lv.internal.shutterfly.com-dir JobId 113: Error: getmsg.c:209 
Malformed message: bsock.c:819 Packet size=50331667 too big from 
"client:10.32.12.18:9103". Maximum permitted 100. Terminating connection.
xbacdirector01-lv.internal.shutterfly.com-dir JobId 113: Using Device 
"FileChgr1-Dev2" to write.
xbacdirector01-lv.internal.shutterfly.com-dir JobId 113: Error: getmsg.c:209 
Malformed message: bsock.c:819 Packet size=121984032 too big from 
"client:10.32.12.18:9102". Maximum permitted 100. Terminating connection.
xbacdirector01-lv.internal.shutterfly.com-dir JobId 113: Error: getmsg.c:209 
Malformed message: bsock.c:819 Packet size=138759248 too big from 
"client:10.32.12.18:9102". Maximum permitted 100. Terminating connection.
xbacdirector01-lv.internal.shutterfly.com-dir JobId 113: Error: getmsg.c:209 
Malformed message: bsock.c:819 Packet size=50331667 too big from 
"client:10.32.12.18:9102". Maximum permitted 100. Terminating connection.
xbacdirector01-lv.internal.shutterfly.com-sd JobId 113: Volume "daily-0" 
previously written, moving to end of data.
xbacdirector01-lv.internal.shutterfly.com-sd JobId 113: Elapsed time=00:00:02, 
Transfer rate=11.07 M Bytes/second
xbacdirector01-lv.internal.shutterfly.com-sd JobId 113: Sending spooled attrs 
to the Director. Despooling 225 bytes ...
xbacdirector01-lv.internal.shutterfly.com-dir JobId 113: Bacula 
xbacdirector01-lv.internal.shutterfly.com-dir 9.0.6 (20Nov17):
  Build OS:   x86_64-pc-linux-gnu redhat (Core)
  JobId:  113
  Job:BackupCatalog.2018-03-03_23.10.00_10
  Backup Level:   Full
  Client: "xbacdirector01-lv.internal.shutterfly.com-fd" 9.0.6 
(20Nov17) x86_64-pc-linux-gnu,redhat,(Core)
  FileSet:"Catalog" 2018-02-08 23:10:00
  Pool:   "Daily" (From Job resource)
  Catalog:"MyCatalog" (From Client resource)
  Storage:"File1" (From Pool resource)
  Scheduled time: 03-Mar-2018 23:10:00
  Start time: 03-Mar-2018 23:10:03
  End time:   03-Mar-2018 23:10:05
  Elapsed time:   2 secs
  Priority:   11
  FD Files Written:   1
  SD Files Written:   1
  FD Bytes Written:   22,147,958 (22.14 MB)
  SD Bytes Written:   22,148,071 (22.14 MB)
  Rate:   11074.0 KB/s

Re: [Bacula-users] Packet size too big errors

On 03/05/2018 03:35 PM, Josip Deanovic wrote:

> Shawn, can you confirm that both backups were successfully completed?

Yes, if an unsuccessful connection attempt kills a running backup, that
would be unpleasant. The log doesn't look like it, though, it seems to
log a "jobid 0" for just the connection attempt: hopefully a misleading
message is all it is.

-- 
Dimitri Maziuk
Programmer/sysadmin
BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu



signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Packet size too big errors

Josip DeanovicOn Monday 2018-03-05 22:23:08  wrote:
> On Monday 2018-03-05 14:38:07 Dimitri Maziuk wrote:
> > On 03/05/2018 02:27 PM, Josip Deanovic wrote:
> > > On Monday 2018-03-05 14:16:34 Dimitri Maziuk wrote:
> > >> That's not an error if a security op's workstation is also a backup
> > >> client.
> > > 
> > > Yes, and I would like to know if that was the case.
> > 
> > I tend to have a blanket iptables rule allowing local subnet traffic.
> > Our security nazis live in a separate subnet so their scans get
> > blocked
> > by that. If I were running portscans from inside my netblock I expect
> > I'd get the same log entries. That's anther other option for it being
> > legit.
> 
> I have additional backup interfaces and completely separated backup
> network where no other two backup clients can see or reach each other.
> 
> Where there is no additional network card available there is a VLAN.
> 
> But all of that is not important here.
> What is important is the case where if you can reach bacula services
> you could potentially break backup jobs and thus effectively produce
> a bacula denial of service.
> 
> If I understood correctly that's what happened to Shawn.

Actually Shawn didn't say that the backup failed.
He just said that when he manually started the backup job the next day,
it finished successfully, without errors.

Shawn, can you confirm that both backups were successfully completed?

Thank you in advance.

-- 
Josip Deanovic

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Packet size too big errors

On Monday 2018-03-05 14:38:07 Dimitri Maziuk wrote:
> On 03/05/2018 02:27 PM, Josip Deanovic wrote:
> > On Monday 2018-03-05 14:16:34 Dimitri Maziuk wrote:
> >> That's not an error if a security op's workstation is also a backup
> >> client.
> > 
> > Yes, and I would like to know if that was the case.
> 
> I tend to have a blanket iptables rule allowing local subnet traffic.
> Our security nazis live in a separate subnet so their scans get blocked
> by that. If I were running portscans from inside my netblock I expect
> I'd get the same log entries. That's anther other option for it being
> legit.

I have additional backup interfaces and completely separated backup
network where no other two backup clients can see or reach each other.

Where there is no additional network card available there is a VLAN.

But all of that is not important here.
What is important is the case where if you can reach bacula services
you could potentially break backup jobs and thus effectively produce
a bacula denial of service.

If I understood correctly that's what happened to Shawn.

-- 
Josip Deanovic

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Packet size too big errors

On Monday 2018-03-05 19:41:45 Shawn Rappaport wrote:
> No, 10.32.12.18 is not the IP of the client to be backed up. I’m
> guessing that was the IP of the Nessus scanner.

In that case everything is ok except I don't understand why the
backup failed because some other server tried to open a connection
to the bacula service during the backup.

I don't think that should happen.

-- 
Josip Deanovic

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Packet size too big errors

On 03/05/2018 02:27 PM, Josip Deanovic wrote:
> On Monday 2018-03-05 14:16:34 Dimitri Maziuk wrote:

>> That's not an error if a security op's workstation is also a backup
>> client.
> 
> Yes, and I would like to know if that was the case.

I tend to have a blanket iptables rule allowing local subnet traffic.
Our security nazis live in a separate subnet so their scans get blocked
by that. If I were running portscans from inside my netblock I expect
I'd get the same log entries. That's anther other option for it being legit.

-- 
Dimitri Maziuk
Programmer/sysadmin
BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu

signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Packet size too big errors

On Monday 2018-03-05 14:16:34 Dimitri Maziuk wrote:
> On 03/05/2018 12:45 PM, Josip Deanovic wrote:
> > The question is: is the IP 10.32.12.18 the IP of the client that had
> > to be backed up?
> >
> > 
> >
> > If yes then the vulnerability scan overtook the client's IP.
> 
> That's not an error if a security op's workstation is also a backup
> client.

Yes, and I would like to know if that was the case.

-- 
Josip Deanovic

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Packet size too big errors

On 03/05/2018 12:45 PM, Josip Deanovic wrote:

> The question is: is the IP 10.32.12.18 the IP of the client that had
> to be backed up?
> 
> If yes then the vulnerability scan overtook the client's IP.

That's not an error if a security op's workstation is also a backup client.

-- 
Dimitri Maziuk
Programmer/sysadmin
BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu



signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Packet size too big errors

No, 10.32.12.18 is not the IP of the client to be backed up. I’m guessing that 
was the IP of the Nessus scanner.

--Shawn

On 3/5/18, 11:48 AM, "Josip Deanovic"  wrote:

On Monday 2018-03-05 12:32:50 Dimitri Maziuk wrote:
> On 03/05/2018 12:00 PM, Josip Deanovic wrote:
> > On Monday 2018-03-05 17:08:45 Shawn Rappaport wrote:
> >> Thank you, Patti! You were correct. It turns out there was a
> >> vulnerability scan run against that network at that time.
> > 
> > Did you configure your bacula to use SSL/TLS connection?
> > I wonder if that would help in your case.
> 
> I'd expect to still see "invalid HELO" logged. Firewalling the port
> would work if the scanner and bacula clients live in different subnets.

But the log says: UA Hello from client:10.32.12.18:9101
The same IP was mentioned several times in the logs Shawn provided.

The question is: is the IP 10.32.12.18 the IP of the client that had
to be backed up?

If yes then the vulnerability scan overtook the client's IP.

-- 
Josip Deanovic


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! 
https://urldefense.proofpoint.com/v2/url?u=http-3A__sdm.link_slashdot=DwICAg=sy2pFYeXOTBQJUPqadkFIXq5lzPIgQxhI8DCCAdSjYc=N3_BTL1Tt2ryeleRqn2wc-R4w3v0TnI7dlgnwdQ7zE8=wPBX6OgHHj7MV7gxOQnY5082cQ6UQimXGy_zUId9AEk=t6x_0Qp-42lkZWidsQ1GprGuNjHMqy03eQf7EY3q4QY=
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net

https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_bacula-2Dusers=DwICAg=sy2pFYeXOTBQJUPqadkFIXq5lzPIgQxhI8DCCAdSjYc=N3_BTL1Tt2ryeleRqn2wc-R4w3v0TnI7dlgnwdQ7zE8=wPBX6OgHHj7MV7gxOQnY5082cQ6UQimXGy_zUId9AEk=KpPQj-PVt6jtDqYpxWXzkYFL5GRAB4MrFcPCHfMqdTI=


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Packet size too big errors

No, I don’t have that configured on my Bacula server.

--Shawn

On 3/5/18, 11:02 AM, "Josip Deanovic"  wrote:

On Monday 2018-03-05 17:08:45 Shawn Rappaport wrote:
> Thank you, Patti! You were correct. It turns out there was a
> vulnerability scan run against that network at that time.

Did you configure your bacula to use SSL/TLS connection?
I wonder if that would help in your case.

-- 
Josip Deanovic


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! 
https://urldefense.proofpoint.com/v2/url?u=http-3A__sdm.link_slashdot=DwICAg=sy2pFYeXOTBQJUPqadkFIXq5lzPIgQxhI8DCCAdSjYc=h5HhK7l-Sb7S5EybxFgVhTmfouIJFux6awyOLzFBk_o=OmN0FDVpocexNp-3-HbUpcHB4rVuTnZaMt9HV7yB2ws=3EkvYPiOwkJZoMKVmIYLDHszoZ5gFw_gZ3Sqx48u7iA=
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net

https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_bacula-2Dusers=DwICAg=sy2pFYeXOTBQJUPqadkFIXq5lzPIgQxhI8DCCAdSjYc=h5HhK7l-Sb7S5EybxFgVhTmfouIJFux6awyOLzFBk_o=OmN0FDVpocexNp-3-HbUpcHB4rVuTnZaMt9HV7yB2ws=l6JwFmldtJUFrLaECgIfziwSqzsRQ8LR1V6_3_REKBI=


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Packet size too big errors

On Monday 2018-03-05 12:32:50 Dimitri Maziuk wrote:
> On 03/05/2018 12:00 PM, Josip Deanovic wrote:
> > On Monday 2018-03-05 17:08:45 Shawn Rappaport wrote:
> >> Thank you, Patti! You were correct. It turns out there was a
> >> vulnerability scan run against that network at that time.
> > 
> > Did you configure your bacula to use SSL/TLS connection?
> > I wonder if that would help in your case.
> 
> I'd expect to still see "invalid HELO" logged. Firewalling the port
> would work if the scanner and bacula clients live in different subnets.

But the log says: UA Hello from client:10.32.12.18:9101
The same IP was mentioned several times in the logs Shawn provided.

The question is: is the IP 10.32.12.18 the IP of the client that had
to be backed up?

If yes then the vulnerability scan overtook the client's IP.

-- 
Josip Deanovic

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Packet size too big errors

On 03/05/2018 12:00 PM, Josip Deanovic wrote:
> On Monday 2018-03-05 17:08:45 Shawn Rappaport wrote:
>> Thank you, Patti! You were correct. It turns out there was a
>> vulnerability scan run against that network at that time.
> 
> Did you configure your bacula to use SSL/TLS connection?
> I wonder if that would help in your case.

I'd expect to still see "invalid HELO" logged. Firewalling the port
would work if the scanner and bacula clients live in different subnets.

-- 
Dimitri Maziuk
Programmer/sysadmin
BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu



signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Packet size too big errors

On Monday 2018-03-05 17:08:45 Shawn Rappaport wrote:
> Thank you, Patti! You were correct. It turns out there was a
> vulnerability scan run against that network at that time.

Did you configure your bacula to use SSL/TLS connection?
I wonder if that would help in your case.

-- 
Josip Deanovic

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Packet size too big errors

Thank you, Patti! You were correct. It turns out there was a vulnerability scan 
run against that network at that time.

--Shawn

From: "Clark, Patti" <clar...@ornl.gov>
Date: Monday, March 5, 2018 at 8:05 AM
To: Shawn Rappaport <srappap...@shutterfly.com>, 
"bacula-users@lists.sourceforge.net" <bacula-users@lists.sourceforge.net>
Subject: Re: [Bacula-users] Packet size too big errors

Not from your backup.  You have something on the network that is scanning the 
server your director is running on.  Probably Nessus.  I’m sure the client IP 
is a clue.

Patti

From: Shawn Rappaport <srappap...@shutterfly.com>
Date: Sunday, March 4, 2018 at 6:06 PM
To: "bacula-users@lists.sourceforge.net" <bacula-users@lists.sourceforge.net>
Subject: [Bacula-users] Packet size too big errors

I’m running Bacula 9.0.6 on CentOS 7.3. Today I received the following errors 
when my catalog was backing up:

03-Mar 12:27 xbacdirector01-lv.internal.shutterfly.com-dir: ERROR in 
authenticate.c:330 UA Hello from client:10.32.12.18:9101 is invalid. Len=0

03-Mar 12:27 xbacdirector01-lv.internal.shutterfly.com-dir: ERROR in 
authenticate.c:330 UA Hello from client:10.32.12.18:9101 is invalid. Len=-4
03-Mar 12:27 xbacdirector01-lv.internal.shutterfly.com-dir JobId 0: Fatal 
error: bsock.c:819 Packet size=121984032 too big from 
"client:10.32.12.18:9101". Maximum permitted 100. Terminating connection.

03-Mar 12:28 xbacdirector01-lv.internal.shutterfly.com-dir: ERROR in 
authenticate.c:330 UA Hello from client:10.32.12.18:9101 is invalid. Len=-4
03-Mar 12:28 xbacdirector01-lv.internal.shutterfly.com-dir JobId 0: Fatal 
error: bsock.c:819 Packet size=138759248 too big from 
"client:10.32.12.18:9101". Maximum permitted 100. Terminating connection.

03-Mar 12:28 xbacdirector01-lv.internal.shutterfly.com-dir: ERROR in 
authenticate.c:330 UA Hello from client:10.32.12.18:9101 is invalid. Len=-4
03-Mar 12:28 xbacdirector01-lv.internal.shutterfly.com-dir JobId 0: Fatal 
error: bsock.c:819 Packet size=50331667 too big from "client:10.32.12.18:9101". 
Maximum permitted 100. Terminating connection.

I manually ran a backup of my catalog after I received the errors and it was 
successful.

Does anyone know why I would be getting these messages and if it’s something to 
be concerned about?

--Shawn
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Packet size too big errors

2018-03-05 Thread Clark, Patti

Not from your backup.  You have something on the network that is scanning the 
server your director is running on.  Probably Nessus.  I’m sure the client IP 
is a clue.

Patti

From: Shawn Rappaport <srappap...@shutterfly.com>
Date: Sunday, March 4, 2018 at 6:06 PM
To: "bacula-users@lists.sourceforge.net" <bacula-users@lists.sourceforge.net>
Subject: [Bacula-users] Packet size too big errors

I’m running Bacula 9.0.6 on CentOS 7.3. Today I received the following errors 
when my catalog was backing up:

03-Mar 12:27 xbacdirector01-lv.internal.shutterfly.com-dir: ERROR in 
authenticate.c:330 UA Hello from client:10.32.12.18:9101 is invalid. Len=0

03-Mar 12:27 xbacdirector01-lv.internal.shutterfly.com-dir: ERROR in 
authenticate.c:330 UA Hello from client:10.32.12.18:9101 is invalid. Len=-4
03-Mar 12:27 xbacdirector01-lv.internal.shutterfly.com-dir JobId 0: Fatal 
error: bsock.c:819 Packet size=121984032 too big from 
"client:10.32.12.18:9101". Maximum permitted 100. Terminating connection.

03-Mar 12:28 xbacdirector01-lv.internal.shutterfly.com-dir: ERROR in 
authenticate.c:330 UA Hello from client:10.32.12.18:9101 is invalid. Len=-4
03-Mar 12:28 xbacdirector01-lv.internal.shutterfly.com-dir JobId 0: Fatal 
error: bsock.c:819 Packet size=138759248 too big from 
"client:10.32.12.18:9101". Maximum permitted 100. Terminating connection.

03-Mar 12:28 xbacdirector01-lv.internal.shutterfly.com-dir: ERROR in 
authenticate.c:330 UA Hello from client:10.32.12.18:9101 is invalid. Len=-4
03-Mar 12:28 xbacdirector01-lv.internal.shutterfly.com-dir JobId 0: Fatal 
error: bsock.c:819 Packet size=50331667 too big from "client:10.32.12.18:9101". 
Maximum permitted 100. Terminating connection.

I manually ran a backup of my catalog after I received the errors and it was 
successful.

Does anyone know why I would be getting these messages and if it’s something to 
be concerned about?

--Shawn
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

[Bacula-users] Packet size too big errors

2018-03-04 Thread Shawn Rappaport

I’m running Bacula 9.0.6 on CentOS 7.3. Today I received the following errors 
when my catalog was backing up:

03-Mar 12:27 xbacdirector01-lv.internal.shutterfly.com-dir: ERROR in 
authenticate.c:330 UA Hello from client:10.32.12.18:9101 is invalid. Len=0

03-Mar 12:27 xbacdirector01-lv.internal.shutterfly.com-dir: ERROR in 
authenticate.c:330 UA Hello from client:10.32.12.18:9101 is invalid. Len=-4
03-Mar 12:27 xbacdirector01-lv.internal.shutterfly.com-dir JobId 0: Fatal 
error: bsock.c:819 Packet size=121984032 too big from 
"client:10.32.12.18:9101". Maximum permitted 100. Terminating connection.

03-Mar 12:28 xbacdirector01-lv.internal.shutterfly.com-dir: ERROR in 
authenticate.c:330 UA Hello from client:10.32.12.18:9101 is invalid. Len=-4
03-Mar 12:28 xbacdirector01-lv.internal.shutterfly.com-dir JobId 0: Fatal 
error: bsock.c:819 Packet size=138759248 too big from 
"client:10.32.12.18:9101". Maximum permitted 100. Terminating connection.

03-Mar 12:28 xbacdirector01-lv.internal.shutterfly.com-dir: ERROR in 
authenticate.c:330 UA Hello from client:10.32.12.18:9101 is invalid. Len=-4
03-Mar 12:28 xbacdirector01-lv.internal.shutterfly.com-dir JobId 0: Fatal 
error: bsock.c:819 Packet size=50331667 too big from "client:10.32.12.18:9101". 
Maximum permitted 100. Terminating connection.

I manually ran a backup of my catalog after I received the errors and it was 
successful.

Does anyone know why I would be getting these messages and if it’s something to 
be concerned about?

--Shawn
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Packet size too big from client

2015-12-19 Thread Ana Emília M . Arruda

This is a very frequently problem if you have a damaged network card.

Best regards,
Ana

On Fri, Dec 18, 2015 at 2:56 PM, Kern Sibbald  wrote:

> Many Windows machines do not support (i.e. get errors) network buffer
> sizes greater than 32K.  This is likely the case for you.   The manual
> probably explains this a bit more.  The problem can be resolved (if it is
> this particular problem) by getting a better network card in your Windows
> machine or limiting the network buffer size in the Windows Bacula FD.
>
> Best regards,
> Kern
>
>
> On 12/17/2015 07:33 PM, Gilberto Nunes wrote:
>
> Oh boy!
> I change bacula version to 7.2.0, set net keepalive to 60, set Spool Size,
> like this
>
>   Maximum Spool Size = 500G
>   Maximum Block Size = 1032192
>   Maximum Network Buffer Size = 65536
>   Spool Directory = /var/spool/bacula
>
> in bacula-sd.conf, but still get the error bellow:
>
> 17-Dec 16:30 storage-global-sd: ERROR in bget_msg.c:95 bget_msg: unknown
> signal -1827994119
> 17-Dec 16:30 storage-global-sd JobId 1003: Fatal error: bsock.c:570 Packet
> size=2102457799 too big from "client:172.16.254.5:9103. Terminating
> connection.
> 17-Dec 16:30 storage-global-sd JobId 1003: Elapsed time=00:06:29, Transfer
> rate=78.19 K Bytes/second
> 17-Dec 16:30 storage-global-sd JobId 1003: Fatal error: Error creating
> JobMedia records: 1000 OK VolName=Bkp-WCF0123 VolJobs=2 VolFiles=0
> VolBlocks=62 VolBytes=63996110 VolABytes=0 VolHoleBytes=0 VolHoles=0
> VolMounts=2 VolErrors=0 VolWrites=63 MaxVolBytes=5000
> VolCapacityBytes=0 VolStatus=Append Slot=0 MaxVolJobs=0 MaxVolFiles=0
> InChanger=0 VolReadTime=0 VolWriteTime=61424 EndFile=0 EndBlock=34062542
> VolType=1 LabelType=0 MediaId=123 ScratchPoolId=0
>
> 17-Dec 16:30 global-wcf-fd JobId 1003: Error: lib/bsock.c:429 Write error
> sending 8 bytes to Storage daemon:172.16.221.232:9103: ERR=Input/output
> error
> 17-Dec 16:30 global-wcf-fd JobId 1003: Error: lib/bsock.c:375 Socket has
> errors=1 on call to Storage daemon:172.16.221.232:9103
> 17-Dec 16:30 global-wcf-fd JobId 1003: Error: lib/bsock.c:375 Socket has
> errors=1 on call to Storage daemon:172.16.221.232:9103
> 17-Dec 16:30 global-wcf-fd JobId 1003: Fatal error: filed/backup.c:1320
> Network send error to SD. ERR=Input/output error
>
>
>
> Suggestions???
>
>
> Thanks
>
> 2015-12-17 15:32 GMT-02:00 Gilberto Nunes :
>
>> I will try update bacula to 7.2...
>> Somebody know where I can find deb package for Debian??
>>
>> Thanks a lot
>>
>> 2015-12-17 15:20 GMT-02:00 Gilberto Nunes < 
>> gilberto.nune...@gmail.com>:
>>
>>> Well...
>>> If the situation was that, I agreed with you, but that is not the
>>> case
>>> I have several clients...
>>> And one of them the bacula client is the exactly same version of bacula
>>> directory: 5.2.6...
>>> And I get the exactly the same error
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> 2015-12-17 15:12 GMT-02:00 Heitor Faria < 
>>> hei...@bacula.com.br>:
>>>
 hello bacula users...

 Suddenly, bacula return me this error:

 Packet size too big from client 

 This error happens just from one server.
 The server is Linux Debian 64 bits.
 I already down firewall for a while, just to check... No effect.
 Change the network interface and cable, to isolate bacula/fd traffic to
 another IP and network channel: same results!

 The the entire erro:

 17-Dec 14:37 storage-global-sd JobId 996: Fatal error: bsock.c:503
 Packet size too big from "client:172.16.254.5:36643. Terminating
 connection.
 17-Dec 14:37 storage-global-sd JobId 996: Fatal error: append.c:161
 Error reading data header from FD. ERR=No data available
 17-Dec 14:37 storage-global-sd JobId 996: Job write elapsed time =
 00:05:38, Transfer rate = 21.09 K Bytes/second
 17-Dec 14:37 global-wcf-fd JobId 996: Error: lib/bsock.c:429 Write
 error sending 7 bytes to Storage daemon:172.16.221.232:9103:
 ERR=Input/output error
 17-Dec 14:37 global-wcf-fd JobId 996: Error: lib/bsock.c:375 Socket has
 errors=1 on call to Storage daemon:172.16.221.232:9103
 17-Dec 14:37 global-wcf-fd JobId 996: Error: lib/bsock.c:375 Socket has
 errors=1 on call to Storage daemon:172.16.221.232:9103
 17-Dec 14:37 global-wcf-fd JobId 996: Fatal error: filed/backup.c:1320
 Network send error to SD. ERR=Input/output error
 17-Dec 14:37 global-wcf-fd JobId 996: VSS Writer (BackupComplete):
 "Task Scheduler Writer", State: 0x1 (VSS_WS_STABLE)
 17-Dec 14:37 global-wcf-fd JobId 996: VSS Writer (BackupComplete): "VSS
 Metadata Store Writer", State: 0x1 (VSS_WS_STABLE)
 17-Dec 14:37 global-wcf-fd JobId 996: VSS Writer (BackupComplete):
 "Performance Counters Writer", State: 0x1 (VSS_WS_STABLE)
 17-Dec 14:37 global-wcf-fd JobId 996: VSS Writer (BackupComplete):
 "System Writer", State: 0x1 (VSS_WS_STABLE)

Re: [Bacula-users] Packet size too big from client

2015-12-18 Thread Radosław Korzeniewski

Hello,

2015-12-17 19:33 GMT+01:00 Gilberto Nunes :

> 17-Dec 16:30 storage-global-sd: ERROR in bget_msg.c:95 bget_msg: unknown
> signal -1827994119
> 17-Dec 16:30 storage-global-sd JobId 1003: Fatal error: bsock.c:570 Packet
> size=2102457799 too big from "client:172.16.254.5:9103. Terminating
> connection.
>

Something/someone is mangling your network transmission. Every message
exchanged in Bacula consist of a following stream: ...

So during your backup Bacula SD received a  which value was:
2102457799, but Bacula allow packet size to be no greater then 10^6 bytes.
The signal is a value less then zero.

You need to verify what is going on on your network or servers.

best regards
-- 
Radosław Korzeniewski
rados...@korzeniewski.net
--
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Packet size too big from client

2015-12-18 Thread Gilberto Nunes

Hello

I change bacula to other server, and works perfectly!

Thank you!

2015-12-18 7:52 GMT-02:00 Radosław Korzeniewski :

> Hello,
>
> 2015-12-17 19:33 GMT+01:00 Gilberto Nunes :
>
>> 17-Dec 16:30 storage-global-sd: ERROR in bget_msg.c:95 bget_msg: unknown
>> signal -1827994119
>> 17-Dec 16:30 storage-global-sd JobId 1003: Fatal error: bsock.c:570
>> Packet size=2102457799 too big from "client:172.16.254.5:9103.
>> Terminating connection.
>>
>
> Something/someone is mangling your network transmission. Every message
> exchanged in Bacula consist of a following stream:  "packed size" bytes>...
>
> So during your backup Bacula SD received a  which value was:
> 2102457799, but Bacula allow packet size to be no greater then 10^6 bytes.
> The signal is a value less then zero.
>
> You need to verify what is going on on your network or servers.
>
> best regards
> --
> Radosław Korzeniewski
> rados...@korzeniewski.net
>



-- 

Gilberto Ferreira
+55 (47) 9676-7530
Skype: gilberto.nunes36
--
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Packet size too big from client

2015-12-18 Thread Kern Sibbald


  
  
Many Windows machines do not support
  (i.e. get errors) network buffer sizes greater than 32K.  This is
  likely the case for you.   The manual probably explains this a bit
  more.  The problem can be resolved (if it is this particular
  problem) by getting a better network card in your Windows machine
  or limiting the network buffer size in the Windows Bacula FD.
  
  Best regards,
  Kern
  
  On 12/17/2015 07:33 PM, Gilberto Nunes wrote:


  

  Oh boy!
  
  I change bacula version to 7.2.0, set net keepalive to 60, set
  Spool Size, like this
  
    Maximum Spool Size = 500G
    Maximum Block Size = 1032192
    Maximum Network Buffer Size = 65536
    Spool Directory = /var/spool/bacula
  

in bacula-sd.conf, but still get the error bellow:

  17-Dec 16:30 storage-global-sd: ERROR in bget_msg.c:95
  bget_msg: unknown signal -1827994119
  17-Dec 16:30 storage-global-sd JobId 1003: Fatal error:
  bsock.c:570 Packet size=2102457799 too big from "client:172.16.254.5:9103.
  Terminating connection.
  17-Dec 16:30 storage-global-sd JobId 1003: Elapsed
  time=00:06:29, Transfer rate=78.19 K Bytes/second
  17-Dec 16:30 storage-global-sd JobId 1003: Fatal error: Error
  creating JobMedia records: 1000 OK VolName=Bkp-WCF0123
  VolJobs=2 VolFiles=0 VolBlocks=62 VolBytes=63996110
  VolABytes=0 VolHoleBytes=0 VolHoles=0 VolMounts=2 VolErrors=0
  VolWrites=63 MaxVolBytes=5000 VolCapacityBytes=0
  VolStatus=Append Slot=0 MaxVolJobs=0 MaxVolFiles=0 InChanger=0
  VolReadTime=0 VolWriteTime=61424 EndFile=0 EndBlock=34062542
  VolType=1 LabelType=0 MediaId=123 ScratchPoolId=0
  
  17-Dec 16:30 global-wcf-fd JobId 1003: Error: lib/bsock.c:429
  Write error sending 8 bytes to Storage daemon:172.16.221.232:9103:
  ERR=Input/output error
  17-Dec 16:30 global-wcf-fd JobId 1003: Error: lib/bsock.c:375
  Socket has errors=1 on call to Storage daemon:172.16.221.232:9103
  17-Dec 16:30 global-wcf-fd JobId 1003: Error: lib/bsock.c:375
  Socket has errors=1 on call to Storage daemon:172.16.221.232:9103
  17-Dec 16:30 global-wcf-fd JobId 1003: Fatal error:
  filed/backup.c:1320 Network send error to SD. ERR=Input/output
  error
  
  
  

Suggestions???
  
  

Thanks

  
  
2015-12-17 15:32 GMT-02:00 Gilberto
  Nunes :
  

  
I will try update bacula to 7.2...

Somebody know where I can find deb package for Debian??

  
  Thanks a lot


  2015-12-17 15:20
  GMT-02:00 Gilberto Nunes :


  

  

  

  

  Well...
  
  If the situation was that, I agreed
  with you, but that is not the case

I have several clients...
  
  And one of them the bacula client is the
  exactly same version of bacula directory:
  5.2.6...

And I get the exactly the same error
  



  



  

  

  
  

  

  

  
  

  
2015-12-17 15:12
  GMT-02:00 Heitor Faria :

[Bacula-users] Packet size too big from client

Hello bacula users...

Suddenly, bacula return me this error:

Packet size too big from client 

This error happens just from one server.
The server is Linux Debian 64 bits.
I already down firewall for a while, just to check... No effect.
Change the network interface and cable, to isolate bacula/fd traffic to
another IP and network channel: same results!

The the entire erro:

17-Dec 14:37 storage-global-sd JobId 996: Fatal error: bsock.c:503 Packet
size too big from "client:172.16.254.5:36643. Terminating connection.
17-Dec 14:37 storage-global-sd JobId 996: Fatal error: append.c:161 Error
reading data header from FD. ERR=No data available
17-Dec 14:37 storage-global-sd JobId 996: Job write elapsed time =
00:05:38, Transfer rate = 21.09 K Bytes/second
17-Dec 14:37 global-wcf-fd JobId 996: Error: lib/bsock.c:429 Write error
sending 7 bytes to Storage daemon:172.16.221.232:9103: ERR=Input/output
error
17-Dec 14:37 global-wcf-fd JobId 996: Error: lib/bsock.c:375 Socket has
errors=1 on call to Storage daemon:172.16.221.232:9103
17-Dec 14:37 global-wcf-fd JobId 996: Error: lib/bsock.c:375 Socket has
errors=1 on call to Storage daemon:172.16.221.232:9103
17-Dec 14:37 global-wcf-fd JobId 996: Fatal error: filed/backup.c:1320
Network send error to SD. ERR=Input/output error
17-Dec 14:37 global-wcf-fd JobId 996: VSS Writer (BackupComplete): "Task
Scheduler Writer", State: 0x1 (VSS_WS_STABLE)
17-Dec 14:37 global-wcf-fd JobId 996: VSS Writer (BackupComplete): "VSS
Metadata Store Writer", State: 0x1 (VSS_WS_STABLE)
17-Dec 14:37 global-wcf-fd JobId 996: VSS Writer (BackupComplete):
"Performance Counters Writer", State: 0x1 (VSS_WS_STABLE)
17-Dec 14:37 global-wcf-fd JobId 996: VSS Writer (BackupComplete): "System
Writer", State: 0x1 (VSS_WS_STABLE)
17-Dec 14:37 global-wcf-fd JobId 996: VSS Writer (BackupComplete): "ASR
Writer", State: 0x1 (VSS_WS_STABLE)
17-Dec 14:37 global-wcf-fd JobId 996: VSS Writer (BackupComplete):
"Registry Writer", State: 0x1 (VSS_WS_STABLE)
17-Dec 14:37 global-wcf-fd JobId 996: VSS Writer (BackupComplete): "IIS
Config Writer", State: 0x1 (VSS_WS_STABLE)
17-Dec 14:37 global-wcf-fd JobId 996: VSS Writer (BackupComplete): "WMI
Writer", State: 0x1 (VSS_WS_STABLE)
17-Dec 14:37 global-wcf-fd JobId 996: VSS Writer (BackupComplete): "Shadow
Copy Optimization Writer", State: 0x1 (VSS_WS_STABLE)
17-Dec 14:37 global-wcf-fd JobId 996: VSS Writer (BackupComplete): "COM+
REGDB Writer", State: 0x1 (VSS_WS_STABLE)
17-Dec 14:37 backup-global JobId 996: Error: Bacula backup-global 5.2.6
(21Feb12):
  Build OS:   x86_64-pc-linux-gnu debian jessie/sid
  JobId:  996
  Job:WFC-Job.2015-12-17_14.32.00_59
  Backup Level:   Incremental, since=2015-12-16 03:30:05
  Client: "WCF" 5.2.10 (28Jun12) Microsoft Windows Server
2008 R2 Enterprise Edition Service Pack 1 (build 7601),
64-bit,Cross-compile,Win64
  FileSet:"WCF" 2015-09-04 04:30:00
  Pool:   "WCF" (From Job resource)
  Catalog:"MyCatalog" (From Client resource)
  Storage:"WCF-Storage-Daemon" (From Job resource)
  Scheduled time: 17-Dec-2015 14:31:53
  Start time: 17-Dec-2015 14:32:03
  End time:   17-Dec-2015 14:37:59
  Elapsed time:   5 mins 56 secs
  Priority:   1
  FD Files Written:   33
  SD Files Written:   32
  FD Bytes Written:   7,106,691 (7.106 MB)
  SD Bytes Written:   7,128,953 (7.128 MB)
  Rate:   20.0 KB/s
  Software Compression:   10.8 %
  VSS:yes
  Encryption: yes
  Accurate:   no
  Volume name(s): Bkp-WCF0122
  Volume Session Id:  30
  Volume Session Time:1450288692
  Last Volume Bytes:  7,096,515 (7.096 MB)
  Non-fatal FD errors:3
  SD Errors:  1
  FD termination status:  Error
  SD termination status:  Error
  Termination:*** Backup Error ***


Notice the Storage Daemon I/O Error...
I don't know whats this error are related for, 'cause the disk is OK...
There's no warnning about I/O errror...
I can see the disk, mount it on /backup and list the content...
Somebody can help me???


Thanks a lot.


-- 

Gilberto Ferreira
+55 (47) 9676-7530
Skype: gilberto.nunes36
--
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Packet size too big from client

2015-12-17 Thread Heitor Faria

> hello bacula users...

> Suddenly, bacula return me this error:

> Packet size too big from client 

> This error happens just from one server.
> The server is Linux Debian 64 bits.
> I already down firewall for a while, just to check... No effect.
> Change the network interface and cable, to isolate bacula/fd traffic to 
> another
> IP and network channel: same results!

> The the entire erro:

> 17-Dec 14:37 storage-global-sd JobId 996: Fatal error: bsock.c:503 Packet size
> too big from "client: 172.16.254.5:36643 . Terminating connection.
> 17-Dec 14:37 storage-global-sd JobId 996: Fatal error: append.c:161 Error
> reading data header from FD. ERR=No data available
> 17-Dec 14:37 storage-global-sd JobId 996: Job write elapsed time = 00:05:38,
> Transfer rate = 21.09 K Bytes/second
> 17-Dec 14:37 global-wcf-fd JobId 996: Error: lib/bsock.c:429 Write error 
> sending
> 7 bytes to Storage daemon: 172.16.221.232:9103 : ERR=Input/output error
> 17-Dec 14:37 global-wcf-fd JobId 996: Error: lib/bsock.c:375 Socket has 
> errors=1
> on call to Storage daemon: 172.16.221.232:9103
> 17-Dec 14:37 global-wcf-fd JobId 996: Error: lib/bsock.c:375 Socket has 
> errors=1
> on call to Storage daemon: 172.16.221.232:9103
> 17-Dec 14:37 global-wcf-fd JobId 996: Fatal error: filed/backup.c:1320 Network
> send error to SD. ERR=Input/output error
> 17-Dec 14:37 global-wcf-fd JobId 996: VSS Writer (BackupComplete): "Task
> Scheduler Writer", State: 0x1 (VSS_WS_STABLE)
> 17-Dec 14:37 global-wcf-fd JobId 996: VSS Writer (BackupComplete): "VSS 
> Metadata
> Store Writer", State: 0x1 (VSS_WS_STABLE)
> 17-Dec 14:37 global-wcf-fd JobId 996: VSS Writer (BackupComplete): 
> "Performance
> Counters Writer", State: 0x1 (VSS_WS_STABLE)
> 17-Dec 14:37 global-wcf-fd JobId 996: VSS Writer (BackupComplete): "System
> Writer", State: 0x1 (VSS_WS_STABLE)
> 17-Dec 14:37 global-wcf-fd JobId 996: VSS Writer (BackupComplete): "ASR 
> Writer",
> State: 0x1 (VSS_WS_STABLE)
> 17-Dec 14:37 global-wcf-fd JobId 996: VSS Writer (BackupComplete): "Registry
> Writer", State: 0x1 (VSS_WS_STABLE)
> 17-Dec 14:37 global-wcf-fd JobId 996: VSS Writer (BackupComplete): "IIS Config
> Writer", State: 0x1 (VSS_WS_STABLE)
> 17-Dec 14:37 global-wcf-fd JobId 996: VSS Writer (BackupComplete): "WMI 
> Writer",
> State: 0x1 (VSS_WS_STABLE)
> 17-Dec 14:37 global-wcf-fd JobId 996: VSS Writer (BackupComplete): "Shadow 
> Copy
> Optimization Writer", State: 0x1 (VSS_WS_STABLE)
> 17-Dec 14:37 global-wcf-fd JobId 996: VSS Writer (BackupComplete): "COM+ REGDB
> Writer", State: 0x1 (VSS_WS_STABLE)
> 17-Dec 14:37 backup-global JobId 996: Error: Bacula backup-global 5.2.6
> (21Feb12):
> Build OS: x86_64-pc-linux-gnu debian jessie/sid
> JobId: 996
> Job: WFC-Job.2015-12-17_14.32.00_59
> Backup Level: Incremental, since=2015-12-16 03:30:05
> Client: "WCF" 5.2.10 (28Jun12) Microsoft Windows Server 2008 R2 Enterprise
> Edition Service Pack 1 (build 7601), 64-bit,Cross-compile,Win64

Hello Gilberto: client version should never be greater than director's one. 

Regards, 
=== 
Heitor Medrado de Faria - LPIC-III | ITIL-F | Bacula Systems Certified 
Administrator II 
Do you need Bacula training? http://bacula.us/video-classes/ 
+55 61 8268-4220 
Site: http://bacula.us FB: heitor.faria 
=== 
--
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Packet size too big from client

Well...
If the situation was that, I agreed with you, but that is not the case
I have several clients...
And one of them the bacula client is the exactly same version of bacula
directory: 5.2.6...
And I get the exactly the same error







2015-12-17 15:12 GMT-02:00 Heitor Faria :

> hello bacula users...
>
> Suddenly, bacula return me this error:
>
> Packet size too big from client 
>
> This error happens just from one server.
> The server is Linux Debian 64 bits.
> I already down firewall for a while, just to check... No effect.
> Change the network interface and cable, to isolate bacula/fd traffic to
> another IP and network channel: same results!
>
> The the entire erro:
>
> 17-Dec 14:37 storage-global-sd JobId 996: Fatal error: bsock.c:503 Packet
> size too big from "client:172.16.254.5:36643. Terminating connection.
> 17-Dec 14:37 storage-global-sd JobId 996: Fatal error: append.c:161 Error
> reading data header from FD. ERR=No data available
> 17-Dec 14:37 storage-global-sd JobId 996: Job write elapsed time =
> 00:05:38, Transfer rate = 21.09 K Bytes/second
> 17-Dec 14:37 global-wcf-fd JobId 996: Error: lib/bsock.c:429 Write error
> sending 7 bytes to Storage daemon:172.16.221.232:9103: ERR=Input/output
> error
> 17-Dec 14:37 global-wcf-fd JobId 996: Error: lib/bsock.c:375 Socket has
> errors=1 on call to Storage daemon:172.16.221.232:9103
> 17-Dec 14:37 global-wcf-fd JobId 996: Error: lib/bsock.c:375 Socket has
> errors=1 on call to Storage daemon:172.16.221.232:9103
> 17-Dec 14:37 global-wcf-fd JobId 996: Fatal error: filed/backup.c:1320
> Network send error to SD. ERR=Input/output error
> 17-Dec 14:37 global-wcf-fd JobId 996: VSS Writer (BackupComplete): "Task
> Scheduler Writer", State: 0x1 (VSS_WS_STABLE)
> 17-Dec 14:37 global-wcf-fd JobId 996: VSS Writer (BackupComplete): "VSS
> Metadata Store Writer", State: 0x1 (VSS_WS_STABLE)
> 17-Dec 14:37 global-wcf-fd JobId 996: VSS Writer (BackupComplete):
> "Performance Counters Writer", State: 0x1 (VSS_WS_STABLE)
> 17-Dec 14:37 global-wcf-fd JobId 996: VSS Writer (BackupComplete): "System
> Writer", State: 0x1 (VSS_WS_STABLE)
> 17-Dec 14:37 global-wcf-fd JobId 996: VSS Writer (BackupComplete): "ASR
> Writer", State: 0x1 (VSS_WS_STABLE)
> 17-Dec 14:37 global-wcf-fd JobId 996: VSS Writer (BackupComplete):
> "Registry Writer", State: 0x1 (VSS_WS_STABLE)
> 17-Dec 14:37 global-wcf-fd JobId 996: VSS Writer (BackupComplete): "IIS
> Config Writer", State: 0x1 (VSS_WS_STABLE)
> 17-Dec 14:37 global-wcf-fd JobId 996: VSS Writer (BackupComplete): "WMI
> Writer", State: 0x1 (VSS_WS_STABLE)
> 17-Dec 14:37 global-wcf-fd JobId 996: VSS Writer (BackupComplete): "Shadow
> Copy Optimization Writer", State: 0x1 (VSS_WS_STABLE)
> 17-Dec 14:37 global-wcf-fd JobId 996: VSS Writer (BackupComplete): "COM+
> REGDB Writer", State: 0x1 (VSS_WS_STABLE)
> 17-Dec 14:37 backup-global JobId 996: Error: Bacula backup-global 5.2.6
> (21Feb12):
>   Build OS:   x86_64-pc-linux-gnu debian jessie/sid
>   JobId:  996
>   Job:WFC-Job.2015-12-17_14.32.00_59
>   Backup Level:   Incremental, since=2015-12-16 03:30:05
>   Client: "WCF" 5.2.10 (28Jun12) Microsoft Windows Server
> 2008 R2 Enterprise Edition Service Pack 1 (build 7601),
> 64-bit,Cross-compile,Win64
>
> Hello Gilberto: client version should never be greater than director's one.
>
> Regards,
> ===
> Heitor Medrado de Faria - LPIC-III | ITIL-F |  Bacula Systems Certified
> Administrator II
> Do you need Bacula training? http://bacula.us/video-classes/
> +55 61 <%2B55%2061%202021-8260>8268-4220 <%2B55%2061%208268-4220>
> Site: http://bacula.us FB: heitor.faria
> 
> ===
>
>
>


-- 

Gilberto Ferreira
+55 (47) 9676-7530
Skype: gilberto.nunes36
--
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Packet size too big from client

I will try update bacula to 7.2...
Somebody know where I can find deb package for Debian??

Thanks a lot

2015-12-17 15:20 GMT-02:00 Gilberto Nunes :

> Well...
> If the situation was that, I agreed with you, but that is not the case
> I have several clients...
> And one of them the bacula client is the exactly same version of bacula
> directory: 5.2.6...
> And I get the exactly the same error
>
>
>
>
>
>
>
> 2015-12-17 15:12 GMT-02:00 Heitor Faria :
>
>> hello bacula users...
>>
>> Suddenly, bacula return me this error:
>>
>> Packet size too big from client 
>>
>> This error happens just from one server.
>> The server is Linux Debian 64 bits.
>> I already down firewall for a while, just to check... No effect.
>> Change the network interface and cable, to isolate bacula/fd traffic to
>> another IP and network channel: same results!
>>
>> The the entire erro:
>>
>> 17-Dec 14:37 storage-global-sd JobId 996: Fatal error: bsock.c:503 Packet
>> size too big from "client:172.16.254.5:36643. Terminating connection.
>> 17-Dec 14:37 storage-global-sd JobId 996: Fatal error: append.c:161 Error
>> reading data header from FD. ERR=No data available
>> 17-Dec 14:37 storage-global-sd JobId 996: Job write elapsed time =
>> 00:05:38, Transfer rate = 21.09 K Bytes/second
>> 17-Dec 14:37 global-wcf-fd JobId 996: Error: lib/bsock.c:429 Write error
>> sending 7 bytes to Storage daemon:172.16.221.232:9103: ERR=Input/output
>> error
>> 17-Dec 14:37 global-wcf-fd JobId 996: Error: lib/bsock.c:375 Socket has
>> errors=1 on call to Storage daemon:172.16.221.232:9103
>> 17-Dec 14:37 global-wcf-fd JobId 996: Error: lib/bsock.c:375 Socket has
>> errors=1 on call to Storage daemon:172.16.221.232:9103
>> 17-Dec 14:37 global-wcf-fd JobId 996: Fatal error: filed/backup.c:1320
>> Network send error to SD. ERR=Input/output error
>> 17-Dec 14:37 global-wcf-fd JobId 996: VSS Writer (BackupComplete): "Task
>> Scheduler Writer", State: 0x1 (VSS_WS_STABLE)
>> 17-Dec 14:37 global-wcf-fd JobId 996: VSS Writer (BackupComplete): "VSS
>> Metadata Store Writer", State: 0x1 (VSS_WS_STABLE)
>> 17-Dec 14:37 global-wcf-fd JobId 996: VSS Writer (BackupComplete):
>> "Performance Counters Writer", State: 0x1 (VSS_WS_STABLE)
>> 17-Dec 14:37 global-wcf-fd JobId 996: VSS Writer (BackupComplete):
>> "System Writer", State: 0x1 (VSS_WS_STABLE)
>> 17-Dec 14:37 global-wcf-fd JobId 996: VSS Writer (BackupComplete): "ASR
>> Writer", State: 0x1 (VSS_WS_STABLE)
>> 17-Dec 14:37 global-wcf-fd JobId 996: VSS Writer (BackupComplete):
>> "Registry Writer", State: 0x1 (VSS_WS_STABLE)
>> 17-Dec 14:37 global-wcf-fd JobId 996: VSS Writer (BackupComplete): "IIS
>> Config Writer", State: 0x1 (VSS_WS_STABLE)
>> 17-Dec 14:37 global-wcf-fd JobId 996: VSS Writer (BackupComplete): "WMI
>> Writer", State: 0x1 (VSS_WS_STABLE)
>> 17-Dec 14:37 global-wcf-fd JobId 996: VSS Writer (BackupComplete):
>> "Shadow Copy Optimization Writer", State: 0x1 (VSS_WS_STABLE)
>> 17-Dec 14:37 global-wcf-fd JobId 996: VSS Writer (BackupComplete): "COM+
>> REGDB Writer", State: 0x1 (VSS_WS_STABLE)
>> 17-Dec 14:37 backup-global JobId 996: Error: Bacula backup-global 5.2.6
>> (21Feb12):
>>   Build OS:   x86_64-pc-linux-gnu debian jessie/sid
>>   JobId:  996
>>   Job:WFC-Job.2015-12-17_14.32.00_59
>>   Backup Level:   Incremental, since=2015-12-16 03:30:05
>>   Client: "WCF" 5.2.10 (28Jun12) Microsoft Windows Server
>> 2008 R2 Enterprise Edition Service Pack 1 (build 7601),
>> 64-bit,Cross-compile,Win64
>>
>> Hello Gilberto: client version should never be greater than director's
>> one.
>>
>> Regards,
>>
>> ===
>> Heitor Medrado de Faria - LPIC-III | ITIL-F |  Bacula Systems Certified
>> Administrator II
>> Do you need Bacula training? http://bacula.us/video-classes/
>> +55 61 <%2B55%2061%202021-8260>8268-4220 <%2B55%2061%208268-4220>
>> Site: http://bacula.us FB: heitor.faria
>> 
>>
>> ===
>>
>>
>>
>
>
> --
>
> Gilberto Ferreira
> +55 (47) 9676-7530
> Skype: gilberto.nunes36
>
>


-- 

Gilberto Ferreira
+55 (47) 9676-7530
Skype: gilberto.nunes36
--
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Packet size too big from client

Oh boy!
I change bacula version to 7.2.0, set net keepalive to 60, set Spool Size,
like this

  Maximum Spool Size = 500G
  Maximum Block Size = 1032192
  Maximum Network Buffer Size = 65536
  Spool Directory = /var/spool/bacula

in bacula-sd.conf, but still get the error bellow:

17-Dec 16:30 storage-global-sd: ERROR in bget_msg.c:95 bget_msg: unknown
signal -1827994119
17-Dec 16:30 storage-global-sd JobId 1003: Fatal error: bsock.c:570 Packet
size=2102457799 too big from "client:172.16.254.5:9103. Terminating
connection.
17-Dec 16:30 storage-global-sd JobId 1003: Elapsed time=00:06:29, Transfer
rate=78.19 K Bytes/second
17-Dec 16:30 storage-global-sd JobId 1003: Fatal error: Error creating
JobMedia records: 1000 OK VolName=Bkp-WCF0123 VolJobs=2 VolFiles=0
VolBlocks=62 VolBytes=63996110 VolABytes=0 VolHoleBytes=0 VolHoles=0
VolMounts=2 VolErrors=0 VolWrites=63 MaxVolBytes=5000
VolCapacityBytes=0 VolStatus=Append Slot=0 MaxVolJobs=0 MaxVolFiles=0
InChanger=0 VolReadTime=0 VolWriteTime=61424 EndFile=0 EndBlock=34062542
VolType=1 LabelType=0 MediaId=123 ScratchPoolId=0

17-Dec 16:30 global-wcf-fd JobId 1003: Error: lib/bsock.c:429 Write error
sending 8 bytes to Storage daemon:172.16.221.232:9103: ERR=Input/output
error
17-Dec 16:30 global-wcf-fd JobId 1003: Error: lib/bsock.c:375 Socket has
errors=1 on call to Storage daemon:172.16.221.232:9103
17-Dec 16:30 global-wcf-fd JobId 1003: Error: lib/bsock.c:375 Socket has
errors=1 on call to Storage daemon:172.16.221.232:9103
17-Dec 16:30 global-wcf-fd JobId 1003: Fatal error: filed/backup.c:1320
Network send error to SD. ERR=Input/output error



Suggestions???


Thanks

2015-12-17 15:32 GMT-02:00 Gilberto Nunes :

> I will try update bacula to 7.2...
> Somebody know where I can find deb package for Debian??
>
> Thanks a lot
>
> 2015-12-17 15:20 GMT-02:00 Gilberto Nunes :
>
>> Well...
>> If the situation was that, I agreed with you, but that is not the case
>> I have several clients...
>> And one of them the bacula client is the exactly same version of bacula
>> directory: 5.2.6...
>> And I get the exactly the same error
>>
>>
>>
>>
>>
>>
>>
>> 2015-12-17 15:12 GMT-02:00 Heitor Faria :
>>
>>> hello bacula users...
>>>
>>> Suddenly, bacula return me this error:
>>>
>>> Packet size too big from client 
>>>
>>> This error happens just from one server.
>>> The server is Linux Debian 64 bits.
>>> I already down firewall for a while, just to check... No effect.
>>> Change the network interface and cable, to isolate bacula/fd traffic to
>>> another IP and network channel: same results!
>>>
>>> The the entire erro:
>>>
>>> 17-Dec 14:37 storage-global-sd JobId 996: Fatal error: bsock.c:503
>>> Packet size too big from "client:172.16.254.5:36643. Terminating
>>> connection.
>>> 17-Dec 14:37 storage-global-sd JobId 996: Fatal error: append.c:161
>>> Error reading data header from FD. ERR=No data available
>>> 17-Dec 14:37 storage-global-sd JobId 996: Job write elapsed time =
>>> 00:05:38, Transfer rate = 21.09 K Bytes/second
>>> 17-Dec 14:37 global-wcf-fd JobId 996: Error: lib/bsock.c:429 Write error
>>> sending 7 bytes to Storage daemon:172.16.221.232:9103: ERR=Input/output
>>> error
>>> 17-Dec 14:37 global-wcf-fd JobId 996: Error: lib/bsock.c:375 Socket has
>>> errors=1 on call to Storage daemon:172.16.221.232:9103
>>> 17-Dec 14:37 global-wcf-fd JobId 996: Error: lib/bsock.c:375 Socket has
>>> errors=1 on call to Storage daemon:172.16.221.232:9103
>>> 17-Dec 14:37 global-wcf-fd JobId 996: Fatal error: filed/backup.c:1320
>>> Network send error to SD. ERR=Input/output error
>>> 17-Dec 14:37 global-wcf-fd JobId 996: VSS Writer (BackupComplete): "Task
>>> Scheduler Writer", State: 0x1 (VSS_WS_STABLE)
>>> 17-Dec 14:37 global-wcf-fd JobId 996: VSS Writer (BackupComplete): "VSS
>>> Metadata Store Writer", State: 0x1 (VSS_WS_STABLE)
>>> 17-Dec 14:37 global-wcf-fd JobId 996: VSS Writer (BackupComplete):
>>> "Performance Counters Writer", State: 0x1 (VSS_WS_STABLE)
>>> 17-Dec 14:37 global-wcf-fd JobId 996: VSS Writer (BackupComplete):
>>> "System Writer", State: 0x1 (VSS_WS_STABLE)
>>> 17-Dec 14:37 global-wcf-fd JobId 996: VSS Writer (BackupComplete): "ASR
>>> Writer", State: 0x1 (VSS_WS_STABLE)
>>> 17-Dec 14:37 global-wcf-fd JobId 996: VSS Writer (BackupComplete):
>>> "Registry Writer", State: 0x1 (VSS_WS_STABLE)
>>> 17-Dec 14:37 global-wcf-fd JobId 996: VSS Writer (BackupComplete): "IIS
>>> Config Writer", State: 0x1 (VSS_WS_STABLE)
>>> 17-Dec 14:37 global-wcf-fd JobId 996: VSS Writer (BackupComplete): "WMI
>>> Writer", State: 0x1 (VSS_WS_STABLE)
>>> 17-Dec 14:37 global-wcf-fd JobId 996: VSS Writer (BackupComplete):
>>> "Shadow Copy Optimization Writer", State: 0x1 (VSS_WS_STABLE)
>>> 17-Dec 14:37 global-wcf-fd JobId 996: VSS Writer (BackupComplete): "COM+
>>> REGDB Writer", State: 0x1 (VSS_WS_STABLE)
>>> 17-Dec 14:37 backup-global JobId 996: Error: Bacula backup-global 5.2.6
>>>

Re: [Bacula-users] Packet size too big from client