The plan was small enough that I almost didn't bother sitting down for it: move Immich's photo storage off the external SSD hanging off the server and onto the NAS. One config change, one copy, done. Instead it turned into the most nervous hour I've had with this homelab so far — the kind where you're watching dd output and quietly hoping a drive comes back to life.
The actual goal
Immich has been storing everything on the Samsung T7 Shield mounted at /mnt/tmpnas. I wanted it on the NAS (/mnt/ugnas01-personal) so the photos sit on the big pool instead of a single bus-powered SSD. Before touching anything I wanted the full picture: what else was on that drive, and everything on the server still pointing at it.
Turned out the SSD only really held the Immich library (135 GB) plus two empty Samba shares. The things referencing it were the UPLOAD_LOCATION in Immich's .env, the bind mount into the immich_server container, the /etc/fstab entry, and those two smb.conf shares. The Postgres database was never on the SSD — it lives on the internal NVMe, which is exactly where Immich wants it. Good. Clean scope.
Where it went sideways
Started the copy to the NAS and the numbers were nonsense. Bulk writes to the NAS hit 190 MB/s no problem, but copying actual files crawled — single small files taking twenty, thirty seconds each. I burned a long time blaming the NAS: SMB mount options, file-create latency, even disk spin-down theories. Ran benchmark after benchmark.
The real answer showed up in a tar run that started spitting Input/output error on hundreds of files — and the errors were on the source, not the destination. Then the smoking gun: the SSD's mount flags had flipped to emergency_ro,shutdown. The ext4 filesystem had detected fatal I/O errors and taken itself offline. /dev/sdb was gone from the bus entirely.
That's the moment it stopped being a chore. The drive holding the only copy of my photo library had just dropped dead mid-operation, and every read was now returning an error.
It wasn't the drive
The saving grace: the T7 had re-enumerated on the USB bus as a new device (the device number kept ticking up — 005, 006, 007). That's not the signature of dead flash; that's a connection dropping and coming back. SMART confirmed it — overall health PASSED, 0% wear. fsck only needed to replay the journal; no corruption, all 121,599 files intact.
So this was the T7's old party trick again — the same USB instability under load I'd already fought once earlier this month. UAS is already disabled for it and autosuspend is off, so the remaining suspects were power, heat, or the cable. The fix was almost insultingly physical: stop Immich, unmount cleanly, swap to a different cable on a rear port, remount.
After that, the exact same copy that had been dying ran at a steady 107 MB/s and never flinched. All that "the NAS is slow" analysis had been the failing USB link the whole time.
Doing it properly the second time
With the drive stable, the rest went the way it should have the first time. Stopped Immich for a clean, consistent snapshot, rsynced the whole library across, and verified it file-for-file rather than trusting byte totals:
- library: 25,125 → 25,125
- thumbs: 49,341 → 49,341
- encoded-video, backups, upload, profile — all exact
Repointed UPLOAD_LOCATION to the NAS (with a backup of the .env), brought Immich back up, and watched it come up healthy with /data now resolving to the NAS share. Pinged the API — pong. By the time I checked, the library count had already ticked up past the migration number, which was oddly reassuring: it meant Immich was live and writing to the NAS, the new copy already the source of truth.
Then the cleanup, since I wanted to actually unplug the drive: deleted the now-stale SSD copy, pulled the two Samba shares pointing at it, removed the fstab entry, and unmounted. Wrapped it in a script with config backups and a testparm check so a bad edit couldn't take Samba down with it. The T7 is now fully decommissioned and free to repurpose.
What I'm sitting with
The migration is done and it's genuinely better — photos on the pool, drive freed, no dangling references. But the honest takeaway isn't the move, it's the reminder that my "backup" was a single bus-powered SSD on a flaky cable. For a stretch tonight that drive was my photo library, and it chose that moment to fall off the bus.
I deleted the SSD copy in the end — iCloud is the other copy — but the NAS pool has no redundancy, which means iCloud is now genuinely the only second copy. That's a thread to pull on soon: a real, redundant backup of the photos, not a hand-wave. Tonight ended fine. It came closer to not ending fine than I'd like.
And the T7 Shield is officially on notice. Healthy flash, lovely speeds, drops off the bus the second you ask it to work hard. Fine as scratch space; never again as the only home for anything I care about.