---
title: 'Workbench: Taming a Home Print Server for a Brother HL2240D'
date: 2025-04-13
draft: false
---
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!