15 October 2026

📌 One in the morning, Solaris by The Ocean in the headphones (the CD arrived today, finally), and a sync that would not finish. The oldest piece of my homelab decided tonight was the night: ls on a folder full of films answered with Input/output error, and mount -a did nothing at all.

the oldest piece

Before Proxmox, before the containers, before the monitoring and the alerts, there was a Raspberry Pi 3 with a USB disk and Nextcloud on it. That was the whole homelab. The Pi became a 4, then a 5, the disk became two, and everything else grew around it - but that Nextcloud is still there, still on a Pi, still with two plain ext4 disks hanging off a USB hub, bind-mounted into the data folder. It is the most obsolete thing I run, and it works. So it stays, for now.

Tonight it reminded me why "for now" is the operative phrase.

what it looked like

The symptom was a folder that could not be read. The folder is a bind mount of a second disk, so the first guess was that disk. Then lsblk showed no USB disks at all. Not the one with the films, not the one with everything else. Only the SD card. And lsusb showed the Pi's own root hubs and nothing behind them - not the disks, not even the external hub.

dmesg was a wall of this:

usb 2-1: device descriptor read/8, error -110
usb usb2-port1: attempt power cycle
usb 1-1: device descriptor read/64, error -110
usb 1-1: USB disconnect, device number 2

Timeouts on both USB buses, the kernel power-cycling the ports and giving up. The ext4 warnings on the disk were just the consequence: the filesystem answering error -5 because there was no device under it any more. The Pi itself reported no undervoltage, so it wasn't the power supply.

A reboot brought everything back. Three and a half minutes later it was gone again, and this time the log told the whole story.

what it actually was

One of the disks had about thirty write commands queued and waiting for 35 seconds, and the UAS driver was aborting them one by one:

sd 1:0:0:0: [sdb] tag#28 uas_eh_abort_handler 0 uas-tag 16 inflight: CMD OUT
...
scsi host1: uas_eh_device_reset_handler FAILED to get lock err -19
device offline error, dev sda, sector 0 op 0x1:(WRITE)
EXT4-fs (sda1): shut down requested (2)
Aborting journal on device sda1-8.

The writes were coming from Apache: a Nextcloud sync uploading a file. The disk stopped answering, the driver tried to reset it, the reset took the whole hub down with it, and the other disk - idle, not writing anything - went offline too. Both journals aborted. The file being uploaded was marked potential data loss and is gone.

The boot log had the last piece. The two enclosures are JMicron bridges (152d:0580 and 152d:a580), both running in UAS mode behind a Genesys Logic USB 3 hub. JMicron plus UAS on a Raspberry Pi is a known bad combination: under sustained writes the bridge times out, and what should be one disk's problem becomes everybody's problem.

the fix

Tell the kernel to stop using UAS for those two bridges and fall back to plain usb-storage. One parameter at the end of /boot/firmware/cmdline.txt, after a backup of the file:

usb-storage.quirks=152d:0580:u,152d:a580:u

After the reboot:

usb 2-1.1: UAS is ignored for this device, using usb-storage instead
usb-storage 2-1.1:1.0: Quirks match for vid 152d pid 0580: 800000
usb 2-1.2: UAS is ignored for this device, using usb-storage instead
usb-storage 2-1.2:1.0: Quirks match for vid 152d pid a580: 800000

Then Apache stopped, both disks unmounted (after I remembered that a shell sitting inside the mount point counts as "target is busy"), and a forced fsck on each. Both came back clean - the journals had already been replayed at mount time and nothing was structurally wrong. Mount, start Apache, run the sync again.

The sync that had killed it finished. The next one, the whole music folder, is running as I write this, and dmesg has not moved since boot.

what I'm not fixing

usb-storage is slower than UAS. On a Pi serving one person's files it does not matter.

The hub is still the single point of failure: a reset on one port took both disks down, and that will not change with a kernel parameter. The enclosures also run with write cache enabled and no FUA, so the next hot disconnect, if there is one, will lose whatever was sitting in the drive's cache. A better powered hub is the cheapest improvement I could make. Moving Nextcloud onto Proxmox with the rest of the lab is the proper one.

I'm doing neither tonight. It is the first thing I built, it has survived three Pis, and it works. For now.