My NixOS-based Ugreen NAS

2026-04-01T00:00:00+00:00

I've been using NixOS for about two years now. Started in a VM just to play around, and these days I run it everywhere. So when I ordered the NAS, the OS question was settled before the box even arrived. But before I started, I did some digging. I couldn't find anything about a NixOS-based NAS. Not on the Discourse forum, not on GitHub, nowhere. Which only made me more eager to find out whether it could really work the way I wanted. So I ordered the Ugreen DXP4800 Plus with a few intentions in mind. On the one hand, ending up with a stable, open source, reproducible NAS that lives in Git and runs in production. On the other, getting to know NixOS even better in yet another use case — treating it as a learning and testing project along the way. The pre-installed OS from Ugreen (UGOS) is fine, but I want full control. No proprietary OS, no clicking through web UIs, no mysterious background services. And above all: no forced account creation and no shady telemetry. Just NixOS, where every file, every NFS export, every kernel module lives in config files I can read, version, and rebuild from scratch.

Here's some of what came out of that journey. This post covers both the software and the hardware.

The Hardware

The DXP4800 Plus is a 4-bay x86 NAS with an Intel Pentium Gold 8505 (5C/6T), 8 GB DDR5, two internal NVMe slots, an extra internal SSD slot, and 2.5GbE plus an unused 10GbE port. I liked this NAS not only for its clean, modern look, but also for the upgrade options — the RAM situation in particular won me over. Upgrading the hardware is genuinely easy. Unlike my experience with the QNAP TS-253E-8G I had before, the Ugreen is a joy to work on. Loosen one screw on the bottom panel and you're in. RAM and SSDs are right there. Here's what I have in mine:

2× Patriot P300 128GB NVMe → mdadm RAID1, ext4, this is where NixOS lives
3× Seagate IronWolf 8TB → mdadm RAID5, btrfs+zstd:1, ~14.55 TiB usable on /data
Bay 4 free for later

So one of the three HDDs holding the data can fail (RAID5 lets the missing data be reconstructed from the other two), and so can one of the two SSDs holding the OS, since they're mirrored. The internal SSD is always shipped with UGOS and is, for the moment, almost completely untouched. More on why in a bit.

The underside of the NAS, where the hardware upgrades happen. Photo: techreviewer.de

Disko and the RAID Layout

Disko is a tool that lets you partition the entire system declaratively. Basically: "Write into this file how the partitioning should look, and so it shall be." For this we can look at the following two files. The mdadm we'll bump into more often is a Linux tool (multiple device administrator), which we'll use to create, manage, and monitor our RAIDs.

The whole partitioning lives in disko-config.nix. I'll split it into two parts to make it easier to walk through. Part 1:

mdadm = {
  # NVMe RAID1 Mirror → NixOS root (ext4)
  nixos = {
    type = "mdadm";
    level = 1;
    metadata = "1.2";
    content = {
      type = "filesystem";
      format = "ext4";
      mountpoint = "/";
    };
  };

In this snippet I'm saying: take the two NVMe partitions (defined further up in disko-config.nix) and build an mdadm RAID1 array called nixos, format it as ext4, mount it at /. Disko creates the array, the filesystem, and the mountpoint completely automatically at install time — no manual mdadm --create, mkfs.ext4, or /etc/fstab fiddling needed.

Part 2:

  # HDD RAID5 Array → Data (btrfs with compression)
  data = {
    type = "mdadm";
    level = 5;
    metadata = "1.2";
    content = {
      type = "filesystem";
      format = "btrfs";
      mountpoint = "/data";
      mountOptions = [ "defaults" "noatime" "compress=zstd:1" "commit=3600" ];
    };
  };
};

