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.

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

smb shares and samba usermgmt is rudimentary implemented

nfs shares are now rudimentary implemented

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