Workbench: Taming a Home Print Server for a Brother HL2240D
It turns out printers are their usual wily selves on Linux too.
I’ve been experimenting with turning my Ubuntu‑based home server (running on a Raspberry Pi) into a network print server for my aging, but reliable Brother HL2240D. This isn’t a polished how‑to guide—it’s a work log of the messy, unexpected challenges of building something real. There’s a lot to be learned from the wild detours in DIY server projects, and if you’re curious about what happens when things don’t go exactly as planned, read on.
The Auth Adventure
Getting CUPS (the Common Unix Printing System) to share the printer over the network turned out to be an adventure. I wrestled with accessing the admin interface over HTTPS versus HTTP, and even encountered some browser cache quirks that made authentication seem inconsistent. After a few refreshes (and the occasional incognito window), I finally got into the CUPS admin pages and configured my printer correctly.
The Driver Debacle
Everything looked promising until I tried printing—CUPS reported that the job was completed, yet no paper came out. Classic! A look at the logs revealed that the Brother proprietary driver was built for i386, which isn’t compatible with my ARM64 (aarch64) Raspberry Pi. I briefly toyed with QEMU emulation, only to find that mixing architectures led to missing libraries and a host of awkward workarounds.
Then I discovered the open‑source brlaser driver—a native solution that does away with emulation entirely. Unfortunately, there was no clear match for my HL2240D in the drivers offered by brlaser: HL2220, HL2140, and HL2270DW. HL2220 sounded closest but community feedback steered me toward the HL2140 option. Once I switched to the native driver, printing actually worked, turning a frustrating mismatch into a practical fix.
In short, what began as a straightforward print server project evolved into a wild ride through browser caches, authentication quirks, and architectural mismatches. This was a classic case where one route (emulation) seemed promising and could’ve worked but would’ve required immense complexity to implement all the needed workarounds. Taking a step back revealed the simplest solution and one I hadn’t considered initially: an open source driver.
Happy tinkering!