In Disko-speak it reads like this: three drives, RAID level 5, btrfs as the filesystem, mountpoint /data. The mount options carry most of the tuning — noatime suppresses access-time updates that would otherwise turn every read into an extra metadata write, compress=zstd:1 is the cheapest compression level, and commit=3600 raises the btrfs metadata commit interval from the default 30s to 3600s. Data writes themselves still go through the normal write path and stay consistent thanks to btrfs's copy-on-write. The trade: in a power loss without sync, up to the last 60 minutes of metadata updates are gone (filename changes, new snapshots, etc.) — the data files themselves stay uncorrupted. On a home NAS without a UPS, a deliberately accepted trade against write load on the HDDs.

The Boot Madness

The DXP4800 Plus has one downside that cost me some time. The BIOS only treats the factory NVMe slot (where UGOS lives) as bootable. My two Patriot SSDs are invisible in the boot menu. So: the bootloader has to stay on the UGOS SSD's ESP, even though everything else runs from the Patriots.

Quick refresher in case you're not deep in UEFI land: the ESP (EFI System Partition) is the small FAT32 partition where the bootloader lives. At startup, the firmware reads the ESP, finds the systemd-boot entry there, and starts the kernel through it. No reachable ESP, no boot menu, no kernel, nothing. And above all: no NixOS.

Solution: NixOS' primary ESP sits on Patriot #1, and on every nixos-rebuild /boot gets synced to two more places — the backup ESP on Patriot #2 (so the system still boots if one NVMe dies) and the UGOS SSD's ESP (which is where the BIOS actually looks). The UGOS one is the only one that ever actually gets booted from — the other two are insurance policies for the case where I eventually pull the UGOS SSD or it dies.

Now to the code snippet. What this snippet does is automatically write a copy of the bootloader to the two other ESPs after every nixos-rebuild. That's necessary because NixOS only updates the primary ESP on its own — my two backup ESPs would get more outdated with every update and end up booting an old, broken state if I ever needed them.

This goes through the NixOS hook boot.loader.systemd-boot.extraInstallCommands, into which you can drop a small shell script. Mine mounts the backup ESP and the UGOS ESP one after the other, copies /boot over with rsync, and unmounts again. For the UGOS part I also briefly have to drop the read-only flag with blockdev --setrw (otherwise nothing can be written), and re-enable it right after with --setro.

Here's the code:

boot.loader.systemd-boot.extraInstallCommands = ''
  # Sync to backup ESP (Patriot P300 #2)
  DEVICE="/dev/disk/by-id/nvme-Patriot_M.2_P300_128GB_P300LCBA2508221720"
  BACKUP_PART="''${DEVICE}-part1"
  mkdir -p /boot-backup
  mount "$BACKUP_PART" /boot-backup || true
  rsync -a --delete /boot/ /boot-backup/ || true
  umount /boot-backup 2>/dev/null || true

  # Sync to UGOS ESP (BIOS boots from here)
  UGOS_DEV=$(readlink -f /dev/disk/by-id/nvme-YSO128GTLCW-...)
  if [ -n "$UGOS_DEV" ]; then
    blockdev --setrw "''${UGOS_DEV}" || true
    blockdev --setrw "''${UGOS_DEV}p1" || true
    mkdir -p /boot-ugos
    mount -o rw "''${UGOS_DEV}p1" /boot-ugos || true
    rsync -a --delete --exclude='EFI/debian' --exclude='boot' /boot/ /boot-ugos/
    umount /boot-ugos
    blockdev --setro "''${UGOS_DEV}p1" || true
    blockdev --setro "''${UGOS_DEV}" || true
  fi
'';

(I shortened the absolute store paths to keep this readable — the real script has ${pkgs.rsync}/bin/rsync and so on.)

The two blockdev --setrw / --setro rounds around the UGOS mount are necessary because the SSD is otherwise pinned read-only — we'll get to that.

NFS — Shares for Backups, Home Theater, and Staging

The NAS is supposed to expose three network shares: first, as a backup target for my Proxmox cluster; second, as a media source for Jellyfin (my home theater setup, which runs on a separate server); and third, as a staging area also used by the Jellyfin server.

