TrueNAS, Proxmox, And The Photography Workflow

Photography

Archive note, September 2025: This post is based on SweedestMoments infrastructure notes for photography storage and workflow planning.

Photography infrastructure has a different center of gravity than a normal website.

The website matters. The portfolio matters. Client galleries matter. But the irreplaceable asset is the photo archive: RAW files, edited masters, exports, catalogs, and the folder structure that makes years of work navigable.

That is why the SweedestMoments architecture put local storage at the center.

Local Storage Was The Right Problem

The local stack used Proxmox with a TrueNAS VM and a ZFS pool built from three 4 TB drives. The goal was not public hosting. The goal was reliable internal storage for large creative files.

That distinction shaped the architecture.

The local environment was appropriate for:

  • RAW photo storage.
  • Edited masters.
  • Lightroom catalogs.
  • Internal file management.
  • Backup destination.
  • Development and testing.

It was not appropriate as the public client-facing platform. Limited external connectivity and the nature of the workload made that clear.

The right architecture was hybrid: local for heavy storage and internal operations, cloud or SaaS for public client-facing surfaces.

USB Storage Had To Be Tamed

The TrueNAS build had a very practical hardware problem.

The USB drive enclosure initially caused boot freezes and instability. The likely culprits were UAS driver behavior and USB autosuspend. The fix was not theoretical architecture. It was system administration:

  • Disable UAS and use usb-storage.
  • Disable USB autosuspend.
  • Verify drive enumeration by stable device IDs.
  • Pass raw disks through to the TrueNAS VM.

After that, the drives were consistently detected and the ZFS pool could be managed normally.

That is the kind of work that makes a home lab feel less like a toy and more like infrastructure.

ZFS For Creative Work

The storage layout used RAIDZ1 across three 4 TB drives, giving roughly 7.5 TB usable with one-disk fault tolerance.

The important settings reflected the workload:

  • lz4 compression.
  • Large record size for media files.
  • atime disabled.
  • Scrubs.
  • SMART tests.
  • Snapshots.
  • SMB access for macOS workflows.

None of that makes the archive immortal. It does make it more disciplined than a pile of external drives with unclear history.

Public Tools Belong Elsewhere

The broader photography-business architecture separated internal storage from public tools.

Client galleries, booking, contracts, invoicing, CRM, and the portfolio all have different access requirements than the master archive. Some can be SaaS. Some can be cloud-hosted. Some could be self-hosted behind a VPN if convenience and security line up.

The key is not forcing everything into one machine just because the machine exists.

Local storage is excellent for large files and control. Public client workflows need reachability, SSL, uptime, and lower friction.

The Lesson

The project began with hardware and storage, but the real lesson was architectural separation.

Keep the originals close, durable, and under control. Put public-facing workflows where clients can actually reach them. Use the home lab where it is strongest, not where it creates unnecessary exposure.

That is a mature outcome for a project that started with drives, a hypervisor, and the practical need to stop treating photography storage as an afterthought.