本系列文章将对国产 NAS 系统飞牛 fnOS 进行全方位深度解析，从系统底层、存储架构、文件服务、用户权限，到 Web 前后端架构、应用生态、镜像定制，力争讲清楚每一个模块"是什么、怎么实现、配置文件在哪、关键命令是什么"。

本文是系列第一篇，聚焦系统基础信息摸底与启动流程追踪。

前言

飞牛 fnOS 是近年来国产 NAS 系统中关注度较高的一款，以易用的 Web 管理界面和丰富的应用生态著称。但作为一个基于 Linux 的 NAS 系统，它的底层到底做了哪些定制？启动流程是怎样的？Web 界面背后跑着哪些服务？

本系列将通过 SSH 登录系统，用最原始的命令行方式，一层一层剥开 fnOS 的外壳，看看里面到底是什么。

测试环境：fnOS 1.2.0505，x86_64 平台，4 块硬盘（1×NVMe SSD + 3×SATA HDD），8G 内存。

一、系统基础信息摸底

1.1 系统版本与内核

首先看系统版本：

cat /etc/os-release

输出：

PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
NAME="Debian GNU/Linux"
VERSION_ID="12"
VERSION="12 (bookworm)"
VERSION_CODENAME=bookworm
ID=debian

fnOS 基于 Debian 12 (bookworm)，但有意思的是，/etc/os-release 里完全没有 fnOS 自己的版本标识，是纯 Debian 的内容。fnOS 的版本号存在别的地方（后面会提到）。

再看内核：

uname -a

输出：

Linux DIO 6.18.18.c1032-trim #1032 SMP PREEMPT_DYNAMIC Fri Aug 21 01:49:29 UTC 2026 x86_64 GNU/Linux

这里有几个关键点：

  • 内核版本 6.18.18，非常新，远高于 Debian 12 自带的 6.1 内核
  • c1032-trim 后缀，这是飞牛自己的编译标记，说明内核是飞牛定制编译的
  • PREEMPT_DYNAMIC，动态抢占内核，偏向桌面/响应式优化，不是服务器吞吐量优先
  • 编译时间 2026-08-21，非常新

结论：fnOS 没有用 Debian 自带内核，而是自己编译了一个很新的 6.18 内核，并打上了自己的标记。

1.2 硬件与分区概览

lsblk

输出：

NAME        MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
sda           8:0    0 931.5G  0 disk
└─sda1        8:1    0 931.5G  0 part
sdb           8:16   0 465.8G  0 disk
└─sdb1        8:17   0 465.8G  0 part
  └─md1       9:1    0 931.3G  0 raid0
    └─trim_d1c5b5d5_... 253:1 0 931.3G 0 lvm  /vol3
sdc           8:32   0 465.8G  0 disk
└─sdc1        8:33   0 465.8G  0 part
  └─md1       9:1    0 931.3G  0 raid0
    └─trim_d1c5b5d5_... 253:1 0 931.3G 0 lvm  /vol3
nvme0n1     259:0    0 119.2G  0 disk
├─nvme0n1p1 259:1    0    94M  0 part  /boot/efi
├─nvme0n1p2 259:2    0  63.9G  0 part  /
└─nvme0n1p3 259:3    0  55.2G  0 part
  └─md0       9:0    0  55.2G  0 raid1
    └─trim_a7d015a3_... 253:0 0 55.2G 0 lvm  /vol1

这台机器有 4 块硬盘：

设备类型大小用途
nvme0n1NVMe SSD119.2G系统盘 + vol1
sdaSATA 硬盘931.5GZFS 存储池（vol2）
sdbSATA 硬盘465.8GRAID0 成员（vol3）
sdcSATA 硬盘465.8GRAID0 成员（vol3）

存储架构是混合的：系统盘用 NVMe SSD，数据盘同时使用了 mdadm 软 RAID + LVM 和 ZFS 两种方案。这部分我们将在系列第二篇《存储架构深挖》中详细展开。

1.3 运行服务统计

systemctl list-units --type=service --state=running

一共 81 个服务在运行。这个数字相当可观，说明 fnOS 的功能模块拆得很细。

快速浏览服务列表，会发现一个明显的规律：fnOS 自研的服务大多以 trim_ 开头，这和内核版本里的 c1032-trim 标记对应上了——"trim" 应该是飞牛的内部代号。

二、服务清单深度分析

2.1 fnOS 自研服务识别

在 81 个运行服务中，以 trim_ 开头的有 21 个：