These three use cases all have completely different requirements, so each one gets its own mountpoint with its own permissions. As the protocol I'm using NFS — it's the standard in Linux land, every client can speak it without extra software, and performance over LAN is more than enough. Specifically I'm using NFSv4 instead of v3, because v4 handles everything over a single TCP port (2049). With v3 you had to assign fixed ports to rpc.mountd, rpc.statd, and lockd individually and open all of them in the firewall — more fiddling that v4 saves you.

In NixOS, the NFS server is set up via services.nfs.server. The exports strings are one-to-one the same content that would go into /etc/exports on a classic distro — NixOS just renders the file from this:

services.nfs.server = {
  enable = true;
  exports = ''
    /data/backup   192.168.60.0/24(rw,sync,no_subtree_check,no_root_squash)
    /data/media    192.168.60.0/24(ro,sync,no_subtree_check,root_squash) 192.168.50.0/24(ro,sync,no_subtree_check,root_squash)
    /data/incoming 192.168.60.27(rw,sync,no_subtree_check,no_root_squash)
  '';
};

Each line follows the pattern <path> <client>(<options>). Quick rundown of what the options do:

rw / ro — write or read access
sync — server only acknowledges writes once they're actually on disk (safer than async, but slower; for backups that's exactly what I want)
no_subtree_check — disables an old consistency check that today only causes problems and costs performance
root_squash / no_root_squash — decides whether a root user on the client is also treated as root on the NAS, or gets mapped to the unprivileged user "nobody"

The split hangs entirely on that last point. Proxmox writes its VM and LXC backups as root, so /data/backup absolutely needs no_root_squash and rw — otherwise the backups end up on the NAS as "nobody" and Proxmox bails out with permission errors on the next run. Restricted to the LAN subnet (192.168.60.0/24).

/data/media is read-only and shared with two subnets at once — the LAN and the VLAN where the Jellyfin server hangs. root_squash is fine here since it's read-only anyway; it's the safe default.

/data/incoming is the trickiest path because it gets written to with root privileges (no_root_squash + rw). To make sure not just any client on the LAN can do damage, the share is restricted to a single IP: 192.168.60.27, my media server. No other host can mount it in the first place.

Besides SSH, that means the firewall only has port 2049 (TCP+UDP) open — that's all NFSv4 needs.

SMART, Scrubs, and Not Losing It When a Drive Dies

Hard drives die. The question isn't if, but when. Usually exactly when you don't expect it or really can't deal with it. You can't prevent that, but you can prepare. For exactly that there are two independent mechanisms I have running: SMART monitoring on the drive level and btrfs scrubs on the filesystem level.

SMART (Self-Monitoring, Analysis and Reporting Technology) is built into every halfway modern drive. The drive itself counts how many read errors have occurred, how hot it's getting, how many sectors had to be remapped, how many hours it's been running. But just having those values isn't enough — you have to read them regularly, compare them over time, and raise an alarm when something looks off. Basically the standard built-in monitoring for HDDs. And that's exactly what smartd, the daemon from the smartmontools package, does. In NixOS it's enabled via services.smartd:

services.smartd = {
  enable = true;
  autodetect = true;
  notifications.mail.enable = false;
  defaults.monitored = "-a -o on -S on -n standby,q -s (S/../.././13|L/../../7/13) -W 4,45,55";
};

autodetect = true makes sure smartd finds all attached drives automatically, so I don't have to list them one by one. More interesting is defaults.monitored — that's the default option set smartd applies to every drive. What the flags do, individually:

