飞牛 fnOS 应用提取器：从「能装」到「能留」，NAS 应用管理提取

当你辛苦调教好的应用因为下架、换机或内网限制而无法复现时，手里有一个 .fpk 安装包，就是最大的安全感。

一、先说结论：它解决的到底是什么问题

飞牛 fnOS 的应用中心让安装变得极其简单——点一下就行。但也正因为太简单，我们很少想过一个问题：如果这个应用突然下架了，我的「安装能力」还在吗？

这个问题在几个场景下会变得非常尖锐：

场景一：官方内测应用的分享困境。飞牛音乐内测期间，拿到资格的用户想分享给朋友，却发现应用中心里根本没有「下载安装包」的选项。自己机器上装得好好的，却没法给别人。

场景二：应用下架的不可逆性。Lucky 从飞牛应用中心下架后，新用户再也装不上了。旧用户虽然还能用，但一旦卸载或换机，就永久失去了这个应用——除非手里有安装包。

场景三：纯内网环境的装机需求。没有外网的飞牛设备，应用中心打不开，想装什么只能靠离线包。而官方下载渠道并不提供 .fpk 的公开下载。

场景四：多台设备的批量部署。换新机器后，十几个应用一个个重装，配置还要从头调起。如果能把旧机器上「调教好」的应用直接搬过去，能省下大量重复劳动。

「应用提取器」做的事情，就是把你机器上已安装的应用，反向还原成可以离线安装的 .fpk 文件。它不解决「怎么装」，而是解决「怎么留」。

二、它和「抓包下载」有什么本质区别

在应用提取器出现之前，社区里已经有一种「土办法」：在应用中心点下载，趁安装包还在 /tmp/appcenter 时用 fnpack 工具反向打包。这种方法能work，但有几个致命短板：

依赖操作时机。必须在下载完成后、安装确认前取消操作，稍不留神安装包就被自动删除了。

需要命令行基础。要 SSH 进去、要装 fnpack、要跑循环脚本，对普通用户门槛太高。

无法处理已安装的应用。你只能「重新下载」一个应用来打包，没法直接从当前安装状态提取。

应用提取器的核心差异在于：它读取的是 /var/apps/ 下已经落地的应用文件，直接对「当前安装状态」做快照。这意味着：

• 不需要重新下载，不会错过时机
• 图形界面操作，不需要命令行
• 导出的是你机器上实际运行的版本，而非应用中心当前提供的版本

这个区别至关重要。如果你的机器上装的是某个应用的旧版本（因为新版本有 bug），提取器给你的是那个旧版本，而不是应用中心里的最新版。这对于「版本回退」场景是决定性的。

三、安全模型：以 root 运行，但全程只读

看到「需要 root 权限运行」，很多人第一反应是警惕。这完全可以理解——NAS 是数据重地，一个以 root 身份跑的应用如果行为不端，后果不堪设想。

应用提取器的安全设计值得拆开来看：

权限的必要性。它需要读取 /var/apps/ 下所有应用的文件。这些文件属于不同的应用用户，普通权限下根本无法遍历。不给 root，功能就跑不起来。

约束条件同样明确：

全程只读。它不修改、不删除任何已安装应用的文件。提取过程本质上是一次「复制 + 打包」，源文件保持原样。

用户数据被排除在外。提取时会主动跳过 etc、var、tmp、home、meta、shares 这些运行时目录，以及所有软链接。这意味着你的配置、数据库、用户文件不会被打进包里。导出的是「应用本体」，不是「你的数据」。

纯本地运行，无上传行为。后端只用 Python 3 标准库，前端是单文件 HTML，没有第三方依赖。除了应用内检查更新时会访问 GitHub，没有任何网络上传。

源码完全公开。你可以自己去 GitHub 审一遍代码，确认它只做了该做的事。

这个安全模型的核心逻辑是：用最小必要权限完成任务，用明确的「不做什么」来换取信任。它不碰你的数据，不连你的网络，只从应用目录里把文件读出来、打包、放到指定位置。

