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 <stephen.thomp...@berkeley.edu> Sent: 04 January 2022 19:33 To: Martin Simmons Cc: g...@hotmail.co.uk; bacula-users@lists.sourceforge.net <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 888888: Fatal error: bsock.c:530 Packet size=1387166 too big from "client:1.2.3.4:9103". Maximum permitted 1000000. 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. > > Hmmmm... > > 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 888888: Fatal error: bsock.c:530 Packet >>>> size=1387165 >>>> too big from "client:1.2.3.4:9103". Maximum permitted 1000000. >>>> 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 <g...@hotmail.co.uk> >>>>> 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 <brodb...@math.ucsb.edu> >>>>>> 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 >>>>>> 1000000. 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 <jfis...@jaybus.com> >>>>>> 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 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 >>>>>> >>>>>> >>>>>> -- >>>>>> 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 >>>>>> >>>>>> >>>>>> -- >>>>>> 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 >>>>> >>>> >>>> >>>> -- >>>> 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
