ophub/fnnas: FnNAS firmware for Amlogic, Rockchip and Allwinner TV boxes

What ophub/fnnas actually ships

This repository is not the NAS operating system. FnNAS itself is described in the README as a deeply customized operating system built on the latest Linux kernel and a Debian distribution, developed upstream at fnnas.com. What ophub/fnnas contributes is the Arm64 port: images built for TV boxes and boards powered by Amlogic, Rockchip and Allwinner SoCs, with the stated goal of replacing the Android TV system on a TV box and turning it into a private data storage server.

The README is explicit that the build inherits all features of the official system, and adds writing to eMMC boot and online kernel updates. So the audience is narrow and specific: people who already own one of the listed boxes, usually because it was cheap or because it is sitting unused, and who want a NAS without buying a mini PC. If you are choosing hardware from scratch, this project is the wrong starting point, because the supported device list is a compatibility table rather than a product catalogue.

The supported SoC families named in the repository description are a311d, s922x, s905x3, s905x2, s912, s905d, s905x, s905w, s905, s905l, rk3588, rk3568, rk3399, rk3328 and h6. The device table in the README goes further and lists individual models, from Khadas VIM3 and Beelink GT-King down to carrier boxes such as the CM201-1 and E900V22D. That table is the real specification of the project.

How the build is organised: make-fnnas, rekernel, renas

The top level of the repository shows the mechanism plainly. There are three directories that do the work: make-fnnas/, rekernel and renas, alongside action.yml, which indicates the images are produced by a GitHub Actions workflow rather than by hand on a maintainer's machine. The primary language is Shell, which matches that structure: the build is a set of scripts that assemble a root filesystem and kernel into a flashable image, not a compiled application.

The practical consequence of a scripted build is that the firmware is reproducible from the repository, and the README invites exactly that, suggesting you fork the project for personalised customisation. It also means the kernel is not something you patch in place. The README links a separate kernel_fnnas release tag and states that online kernel updates are supported, so kernel changes arrive as releases rather than as a package you compile.

One thing the README does not document is a rollback path. There is no described procedure for returning a device to its previous Android firmware after the FnNAS image is written, and no described procedure for reverting a kernel update. That silence matters more than any feature listed, because the write targets eMMC boot. Treat the absence as a real gap in the documentation and plan your own recovery route before you start.

Installing FnNAS on a supported TV box

The README does not contain a step-by-step flashing tutorial. It directs readers to the Releases page for the latest firmware and describes the result rather than the procedure, so what can be stated here is limited to the login details the README publishes.

Start by downloading the image for your SoC family from the Releases page. The release names follow the pattern fnnas_amlogic_<build> and fnnas_rockchip_<build>, for example fnnas_rockchip_692 and fnnas_amlogic_693, so the platform is visible in the asset name before you download it.

The README's default information table states that the system name is FnNAS.OS, that the default account and default password are both custom (set during your own setup rather than shipped as a fixed pair), that the SSH port is 22, and that the IP address is obtained from your router. So the first real task after boot is finding the device on the LAN from the router's client list, then logging in over SSH on port 22.

No flashing tool, image format or per-SoC boot mode is described in the README. Those details are not published there, and the release assets themselves are the only place they would appear. If you need a guided flashing procedure, this repository does not provide one.

The supported device table is the whole compatibility story

Compatibility here is not a range, it is a list. The README organises devices by SoC and orders them by performance from high to low, which tells you something useful: an s922x box will behave differently from an s905l3b carrier box, and the project does not pretend otherwise. It simply publishes which specific models are known to work.

The table is dense with model names and links to issue threads on related ophub repositories, which is where the per-device evidence lives. That structure has a cost. A device that is not listed is not necessarily unsupported, but there is no way to tell from the repository whether it will boot. If your box is a variant with a different wireless chip, a different eMMC size, or a different bootloader, the table entry for the base model may not transfer.

