A step-by-step build log for developers who'd rather understand every layer of their storage stack than trust a vendor's black box.
Most home NAS reviews start from the assumption that you want the easiest possible setup. Fair enough, for most people. But there's a specific kind of user — the one who reads a chkdsk log for fun, the one who still has a drawer full of bare SATA drives "just in case" — for whom the closed appliance is the problem, not the solution. This build is for that person.
The goal is simple to state and mildly fiddly to execute: take a Raspberry Pi 5, add a SATA HAT that exposes multiple drive bays over the board's new PCIe lane, and end up with a fully self-managed file server on the local network. No proprietary dashboard, no forced firmware updates, no subscription tier hiding behind a "cloud backup" button.
Parts and prerequisites
The bill of materials is short. A Raspberry Pi 5 — 2GB or 4GB is plenty, since smbd is not a memory-hungry process — a compatible SATA HAT with two to five bays, a microSD card for the OS, an Ethernet cable, and whatever bare SATA drives you already own. The one component that deserves real attention is the power supply. Underestimate it and the board brownouts under load. Every SATA HAT vendor publishes a minimum wattage figure. Respect it, especially with mechanical drives, which draw a real current spike on spin-up.
Flashing the OS
Raspberry Pi Imager handles this part. Choose Raspberry Pi OS Lite (64-bit) — no desktop environment, smaller footprint, one less thing to patch. In the advanced options menu, set the hostname, the user credentials, and enable SSH before writing the image. Do this now and you never need a monitor for this board. Ever.
Physical assembly
The Pi 5 exposes its PCIe interface through the GPIO header, and that's where the HAT connects — usually via a flat FPC ribbon cable that always looks longer than it needs to be. Power everything down before touching any connector. Align the ribbon into its slot, lift the small locking tab, seat the cable, close the tab. It shouldn't require force. If it does, you're inserting it wrong side up.
Mount the HAT on the standoffs, connect each SATA drive's data and power leads one at a time, and label the drives as you go — a strip of tape and a marker, nothing fancy. You'll thank yourself later when lsblk returns five identical-looking device names.
First boot and disk discovery
SD card in, Ethernet connected, power applied. Give it a couple of minutes on first boot — it's doing filesystem expansion in the background. Then connect over SSH from another machine on the network:
ssh username@hostname.local
Once in, lsblk lists every block device the kernel can see. Count the drives. If the number matches what you physically connected, the HAT is talking to the board correctly — that's the real milestone here, more than the SSH login itself.
Two philosophies, one decision
You have a choice to make before formatting anything. Independent disks, mounted and shared separately — call it artisanal JBOD — or a software RAID array via mdadm, merging drives into one logical volume.
I default to independent disks for mixed hardware. If your drives are a pile of mismatched 1TB units bought across a decade, forcing them into a RAID array adds complexity without much upside. RAID 0 loses everything if one member fails. RAID 1 halves your usable capacity. Independent mounts fail one disk at a time, which — for a home archive, not a production database — is usually the outcome you actually want.
Formatting and mounting
Format each target drive — mkfs.ext4 /dev/sdb1, substituting the correct device — and double-check the device letter before running it. This command erases everything on the target. It's not a warning I'm adding for compliance reasons; I've watched someone format the wrong drive because they trusted a device name that had shifted after a reboot. Use blkid to get the UUID instead, and reference that — not sdb — in /etc/fstab, so the mount survives a reboot even if the kernel reorders the devices.
Samba, and why it's still the right tool
Install samba and samba-common-bin, then edit /etc/samba/smb.conf to define a share block per disk — path, browseable, writable, valid users. Set a Samba-specific password with smbpasswd -a; it's separate from the system login, and forgetting that step is the single most common reason a share prompts for credentials and then rejects them anyway.
Restart the service. That's it. No app store, no account creation screen, no telemetry opt-out to hunt for in a settings menu three levels deep.
A static IP, and the point of the whole exercise
Edit /etc/dhcpcd.conf to assign a fixed address on eth0. This is the step that actually delivers on the original brief — a disk with its own IP, reachable from any device on the network without depending on router-side USB sharing, which in my experience is unreliable often enough to be a real annoyance rather than a theoretical one.
When it doesn't work the first time
It usually doesn't, and that's fine. A drive missing from lsblk is almost always the power lead, not the data cable — check that one first. Samba prompting and then rejecting a password nearly always traces back to a missing smbpasswd step. A board that reboots under load is an underpowered supply, not a faulty HAT. None of these are exotic failures. They're the same five things, in a different order, every time.
Scope and requirements
This build assumes a single Pi 5 acting as a file server on a trusted local network — it is not, out of the box, hardened for exposure to the open internet, and that's a deliberate omission rather than an oversight. Whether the same approach scales cleanly to a multi-user office environment with concurrent write-heavy access is a separate question, and one this build doesn't try to answer.
The setup described here requires Raspberry Pi OS Lite (64-bit), a Pi 5 board specifically — the PCIe lane most SATA HATs rely on isn't available on earlier models — and a SATA HAT rated for the number of drives you intend to connect simultaneously.
