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