服务名作用
trim_main.service核心主服务
trim_nginx.serviceWeb 服务（自编译 Nginx）
trim_init.service系统初始化
trim_connect.service飞牛互联远程访问
trim_open_gateway.service开放网关
trim_app_center.service应用中心
trim_license.service许可证管理
trim_upload.service上传服务
trim_sharelink.service分享链接
trim_file_monitor.service文件监控
trim_http_cgi.serviceHTTP CGI 接口
trim_sac.service系统应用控制
trim_tfa.service双因素认证
trim_trashbind.service回收站
trim_diskpowerd.service硬盘电源管理
trim_raid_check.serviceRAID 检查
trim_nic_name_consistency.service网卡名称一致性
trim_clean_up.service清理服务
trim-docs-docservice.service文档服务
trim-docs-fileconverter.service文件转换服务

除了 trim_ 前缀的，还有大量不带前缀但同样是 fnOS 自研的服务，比如 accountsrv（账户服务）、usersrv（用户服务）、filestor_service（文件存储服务）、rpc_broker（RPC 消息代理）、dockermgr（Docker 管理）、ai_manager（AI 管理）等，加起来 fnOS 自研服务大约有 40+ 个。

2.2 服务分类总览

把 81 个服务按功能分类：

分类代表服务数量
核心基础设施trim_main、rpc_broker、trim_init、system_startup~5
Web 服务trim_nginx、trim_http_cgi、trim_open_gateway~3
用户与权限accountsrv、usersrv、security_service、trim_tfa~4
文件存储filestor_service、finder_service、share_service、trim_file_monitor~5
文件协议smbd、nmbd、winbind、nfs-*、webdav、smbftpd、wsdd2~10
网络network_service、avahi、upnp、ipblocker、trim_connect、ovs-*~8
Docker/应用docker、dockermgr、dsmgr、trim_app_center、trim_sac~5
AI/媒体ai_manager、imagesrv、mediasrv、auto_thumbnailer、minidlna~5
备份/下载backup_service、dlcenter、multiple-downloads~3
系统管理updatemgr、sysdiag、sysinfo、sysrestore、resmon、eventlogger~6
硬件定制led-set、pwm-fancontrol、set_gpio-init、system_setmac、resize-rootfs~6
Debian 原生ssh、cron、dbus、NetworkManager、postgresql、rsyslog 等~15

值得注意的是，fnOS 甚至用了 Open vSwitch（ovs-vswitchd、ovsdb-server），这是一个虚拟交换机，通常用于虚拟化和容器网络，说明飞牛的网络架构不是简单的物理网卡配置。

2.3 被飞牛覆盖的 Debian 原生服务

在 /etc/systemd/system/ 目录下，我们发现了几个熟悉的名字：docker.service、smbd.service、nmbd.service、sshd.service、avahi.service。

这些本来是 Debian 包自带的服务，但飞牛在 /etc/systemd/system/ 里放了自己的版本，覆盖了原生配置。这意味着飞牛修改了这些服务的启动参数、依赖关系，甚至替换了二进制程序。

一个典型的例子是 nmbd.service（Samba 的 NetBIOS 名称服务），它的启动时间异常地长（后面会详细分析），很可能就是飞牛修改配置导致的。

三、启动流程全链路追踪

搞清楚有哪些服务之后，接下来的问题是：这些服务是按什么顺序启动的？从按电源到 Web 管理界面能打开，中间经历了什么？

3.1 启动耗时分析

systemd-analyze blame

这条命令按启动耗时从长到短排序，前几名如下：

排名服务耗时
1nmbd.service1分30秒
2system_startup.service12.3秒
3NetworkManager-wait-online.service7.8秒
4dockermgr.service5.0秒
5accountsrv.service5.0秒
6auto_thumbnailer.service5.0秒
7trim_connect.service5.0秒
8trim_open_gateway.service5.0秒
9trim_nginx.service4.1秒
10postgresql@15-main.service2.8秒

几个值得注意的点：

  1. nmbd 花了 1分30秒，这是最大的异常，后面单独分析
  2. system_startup 花了 12.3秒，这是 fnOS 自己的初始化脚本
  3. 多个 fnOS 服务（dockermgr、accountsrv、trim_connect 等）都正好 5 秒左右，这不是巧合，很可能是这些服务都有一个 5 秒的初始化等待，或者都依赖同一个 5 秒才就绪的东西
  4. PostgreSQL 数据库启动只要 2.8 秒，不算瓶颈
  5. trim_nginx（Web 服务）4.1 秒，也不算慢

3.2 关键路径分析

systemd-analyze critical-chain

输出：

