RPi RAID NAS – Quick and Dirty

I had an old NAS lying around, but it no longer supported safe Microsoft network protocols.

My old LG NAS had served me reasonably well, but recent Linux distributions finally drew a hard line: SMBv1 is blacklisted. For good reason, it’s a security nightmare. I could have re-enabled it, but honestly… why bother? A Raspberry Pi 5 was sitting on my desk, and I thought: Sure – why not.

Now, let’s be realistic. A Raspberry Pi, even a Pi 5, is not exactly a data-shuffling powerhouse. So the heavy lifting, specifically RAID mirroring, needed to happen elsewhere. Fortunately, there are hard drive enclosures that do exactly what I wanted: you plug in a couple of disks, and the enclosure presents itself as a single device over USB 3. Simple and transparent.

The enclosure I bought has four bays: the top two drives are configured as a RAID-1 array, while the third and fourth disks operate independently, with the third drive designated as the Raspberry Pi OS boot drive.

I ordered one from Amazon, and it arrived two days later. Out of curiosity, I first connected it to my PC. It mostly worked – but not without issues:

usb 2-7.2: USB disconnect, device number 3
2026-01-10T14:49:32.997890-07:00 elara kernel: sd 7:0:0:0: [sdl] tag#0 FAILED Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK cmd_age=0s
2026-01-10T14:49:32.997891-07:00 elara kernel: sd 7:0:0:0: [sdl] tag#0 CDB: Write(10) 2a 00 02 80 cd 00 00 04 00 00
2026-01-10T14:49:32.997891-07:00 elara kernel: I/O error, dev sdl, sector 41995520 op 0x1:(WRITE) flags 0x0 phys_seg 128 prio class 2
2026-01-10T14:49:32.997892-07:00 elara kernel: sd 7:0:0:0: [sdl] tag#2 FAILED Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK cmd_age=0s

More on that later. My PC has had USB problems for a while. It occasionally even loses the keyboard. Maybe one day I’ll have the time and money for a new main board. For now, the plan was to attach the enclosure to the Raspberry Pi anyway.

First obstacle: I had forgotten the Raspberry Pi’s password. That required some SD-card surgery to reset it, but once that was sorted out, I connected the RAID enclosure. The Pi recognized the disks immediately.

I didn’t feel like setting up SMB or NFS, so I went with a quick-and-dirty solution: SSHFS. It worked perfectly.

Next step: booting the Raspberry Pi directly from the RAID.

I grabbed rpi-clone from GitHub, and within minutes the Pi was booting from the array, well – almost. The boot process stalled with complaints about a missing UID. It turned out that rpi-clone hadn’t updated the kernel command line correctly.

The issue was the PARTUUID. These identifiers, used in both fstab and cmdline.txt, depend on whether the disk uses a GUID or MBR partition table, which in turn depends on disk size. In my case, the fix was simple: ask fdisk for the correct PARTUUID, update cmdline.txt, reboot and the Pi came up cleanly.

However, USB trouble wasn’t done with me yet. The Pi started throwing errors like these:

kernel: sd 0:0:0:0: [sda] tag#10 uas_eh_abort_handler 0 uas-tag 10 inflight: CMD OUT 
2026-01-10T22:56:06.383395+00:00 raspberrypi kernel: sd 0:0:0:0: [sda] tag#10 CDB: opcode=0x2a 2a 00 10 00 b1 00 00 04 00 00
2026-01-10T22:56:06.383405+00:00 raspberrypi kernel: sd 0:0:0:0: [sda] tag#9 uas_eh_abort_handler 0 uas-tag 11 inflight: CMD OUT 
2026-01-10T22:56:06.383411+00:00 raspberrypi kernel: sd 0:0:0:0: [sda] tag#9 CDB: opcode=0x2a 2a 00 10 00 b5 00 00 04 00 00

That’s… not great.

Luckily, this is a well-known problem. USB Attached SCSI (UAS) is fast, but notoriously fragile with certain USB-to-SATA bridges. The solution many people recommend is simply disabling UAS.

First, find the USB vendor and product IDs:

lsusb -t

Then add the following to cmdline.txt:

usb-storage.quirks=XXXX:YYYY:u

Reboot and UAS is disabled.

Yes, this costs a bit of performance. But the errors stopped completely, which is a trade-off I’m happy to make for a NAS.

At this point, my Raspberry Pi RAID NAS has been humming along nicely. The enclosure is (hopefully) dumb enough not to phone home to Shenzhen, and everything else runs cleanly on the Pi.

Quick, dirty, effective.