The s905l3b row is a good illustration of how granular this gets. It lists CM201-1, CM211-1, CM311-1, E900V21D, E900V22D, E900V21E, E900V22E, M302A/M304A, Hisense-IP103H, TY1608 (twice, pointing at two different issue threads), MGV2000, B860AV-2.1M and more, all under one SoC. That is not marketing breadth. It is a record of which carrier boxes people have actually reported working.

Where this approach breaks down

The first limitation is hardware risk. The README states that the build supports writing to eMMC boot. Writing to eMMC replaces what is on the device, and the README does not document rollback, so a device that fails to boot after the write may need vendor-specific recovery that this project does not describe. If the box is your only way to watch television, that is a real cost.

The second is that this is a port, not the upstream product. The README says the build fully inherits all features of the official system, but inheritance is a claim about feature parity, not about support. When something breaks in the NAS layer, the fix comes from upstream, and this repository's role is to rebuild and republish. The release cadence reflects that: the recent releases listed are dated 2026-06-25, and the last push to the repository was on 2026-09-23.

The third is that Arm64 TV boxes are weak NAS hardware. The README's own ordering by SoC performance makes the point. An s905x or s905w box has limited memory and slow storage interfaces, and the README does not document which external storage configurations are validated. If your goal is a multi-disk array with redundancy, this project does not describe how to build one, and the hardware it targets is a poor fit for it.

fnnas versus running Armbian and installing a NAS stack yourself

The obvious alternative is to flash a general-purpose Arm64 distribution from the same maintainer ecosystem, ophub/amlogic-s9xxx-armbian, and install the NAS software yourself. The difference in approach is where the integration happens. ophub/fnnas ships a complete NAS operating system image, so the storage management, sharing and web interface come preassembled and versioned together. The Armbian route ships a base system, and every NAS component becomes your responsibility to install, configure and keep updated.

That trade is real in both directions. With ophub/fnnas you get a known-good combination and lose the ability to swap out the NAS layer. With a base distribution you control every component and own every upgrade conflict. The README's note that the build inherits all features of the official FnNAS system is the strongest argument for the first route: you are not assembling a NAS, you are installing one.

A second alternative, if your hardware is x86 rather than Arm64, is to run FnNAS on that hardware directly, since the README describes the upstream system as supporting mainstream x86 and Arm64 devices. This project exists specifically because Arm64 TV boxes need a port; if you are not on Arm64, the port is not for you.

Licensing and what maintenance costs you

The repository is licensed GPL-2.0, and the LICENSE file sits at the top level. Because the build is a set of Shell scripts that assemble a Debian-based system, the licence governs the scripts and the images built from them. FnNAS itself is a separate upstream product from fnnas.com, and the README does not state its licensing terms. If you plan to redistribute images or ship a device with this firmware, the upstream terms are the ones you need to check, and this article is not legal advice.

Maintenance cost has two parts. The kernel is delivered through releases under the kernel_fnnas tag and the README states online kernel updates are supported, so kernel maintenance is a matter of accepting updates rather than rebuilding. The rest of the system tracks upstream FnNAS, which means your upgrade path is the project's release cadence. The recent releases shown are from 2026-06-25, and the last push was on 2026-09-23. That is a gap of roughly three months between the last release and the last commit, which is worth knowing if you expect image rebuilds to follow upstream changes quickly.

There is no documented support channel and no documented compatibility guarantee beyond the device table. Budget for that: you are adopting a community port whose correctness is evidenced by a table of models and a set of linked issue threads.

Editorial conclusion

Adopt ophub/fnnas if you already own one of the boards listed in its supported device table and want to turn it into a NAS without buying x86 hardware; the images are published on the Releases page and the build inherits the official FnNAS feature set, including eMMC boot and online kernel updates. Do not adopt it if your board is not in that table, if you need a support contract, or if you are unwilling to lose the Android TV system that currently occupies the eMMC. Before flashing, verify three things: that your exact model appears in the table for your SoC, that you have a way to recover the device if the write fails, and that you have read the licence file shipped with the image. The project's own README points at the Releases page as the place to get firmware, and that page is the only distribution channel it documents.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-2.0
3. ophub/fnnas on GitHub
4. README
5. Releases