graphical.target @1min 41.828s
└─multi-user.target @1min 41.828s
  └─winbind.service @1min 41.744s +84ms
    └─network.target @4.292s
      └─networking.service @4.168s +122ms
        └─ovs-vswitchd.service @3.834s +296ms
          └─ovsdb-server.service @3.565s +267ms
            └─network-pre.target @3.563s
              └─system_setmac.service @3.535s +26ms
                └─basic.target @3.502s
                  └─resize-rootfs.service @3.218s +283ms
                    └─sysinit.target @3.213s

这棵树展示了决定整体启动时间的最长依赖链。有一个非常反直觉的发现：

网络在开机后 4.3 秒就就绪了！

但 graphical.target（系统完全启动的标志）要等到 1分41秒。中间这 97 秒在等什么？答案是 winbind.service——它在 1分41.7秒才开始启动，只花了 84ms。

winbind 为什么等这么久？因为它在等 nmbd（就是那个花了 1分30秒的 NetBIOS 服务）。所以实际的瓶颈链是：

nmbd.service（1分30秒）→ winbind.service（84ms）→ graphical.target

3.3 从开机到 Web 可用的完整时序

综合 blame 和 critical-chain 的数据，我们可以画出完整的启动时序：

0s      开机 → BIOS/UEFI → 加载内核(6.18.18.c1032-trim) → systemd 启动
        ↓
0.3s    systemd-journald（日志）、加载内核模块
        ↓
3.2s    sysinit.target（系统初始化完成）
        ↓
3.5s    硬件定制：system_setmac（设MAC）、set_gpio-init、led-set、pwm-fancontrol
        ↓
3.8s    网络启动：ovsdb-server → ovs-vswitchd（Open vSwitch）→ networking
        ↓
4.3s    network.target（网络就绪！）
        ↓
~5s     trim_init.service（fnOS 初始化）
        ↓
~5.5s   rc-local.service（Debian 本地脚本）
        ↓
~6s     trim_main.service（核心主进程启动，常驻）
        ↓
~6s     rpc_broker.service（RPC 消息总线启动，常驻）
        ↓
~6s     system_startup.service（初始化脚本开始执行，花12.3秒）
        ↓
~18s    system_startup 完成 → trim_nginx.service（Web 服务启动，4.1秒）
        ↓
~22s    ✅ Web 管理界面可以访问了！
        ↓
~25s    其他服务陆续启动：accountsrv、filestor、dockermgr、trim_connect...
        ↓
~90s    nmbd.service（NetBIOS 名称服务）终于启动完成
        ↓
~90s    winbind.service（84ms）
        ↓
101s    graphical.target（systemd 认为系统完全启动）

3.4 实际体验时间 vs systemd 完成时间

这里有一个很重要的认知：

graphical.target 的时间（1分41秒）不代表用户体验时间。

用户实际能访问 Web 管理界面，只需要等 20 秒左右。剩下的 80 秒都在等 nmbd（Windows 网上邻居发现），这对通过 Web 界面管理 NAS 的用户来说完全无感。

这也解释了为什么很多人觉得 NAS "开机慢"——其实系统早就可用了，只是 systemd 的"完全启动"标志被某个慢服务拖住了。

四、核心服务拆解

启动流程中，有几个服务是 fnOS 的核心命脉，我们逐个看它们的配置文件。

4.1 trim_main.service —— 核心主进程

[Unit]
Description=trim main service
After=rc-local.service
After=trim_init.service

[Service]
Type=simple
ExecStart=/usr/trim/bin/trim
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

关键点：

  • 执行的是 /usr/trim/bin/trim 这个二进制程序，不是脚本
  • Type=simple，常驻后台运行
  • Restart=always，崩溃后 5 秒自动重启——这是系统的核心命脉，不能挂
  • 在 trim_init 和 rc-local 之后启动

trim_main 是 fnOS 最核心的服务，其他很多服务都依赖它或在它之后启动。

4.2 rpc_broker.service —— RPC 消息总线

[Unit]
Description=trim rpc broker service
After=rc-local.service
After=trim_main.service

[Service]
Type=simple
ExecStart=/usr/trim/bin/rpc_broker
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

关键点：

  • 执行 /usr/trim/bin/rpc_broker，也是二进制程序
  • 在 trim_main 之后启动
  • 同样崩溃自动重启

很多 fnOS 服务的描述里都写了 "(RPC API)"，比如 filestor_service、usersrv、sysinfo_service。这些服务之间不是直接调用，而是通过 rpc_broker 转发消息。

整体架构是微服务 + RPC 消息总线：

Web 前端 → trim_nginx → trim_main（核心） → rpc_broker（消息总线）
                                              ↓
                                    各个子服务（filestor、usersrv、accountsrv...）

