dumpstore — a lightweight ZFS NAS management UI (Go, single binary, no containers)

[langerma]

I have to be upfront: I'm not a developer. I'm an ops/observability engineer who knows how to use software to get things done. I know a bit of Go — not much — and I have no formal background in software design. What I do know is what I need, and what was missing. So I built it. Take the code with that in mind.

 

The problem

 

I run a Kobol Helios64 as my home NAS — a five-bay ARM board that's been sitting in a sweet spot between "serious hardware" and "abandoned by its software ecosystem." I tried the usual NAS UIs. They were either too heavy, too opinionated about owning the underlying OS, or simply unmaintained. None of them gave me a clean window into my ZFS pools without dragging in a container runtime, a Node.js server, or a Python daemon alongside them.

I wanted something simple: observe and manage my storage from a browser, on a machine that stays close to a vanilla Armbian or FreeBSD install. No agents, no frameworks, no surprises.

 

What I built

 

dumpstore — a lightweight ZFS management UI written in Go. link: https://github.com/langerma/dumpstore

 

It's a single compiled binary with a bunge of html/js/css/ansible playbooks. No database. No Node. No container runtime.

 

Ansible handles writes (dataset creation, snapshots, user/group management, ACLs)

 

Current features:

• Pool overview — health, usage, vdev tree, fragmentation
• Live I/O statistics per pool (SSE-pushed, no polling)
• S.M.A.R.T. data per disk — temperature, power-on hours, reallocated sectors
• Dataset browser — collapsible tree, compression, quota, mountpoint
• Dataset create / edit / delete
• Snapshot management — list, create (recursive), delete
• User & group management — create, edit, delete; system users protected
• ACL management — POSIX and NFSv4, recursive apply supported
• Prometheus /metrics endpoint (because of course)
• Runs on Linux (systemd) and FreeBSD (rc.d)
• Builds with make build && sudo make install — that's it

 

What it is not: a full TrueNAS replacement.

 

SMB/NFS share management, a file browser, and ZFS send/receive are on the roadmap — but I'm building deliberately, one thing at a time.

 

Why Armbian specifically

The Helios64 is the reason this exists. If you're running Armbian on a Helios64, an older ARM server, or any ZFS box where you care about what's actually installed — this was built for you.

 

Feedback welcome

Since I'm not a developer by trade, I'm sure there are things I've done in a way that makes experienced Go or software folks cringe.

Issues, PRs, and honest feedback are very welcome.

 

The code is small enough to be auditable — main.go plus a handful of internal packages.

 

Markus Langer

 

 

 

[langerma]

nfs shares are now rudimentary implemented

[langerma]

smb shares and samba usermgmt is rudimentary implemented

[langerma]

i also added a hp now: https://langerma.github.io/dumpstore/ 

[langerma]

a few things happened since sunday:

 

i set up a project homepage: https://langerma.github.io/dumpstore/ - screenshots, feature overview, install instructions.

and a wiki of course: https://github.com/langerma/dumpstore/wiki

 

three new things landed since the initial post:

• live ansible task streaming the op-log dialog now shows tasks appearing one by one as ansible runs them, instead of dumping everything at once when the playbook finishes. small thing, but makes it feel a lot more responsive.
• pool scrub scheduling you can now add/remove pools from the periodic scrub schedule directly from the ui. on linux it edits ZFS_SCRUB_POOLS in /etc/default/zfs (zfsutils-linux), on freebsd it manages daily_scrub_zfs_pools  in /etc/periodic.conf. platform-aware, same interface.
• schema-driven ui all zfs property dropdowns (compression, atime, recordsize, etc.) and the shell picker for users are now driven by a single schema definition in the backend. GET /api/schema returns the full list filtered by platform. before this, the values were hardcoded in four different places — html, js, and go. adding a new property now means touching one file.

 

nothing groundbreaking, just steady progress.