四、技术实现：反向打包的巧思

理解 .fpk 的本质，有助于理解提取器的工作原理。

.fpk 本质上就是一个 tar.gz 压缩包，只是遵循了飞牛定义的目录结构。一个标准的 .fpk 包含：

• manifest：应用的身份信息（名称、版本、架构等）
• app/ 目录：应用的可执行文件、UI 资源
• config/ 目录：权限和资源声明
• cmd/ 目录：生命周期脚本
• ICON.PNG / ICON_256.PNG：图标

关键在于 manifest 文件中的一个字段：manifest.checksum = md5(app.tgz)。也就是说，应用包在构建时，会先把 app/ 目录打成 app.tgz，计算其 MD5 写入 manifest，然后再把整个包根目录打成最终的 .fpk。

反向打包的步骤因此变得清晰：

1. 从已安装应用的目录（/var/apps/<appname>/）复制包根文件
2. 把 target/ 目录（相当于原始包中的 app/）重新打成 app.tgz
3. 重新计算 MD5，更新 manifest.checksum
4. 把所有东西打包成新的 .fpk

这个过程的精妙之处在于：它不需要原始安装包的任何信息。只需要当前安装状态的文件，就能逆向出一个功能完整的安装包。

五、实际使用中的几个关键判断

导出的包能装到哪？

只能装到飞牛 fnOS 上。.fpk 是飞牛的私有格式，其他 NAS 系统（群晖、威联通、绿联）都不认。

架构必须匹配。x86 的包不能装到 ARM 机器上，反之亦然。提取器会沿用原应用的架构声明，不会做转换。

什么情况下值得用它？

值得：

• 应用已从应用中心下架，但你还装着
• 你装的是某个内测/特殊版本，应用中心没有
• 你需要给多台设备装同一个应用，想一次性搞定
• 你想为「万一哪天应用没了」留一份备份

不太值得：

• 应用在应用中心正常提供，且你用的就是最新版——直接重新下载即可
• 应用本身支持 Docker 部署——Docker 方案更灵活，迁移也更方便

一个重要提醒

请勿把导出的包用于商业传播或分发付费应用。提取器的存在是为了解决「备份」和「迁移」的正当需求，不是绕过付费机制的途径。社区需要的是良性循环，而不是对开发者劳动成果的侵蚀。

六、与飞牛官方备份方案的关系

飞牛在 2026 年 9 月的更新中，已经开始支持部分应用的数据备份与还原——相册、Seek 等应用的数据可以备份到存储空间，换机后直接恢复。这是飞牛官方在「应用迁移」方向上迈出的重要一步。

但官方的备份方案目前有两个局限：

覆盖范围有限。只支持飞牛官方指定的几个应用，第三方应用和社区应用的数据不在范围内。

备份的是「数据」，不是「应用本体」。它帮你保留相册的标签、AI 索引、收藏，但不帮你保留「相册应用本身」。你仍然需要在应用中心里重新安装相册应用。

应用提取器和官方备份方案的关系是互补的：

• 官方备份解决「应用的数据怎么搬」
• 提取器解决「应用的安装包怎么留」

两者配合使用，才能实现真正的「无缝迁移」——先用提取器把应用本体导出，再用官方备份把数据导出，到新机器上先装应用、再还原数据。

七、写在最后

NAS 用户有一个共同的焦虑：数据的可控性。我们把照片、文档、影音存进 NAS，就是不想被某个平台的生死存亡绑架。但应用本身呢？它们同样是「资产」的一部分。

应用提取器的价值，不在于它有多「实用」——大部分用户可能一年也用不上一次。它的价值在于存在本身：它意味着当你需要的时候，你有办法。

就像灭火器、备用轮胎、离线密码管理器。你希望永远不需要用它们，但你知道它们在，心里就踏实。

项目地址：https://github.com/cjm2004/fnos-fpk-extractor
下载地址：https://github.com/cjm2004/fnos-fpk-extractor/releases/latest
作者：无名的小卒

最后附上fpk备份文件