4.3 trim_nginx.service —— 自编译 Web 服务

[Unit]
Description=trim nginx service
After=rc-local.service
After=trim_init.service
After=system_startup.service

[Service]
Type=forking
PIDFile=/run/nginx.pid
ExecStartPre=/usr/trim/nginx/sbin/nginx -t
ExecStart=/usr/trim/nginx/sbin/nginx
ExecReload=/usr/trim/nginx/sbin/nginx -s reload
ExecStop=/bin/kill -s QUIT $MAINPID
PrivateTmp=true
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

关键点：

  • Nginx 二进制在 /usr/trim/nginx/sbin/nginx，不是 Debian 包的 /usr/sbin/nginx，是飞牛自己编译的
  • ExecStartPre=/usr/trim/nginx/sbin/nginx -t，启动前先测试配置文件，有语法错误就不启动
  • 在 system_startup 之后启动——这就是为什么 Web 界面要等 20 秒左右
  • Type=forking，Nginx 标准的主进程 + 工作进程模式

飞牛用自编译 Nginx，可能是打了补丁或者加了自定义模块。

4.4 system_startup.service —— 初始化脚本

[Unit]
Description=Run custom script After trim_main
After=trim_main.service

[Service]
Type=oneshot
ExecStart=/usr/trim/bin/system_startup.sh
TimeoutStopSec=3
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

关键点：

  • 描述直接写了 "Run custom script After trim_main"，非常直白
  • Type=oneshot，一次性服务，执行完就退出
  • 执行的是 /usr/trim/bin/system_startup.sh 这个 shell 脚本
  • RemainAfterExit=yes，执行完后仍然标记为 active，这样依赖它的服务不会认为它失败了
  • 花了 12.3 秒，是启动流程中除了 nmbd 之外最慢的环节

五、启动瓶颈分析：nmbd 为什么要 1分30秒？

最后来说说这个最大的异常——nmbd.service 花了 1分30秒。

nmbd 是 Samba 套件里的 NetBIOS 名称服务，负责让 Windows 网上邻居能发现这台 NAS。正常情况下，nmbd 启动应该在几秒内完成。

1分30秒这个数字很微妙——它正好是很多网络操作的默认超时时间。可能的原因包括：

  1. 配置了 WINS 服务器但连不上：nmbd 在等待 WINS 服务器响应，超时后才继续
  2. DNS 解析超时：nmbd 启动时尝试解析某些主机名，DNS 不通导致等待
  3. 网络接口未完全就绪：虽然 network.target 在 4.3 秒就完成了，但某些虚拟接口（比如 Open vSwitch 的网桥）可能还没完全就绪
  4. 飞牛修改了 nmbd 配置：前面提到飞牛覆盖了 nmbd.service，可能加了一些自定义的启动前脚本或依赖

不管具体原因是什么，这个 1分30秒的延迟只影响 Windows 网上邻居发现，不影响 Web 界面访问，也不影响通过 IP 地址直接访问 SMB 共享。对大多数用户来说，这个瓶颈是无感的。

但如果要优化启动速度，nmbd 是第一个该动刀的地方。

六、总结

通过本文的分析，我们对 fnOS 的系统基础和启动流程有了完整的认知：

  1. 系统层面：基于 Debian 12，但使用自己编译的 6.18 新内核，版本号 1.2.0505
  2. 服务架构：微服务架构，81 个运行服务，其中 40+ 是 fnOS 自研，服务间通过 RPC 消息总线通信
  3. 启动流程：从开机到 Web 可用约 20 秒，systemd 完全启动要 1分41秒（被 nmbd 拖住）
  4. 核心服务：trim_main（核心主进程）、rpc_broker（RPC 总线）、trim_nginx（自编译 Web 服务）
  5. 设计特点：大量使用自研组件（自编译内核、自编译 Nginx、自研 useradd/mdadm/smbftpd 等），覆盖 Debian 原生服务

系列预告

下一篇《飞牛 fnOS 深度解析（二）：存储架构深挖》，我们将详细解析 fnOS 的四层存储架构，包括：

  • mdadm 软 RAID 的巧妙设计（单盘也封装 RAID1）
  • LVM 的使用方式（以及为什么管理工具被移除了）
  • ZFS 的定制（trimacl 内核补丁是什么）
  • trimafs2 自研联合文件系统——飞牛存储池的底层实现
  • 拿到一台新 NAS，如何用 5 条命令快速摸清存储架构

敬请期待。

本文基于 fnOS 1.2.0505 版本实测，不同版本可能存在差异。