-a — monitor everything SMART has to offer (health status, attributes, self-test logs, error logs)
-o on / -S on — automatic offline data collection and attribute saving enabled; the drive happily collects its own values in the background
-n standby,q — if a drive is currently sleeping, don't wake it up just to check on it (q = quiet, so no log spam over skipped checks). That matters because the spindown timer from the previous section would otherwise be pointless and the drives would never go to sleep.
-s (S/../.././13|L/../../7/13) — schedule for self-tests: a short test every day at 1 PM (S for Short), a long one every Sunday at 1 PM (L for Long). The times are deliberately not at night, because between 02 and 04 AM my Proxmox Backup Server (PBS) writes its VM snapshots to the NAS — a long test running in parallel would double the drive load and push backup duration into uncomfortable territory.
-W 4,45,55 — temperature monitoring: log every 4°C of change, warn at 45°C, critical at 55°C. IronWolf drives are spec'd up to ~65°C, so 55°C is still in the green zone, but the point at which I want to check on what's going on

But that only covers what the drive itself notices. There's a second class of errors SMART is blind to: silent bitrot. That's when a single bit flips on an otherwise healthy drive — through magnetic drift over the years, marginal sectors, imprecise write heads, or rarely some electronic interference. (Cosmic rays often get cited in this context, but they're practically irrelevant for magnetic storage — that argument applies to DRAM, and that's what ECC RAM is for.) The drive registered no read or write error, SMART says everything's green, but the file sitting there is corrupt anyway. With 14 TiB of storage that's not a theoretical worry.

Exactly against that, btrfs maintains checksums for every block. For that to actually protect anything, the blocks have to be regularly read and verified against their checksum — otherwise nobody notices a thing until you happen to open the broken file. That process is called a scrub, and in NixOS I enable it with three lines:

services.btrfs.autoScrub = {
  enable = true;
  interval = "monthly";
  fileSystems = [ "/data" ];
};

That's it — once a month a systemd timer kicks off and reads and verifies every single block on /data. Wherever a checksum doesn't match, btrfs repairs the block automatically — possible in my case because the underlying mdadm RAID5 has parity data from which the correct version can be reconstructed. At 14 TiB a scrub takes a few hours, runs in the background with low I/O priority, and doesn't get in the way during normal use.

The two mechanisms complement each other: SMART warns me when a drive is about to die (slowly rising read error rates, climbing reallocated sector counts, temperature anomalies). The btrfs scrub catches the errors that fly under the SMART radar. Together I'll know with reasonably high probability before "one drive's acting up" turns into "one drive is dead and is taking data with it".

The HDD Spindown Bug I Had for Weeks

Now for the slightly embarrassing part. I had hdparm spindown configured forever. Only after experimenting back and forth and digging into why my drives were constantly spinning did I get it: I'd set it via powerUpCommands, and that only runs after resume-from-suspend. Servers don't suspend. Meaning: the setting was simply never active.

The fix is a oneshot systemd service that runs at boot:

systemd.services.hdd-power-management = {
  description = "Set HDD spindown timer and acoustic management";
  wantedBy = [ "multi-user.target" ];
  after = [ "systemd-udev-settle.service" ];
  serviceConfig = {
    Type = "oneshot";
    RemainAfterExit = true;
  };
  script = ''
    hdparm -S 240 /dev/sda /dev/sdb /dev/sdc || true
  '';
};

-S 240 sends the drives into spindown after 20 minutes of idle (the unit for this hdparm flag is 5 seconds, so 240 × 5 = 1200s = 20min). There's deliberately no acoustic management command here — Seagate IronWolf drives don't support AAM (the feature was dropped in ATA-8, and NAS/enterprise drives have been silently ignoring the command for years). Earlier versions of my config still had hdparm -M 128, until I verified with hdparm -I that the drives report "AAM not supported" — so the effect was nil.

Fan Control: The Biggest Pain Point

I spent a weekend on this one.

The rear system fan and the removable dust filter. Photo: techreviewer.de

The DXP4800 Plus uses an ITE IT8613E Super-I/O chip for fan control. The mainline kernel ships an it87 module, but the auto-detection for the IT8613E isn't included there — without a force ID, the driver simply doesn't find the chip. The community module from frankcrawford/it87 on GitHub collects patches for exactly these chip variants and is the de-facto standard solution in the lm-sensors community for ITE chips without mainline support. To make the driver load cleanly on this specific hardware, you need three workarounds that all have to play together:

ACPI reserves the I/O ports the driver needs (0x0a00-0x0a3f) and won't release them. With the kernel parameter acpi_enforce_resources=lax you tell the kernel to chill out a bit on this one.
The chip ID has to be passed to the module at load time via force_id. Here's where it gets interesting: originally I used force_id=0x8613 (the actual chip ID), and that worked fine across multiple kernel versions. With kernel 6.12.90 the detection path for IT8613E silently broke — the module loads, but modprobe just returns "No such device", no useful error message. The solution is in frankcrawford/it87 Issue #46: force 0x8622 (IT8622E) instead. The IT8622E is hardware-equivalent enough that all the relevant PWM and temperature registers respond identically — the driver just thinks it's a different chip and takes a detection path that isn't affected by the regression. A working hack, no custom patch required.
At the driver level there's still an ACPI conflict on top of that. ignore_resource_conflict=1 ignores it.

Here's the config:

boot.kernelParams = [ "acpi_enforce_resources=lax" ];

boot.extraModulePackages = [
  (config.boot.kernelPackages.callPackage ({ stdenv, fetchFromGitHub, kernel }:
    stdenv.mkDerivation {
      pname = "it87";
      src = fetchFromGitHub {
        owner = "frankcrawford";
        repo = "it87";
        rev = "master";
        sha256 = "sha256-iWyOctK+TFhVCOw2LiV4NiNFEAqNXOpSdGY//VwO8Ko=";
      };
      nativeBuildInputs = kernel.moduleBuildDependencies;
      # ...
    }) {})
];

boot.extraModprobeConfig = ''
  options it87 force_id=0x8622 ignore_resource_conflict=1
'';

boot.kernelModules = [ "it87" ];

This builds it87.ko fresh from GitHub against the running kernel. On every kernel update it gets rebuilt automatically — and that's exactly the reason you do it this way instead of just dumping a binary somewhere.

Once the module is up, there's still a fun bug. In pure auto mode, the chip stops the rear system fan as soon as the CPU drops below a certain threshold. The CPU then heats up by 1-2°C without airflow, the chip starts the fan again, ten seconds later it stops it again. You can hear it ramping up and down the whole time. Fan gets loud, fan gets quiet, fan gets loud, fan gets quiet. In an endless loop. Drives you nuts.

So I've since moved to a temperature-triggered hysteresis solution (see the update block at the end). Originally it was a simpler variant: pwm2 (HDD cage fan) stayed in auto mode, pwm3 (rear) got a fixed manual value. PWM 50 out of 255 was plenty for cooling and pleasantly quiet:

script = ''
  for attempt in $(seq 1 10); do
    for hwmon in /sys/class/hwmon/hwmon*; do
      if [ "$(cat $hwmon/name 2>/dev/null)" = "it8622" ]; then
        echo 2  > $hwmon/pwm2_enable   # auto
        echo 1  > $hwmon/pwm3_enable   # manual
        echo 50 > $hwmon/pwm3
        echo 2  > $hwmon/pwm4_enable
        echo 2  > $hwmon/pwm5_enable
        exit 0
      fi
    done
    sleep 1
  done
  exit 1
'';

The retry loop is in there because the hwmon device doesn't always show up immediately after the module loads. Up to 10 attempts at one-second intervals. Belt and suspenders, you know how it goes.

UGOS Protection

As we now know, the DXP4800 Plus ships with a fixed 128GB SSD pre-loaded with UGOS (UgreenOS). I want to leave it untouched for two reasons:

Warranty. If I ever have to send the device in, I don't want to be the guy explaining why the factory OS is gone.
Resale. Restoring the original state if I ever sell the NAS is then just a change in the BIOS boot order.

So under no circumstances should this SSD get written to. At the same time I don't want to have to hit the boot menu every reboot and pick NixOS. For that there are four independent layers:

disko-config.nix doesn't list it. Disko can't touch what it doesn't know about.
A udev rule matches the device by its serial number and sets it read-only at the block level the moment it's detected.
A systemd oneshot sets the read-only flag again at every boot, in case something races with udev.
No fstab entries. Nothing tries to mount it.

So I effectively have four layers protecting the UgreenOS install. Here's the snippet:

services.udev.extraRules = ''
  ACTION=="add|change", SUBSYSTEM=="block", \
    ENV{ID_SERIAL}=="YSO128GTLCW-E3C-2_511250701135025164", \
    RUN+="${pkgs.util-linux}/bin/blockdev --setro /dev/%k"
'';

systemd.services.ugos-protect = {
  wantedBy = [ "multi-user.target" ];
  after = [ "systemd-udev-settle.service" ];
  serviceConfig = { Type = "oneshot"; RemainAfterExit = true; };
  script = ''
    UGOS="/dev/disk/by-id/nvme-YSO128GTLCW-E3C-2_511250701135025164"
    if [ -e "$UGOS" ]; then
      DEV=$(readlink -f "$UGOS")
      blockdev --setro "$DEV" 2>/dev/null || true
    fi
  '';
};

The match runs by serial number — so it survives whenever a drive ends up with a different number at the kernel level. The only moments the SSD is briefly writable are during a nixos-rebuild, so the bootloader sync can update its ESP partition. After that it goes straight back to read-only.

The Dashboard

I wanted something central. Something like a dashboard, a web UI, that kind of thing. Where I see the important stuff at a glance instead of running a stack of cat commands against random log files. So I cobbled together a small replacement in the form of a bash script, with some help from AI.

nixnas-status is what it's called and it's roughly 350 lines of bash that, over SSH, give me a live overview: CPU/RAM/load, network throughput and ping, storage with usage bars, RAID status, every drive with SMART and temperature, NFS exports and which of them are currently mounted by clients, and the status of all the services I care about. The thing refreshes every five seconds without flickering — instead of clear it does tput cup 0 0, so it just moves the cursor to the top and renders over what's there.

The whole thing is wired in via writeShellScriptBin:

environment.systemPackages = with pkgs; [
  # ...
  (writeShellScriptBin "nixnas-status" (builtins.readFile ./scripts/nixnas-status))
];

Meaning: no installation. After every nixos-rebuild, nixnas-status is just on the PATH. The script is read in at build time and the resulting wrapper lives in /run/current-system. If I want to change something, I edit the file in /etc/nixos and rebuild. No deployment, no service, no cron. Nothing.

The nixnas-status dashboard — everything important at a glance over SSH.

Hardening

This is one of my favorite areas, security. It's also a bottomless pit you could probably never finish digging in. Since this is "just" a NAS that's also protected by other things — firewall rules in my LAN, VLANs, and so on — I kept things pretty basic. The firewall opens exactly two ports (22 SSH, 2049 NFS). Fail2Ban is running and watching sshd: 5 failed attempts get a 1-hour ban, and bantime-increment escalates that for repeat offenders up to 48 hours. Should keep brute force and the like at bay. Excerpt from the configs:

services.fail2ban = {
  enable = true;
  maxretry = 5;
  bantime = "1h";
  bantime-increment = {
    enable = true;
    maxtime = "48h";
  };
  jails.sshd.settings = {
    enabled = true;
    port = "ssh";
    filter = "sshd";
    maxretry = 5;
  };
};

PermitRootLogin = "no", PasswordAuthentication = false. Login only via SSH keys now — the "password auth is still on" mentioned earlier in this post has since been taken care of, a step that had been sitting on the todo list far too long with no good reason to keep being postponed.

The NAS sits on its own VLAN with no inbound from the internet, so this is more about catching my own mistakes (mine or my girlfriend's) than fending off determined attackers.

Update May 2026 — What's Changed Since Publication

Three weeks after writing this blog post, the live config has moved on a bit, because real-world operation surfaced issues that weren't there in April. So nobody copies stale code 1:1, here are the honest updates:

Kernel 6.12.90 broke the it87 workaround. With the update to kernel 6.12.90, force_id=0x8613 suddenly stopped working — the driver just returned "No such device", no useful error message. The solution is in frankcrawford/it87 Issue #46: force force_id=0x8622 (IT8622E) instead. Hardware-equivalent enough that the driver addresses all the relevant registers identically — it just takes a detection path that isn't affected by the regression. The init script's name check was accordingly migrated from "it8613" to "it8622" — the code block above in this post already shows the current state.

Temperature-triggered hysteresis instead of a fixed PWM 50. The static solution in the original post (pwm3 = 50 as a constant) worked, but was blind to actual load. My current controller reads the HDD temperatures every 3 minutes and switches between Level 0 (PWM 100), Level 1 (PWM 160), Level 2 (PWM 220), and Level 3 (PWM 255) — with hysteresis so it doesn't oscillate: Level 1 only steps back down at ≤44°C even though it steps up at ≥45°C. A deliberate trade against the original auto-mode bug.

Realization: pwm4 and pwm5 are dead. While debugging the new detection, I noticed: the DXP4800 Plus actually has only two fans installed (on pwm2 and pwm3). The driver exposes pwm1, pwm4, and pwm5 too, but there's simply nothing behind them. My older init code still tried to configure all five — under the IT8622 detection path that gives EBUSY errors, because pwm4/5 are initialized read-only in auto mode there. Now I only touch pwm2 and pwm3.

smartd schedule moved to 13:00. Originally the long test ran Sundays at 02:00 — which collided with the backup window of my Proxmox Backup Server. Double drive load, double backup duration. Moved to 13:00, no collisions since.

-M 128 (AAM) removed. It was in the original version as a "quieter seek mode". When verifying, it turned out: (a) 128 isn't the quiet value (that would be 254), (b) IronWolf drives don't support AAM in the first place — the command was dropped in ATA-8, modern NAS drives silently ignore it. So this was a no-op in my config that pretended to do something. Now removed.

What I'd Do Differently

A few honest notes.

8 GB of RAM is borderline. For what I'm doing, it's fine — NFS, smartd, a btrfs scrub once a month, otherwise idle services. But tight enough that I can't pile anything else on top. If I wanted to put Jellyfin or Nextcloud directly on the NAS, 16 GB would be the absolute minimum. Right now those services live on a separate Proxmox host and just mount /data/media over NFS.

The initial password is changeme. Yes, flagged in the comments, yes, I change it after the first boot. But the better play is baking a deployment SSH key in from the start — the "install, panic-change password, then set up keys" pattern just isn't clean and isn't where I want to end up.

No off-site backup yet. RAID5 protects against one drive failing. It does not protect against fire, theft, or me firing off rm -rf in the wrong directory. The plan is a second NAS at a different location. The whole thing is on the planning board and will probably happen later this year.

The fan curve could be more granular. The 4-stage hysteresis described in the update block (levels 0–3 driven by HDD temperatures) replaces the original pwm=50 hack, but it's still coarse — a proper continuous curve (PWM scaling linearly over temperature instead of discrete steps) would be the more elegant long-term solution. As it stands, the controller steps a level up or down maybe 4× a day, which you can hear. Not bad, just not perfect.

The bootloader-on-UGOS thing feels fragile. It works, though. All three ESPs stay in sync. But if the UGOS SSD ever physically dies, I'm locked out of booting until I figure something else out. I should walk through the recovery case before I actually need it.

Overall, though — I'm really happy with how this turned out. In six months I can git diff and still know what every line does. Rebuilding from scratch on different hardware would be a handful of search-and-replace operations on disk IDs.

The repo is on GitHub at daskladas/nasdots if you want to dig further or grab a few bits. Help yourself.

Eric Heinemann