我为什么用 Fedora Server 做 NAS 系统

写于 2026-08-09 。这篇文章讲讲我为什么走到现在这套方案。

0. 叠甲:先说明白几件事

本文是个人博客向的记录与观点分享。重点是介绍我自己的 NAS 是怎么搭的，对其它系统的讨论只作参照，不为分高下。在阅读之前，请先接受以下立场:

1. 方案无优劣，只有适配。 成品 NAS 、TrueNAS 、Windows 、Fedora Server——每个方案都对应一种风险偏好和维护意愿。我的选择只代表”我的需求与偏好”，不能覆盖你内心中的白月光。
2. 飞牛、群晖这类成品 NAS 系统各有适用场景。 本文对它们的讨论，都限定在”与我的存储和系统哲学不完全合拍”这一语境下;对依赖图形界面和集成服务的人，它们往往更省心。
3. 经验来自一台具体机器。 我的结论建立在特定硬件和场景上（硬件配置见 2.2 节），换一台机器，结论可能完全不同。
4. 我大量使用”我行我素”的判断。 不用 RAID 、不用快照、信任 XFS 、接受无冗余——这些基于我自己的备份闭环与风险接受度，请勿照搬，风险自负。

以及最重要的一点:下面这套存储哲学是全文的锚——你看完它，再决定要不要看我后面说的任何一句话。

---

1. 存储哲学:七条原则

1.1 无冗余设计，丢了就重建

先讲最重要的一条:我的四块数据盘全是单盘直挂，没有 RAID ，没有镜像，没有热备。

商业 NAS 的卖点基本都围着 RAID 转:镜像、容错、双盘冗余、热备盘……但 RAID 解决的其实是一个很具体的问题:盘在运行中突然坏了，而你没有别的副本。它用多买几块盘的成本，换取硬盘故障后继续运行的机会。这个机会有边界，不能把风险变成零。阵列重建时第二块盘跟着挂、固件 bug 一波带走全部数据、控制器坏了异地救援困难，这些事故每年都在真实发生。

在我的场景里，RAID 的收益不如备份明显:它要牺牲一部分容量，还容易让人懒惰，不备份。单盘就是单盘，坏了换一块，管理和恢复都更直接。

不靠 RAID 保命，数据就分两类处理:独一无二的靠备份(1.2 节)，能再下载的只留索引(1.3 节)。

1.2 独一无二的数据，靠全量备份兜底

三层备份:

1. 需要长期保存的目录，打成 RAR 分卷，带 10% 恢复记录(分卷自带冗余，小损坏能自愈)
2. 再生成 par2 冗余包，这是第二层:文件在传输或存储中发生位损坏时，par2 能把坏掉的部分修回来，不用整包重传
3. 最后通过网盘官方客户端上传

为什么这么折腾？因为网盘不保证你文件的完整性。传输中断、服务商抽风、存储介质老化，都可能让你某天发现”下载下来，但解压失败”。恢复记录加 par2 ，就是给网盘里的那份再加一层纠错，即使文件有小范围损坏，也还有机会修回来。

1.3 能再下载的东西，只留索引

我的 33TB 存储里，动漫、VN 游戏占了绝大部分，它们的共同特征是:可以重新从互联网上获取。所以我的做法是:

• 每夜全盘扫描生成目录索引（实现见 3.5 ），同步手机浏览
• 判定不常用的内容，删实体，留索引
• 想看了，查索引，重新下载

这套策略让盘永远装不满，”空间焦虑”从日常里消失了。索引的扫描速度也是我在文件系统上感受到差别的地方。

1.4 版本需求交给 git

需要历史版本的东西(代码、文档)，git 已经解决得比任何 NAS 的版本功能都好，而且通用、可迁移。所以我的 NAS 不需要快照。这个决定和预算无关，只是因为我没有这项需求。

1.5 相册:Syncthing 同步，原生浏览

手机相册是商业 NAS 很爱做文章的地方:群晖 Photos 、飞牛相册、Immich……用久以后，人们往往会连同它们的数据格式、APP 和识别功能一起依赖。

我的做法很简单:Syncthing 把手机相册实时同步到 NAS 盘上，手机用原生相册看。

1.6 告警用邮件就够

Scrutiny 每天凌晨巡检硬盘 SMART ，出问题发邮件。我的 NAS 上没有任何东西需要分钟级响应，邮件是最可靠、最不依赖厂商的通道。

1.7 盘不拔插

我的盘永远在机器里，传输走 Samba ，不需要以 Windows 直接拔盘读取为前提。文件系统在 Linux 上可靠，对我来说就够了。

---

2. 这台 NAS 的来历和现状

2.1 从 Windows Server 到 Fedora Server

这台 NAS 之前跑的是 Windows Server ，系统从 2022 一路升到 2025 ，数据盘也是 NTFS 。Windows 环境运行了一年多，今年（ 2026 ）端午节才重装 Fedora Server 44;Fedora 目前运行约两个月，期间完成了数据盘从 NTFS 到 XFS 的迁移。

重装前我先做了准备:先在虚拟机里体验了几天，把基本流程走了一遍，把Podman、SELinux的脾气摸透了之后，又买了一块新硬盘备用。正式装的时候，我拔下原来装 Windows 的系统盘，把 Fedora Server 装到新盘上——这样即使安装失败，换回原盘就能回滚到原来的 Windows 环境，我之前的服务都不需要重新配置。这块新盘就是现在的系统盘，原 Windows 系统盘也没闲置，现在当高速缓存用。

我当时装 Fedora Server ，直接契机是 Linux 7.1 引入的全新 ntfs.ko 驱动，而且我比较中意这个系统，不是原来的 ntfs3。我想换到 Linux 后继续使用原来的 NTFS 数据，但装好以后才发现，这个驱动在内核里虽然有对应的编译选项，Fedora 官方却迟迟没有启用，自带内核里根本用不上。于是我去拉了原作者仓库，自己把驱动编译出来加载，还暂时禁用了内核更新，避免内核更新把自编译的驱动覆盖掉。

后来又等了好几个内核版本，Fedora 官方仍然没有打开那个编译选项。因为禁用了内核更新，我自己写了个脚本，自动拉取官方新内核，检查那个编译选项有没有被打开;直到好几个版本过去，官方始终没开(这个脚本现在也删了)。同时，这个驱动对文件数量有限制，文件装到一定程度后 inode 计数就不再增长，拷贝新文件写不进去。继续围着驱动折腾下去意义不大，且我认为 Linux 上的 NTFS 已经不足以应对我目前的数据量了，且fstab要写一大长串来适应 Linux 的权限系统。于是我最后把数据盘全部格式化成 XFS——这是这条 NTFS 路线走到尽头后的选择。

格式化也不是一次性全格:四块盘的空间刚好够用，我像玩华容道一样，把数据用tmux搭配上Rsync在盘之间腾挪，空出一块就格式化一块，数据全程留在本地盘上，一块块把四块盘全部换成 XFS 。

2.2 硬件和存储

硬件是一台 2017 年的机器，购于闲鱼:i3-7100T ，16G 内存（原机单条 16G ，我在内存涨价前换成了双 8G ），4 块机械盘(2 块 WD 4T 、1 块希捷 14T 、1 块 WD 14T)和 2 块 128G 的 M.2 。现在四块数据盘全部是 XFS （存储层配置见 3.1 节）。

2.3 当前运行的服务

这台机器目前运行 14 个容器（清单和端口见 3.2 节表格），宿主机另提供 Samba 共享（详见 3.2 ），远程访问走 Xray 隧道 + frp （架构见 3.3 节）。

备份和索引任务也在这台机器上定时运行（ cron ，考虑迁移到 systemd timer ），对应 1.2 、1.3 节策略，实现在 3.5 节。

---

3. 技术架构总览

3.1 存储层:全盘 XFS ，单分区直挂

四块数据盘全部 XFS 单分区，fstab 用 UUID + noatime ，nofail。盘符会随 SATA 接线变化，所以挂载配置只认 LABEL/UUID:Old-1 、Old-2 、New-1 、New-2 。格式化时保留 ftype=1(容器 overlayfs 的硬性要求)。系统盘走 LVM ，SSD-Cache 盘专门处理压缩解压这类临时 IO 。还有两块 VeraCrypt 加密卷(H 、Weii)，平时只是空目录，需要时再挂载。

为什么不用 btrfs ？因为我没有快照和 RAID 的需求(第 1 章)，也不想为单盘直挂引入额外管理复杂度，且我不信任这个文件系统(尽管 Fedora Desktop 默认启用)。XFS 历史足够长，大文件顺序 IO 也适合我的情况，对我来说够用了。

3.2 服务层:Podman ，rootless 为主

容器分两类:12 个 rootless(用户级，linger 常驻)+ 2 个 rootful(webtop 和 scrutiny ，开机自启走系统级 podman-restart.service)。更新容器时，我先在 shell 里开代理，再执行 podman pull，重建前要先把代理关掉。原因是 podman 会把调用者环境里的 *_PROXY 自动复制进新容器，容器内的 127.0.0.1:1145 指向容器自己，代理会是死地址——这个坑我踩过，维护手册 3.2 节有记录。

容器	端口	干什么的
Syncthing	8384	同步工具(相册、笔记)
qBittorrent-EE	7474	BT 下载
OpenList	5244	搭 WebDAV 的，顺带挂载网盘
openlist_mysql	3306	OpenList 的 MySQL 数据库
openlist_meilisearch	7700	OpenList 的搜索索引
Open-WebUI	8080	一站式 AI 对话，绑定中转站
Bili-Sync	12345	B 站 视频自动同步
PeerBanHelper	9898	BT 恶意 Peer 自动封禁
dufs	5000	临时文件上传（替代之前 Windows Server 的 localsend ）
vnstat-dashboard	8685	流量统计面板
FluxDown	17800	视频下载服务
frpc	—	内网穿透客户端(host 模式)
webtop(rootful)	3000⁄3001 + 1145	百度网盘/115 GUI 客户端 + 全局代理核心(V2rayN)
scrutiny(rootful)	8088⁄8086	硬盘 SMART 健康监控
Jellyfin(按需)	8096	媒体服务器(核显转码，自启已关)
Minecraft(按需)	25565	联机游戏服务器

Jellyfin 、Minecraft 平时不常驻，需要时再启。

宿主上还跑着 Samba ，8 个共享，覆盖四块数据盘、两块加密卷、SSD 缓存盘及其临时目录，给 Windows 机器用。

3.3 远程层:零端口暴露

公网唯一入口是 VPS 上的 Xray 隧道(用抗量子加密算法，主要防未来量子计算对现有加密体系的破解)，frp 跑在隧道里面。路由器和 NAS 没有直接暴露给公网的服务端口，外部扫描也无法直接碰到这些服务。唯一的临时例外是 Minecraft:按需联机时会启动一个独立的三方 frp 通道对外暴露游戏端口，不开就什么都没有。 架构图：

[访问端 (如手机)] -> 请求访问 22.22.22.22:8384
       │
   (加密隧道)
       ▼
[VPS: Xray/3X-UI 服务端] 
       │ 
       ├─ (触发路由匹配 22.22.22.22:8384 -> 出站 to-8384)
       │ 
       └─ (执行 Redirect 重定向至 11.11.11.11:8384)
       │
[VPS: Linux 内核接管] -> 发现 11.11.11.11 就在本地 lo 网卡
       ▼
[VPS: frps 服务端 (监听在 11.11.11.11)]
       │
   (FRP 协议隧道 - 运行在 Xray 代理隧道内部)
       ▼
[本地: frpc 客户端] 
       │
       ▼
[本地: Syncthing 服务 (127.0.0.1:8384)]

3.4 监控与告警:Cockpit + Scrutiny

Cockpit 看系统全景，Scrutiny 管 SMART 巡检与邮件告警（策略见 1.6 ）。那封报警邮件后来牵扯出一段挺有意思的事，4.3 会讲到。

3.5 索引层:33TB 的一张地图

generate_efu_and_tree.py 每天 04:30 全盘扫描，缓存生效后大约 8 秒产出两份资产（换 XFS 前同样规模要 2 分钟）:

• EFU 文件:给 Windows 的 Everything 用，映射 V:/W:/X:/Y: 四个盘符，全局秒搜
• Tree 文本:经 Syncthing 同步到手机，用自制的 DiskTree-GUI(Kotlin Multiplatform)浏览

这个索引就是 1.3 节策略的实际落地。

---

4. 实证:一块”娇气盘”

我的 WD 14T(WUH721414ALE6L4)前前后后折腾了我几回，这段经历也比较能说明这台机器的维护方式。

4.1 第一个问题:休眠唤醒后的错误计数

这块盘休眠后重新唤醒，SMART 错误计数会持续增长。后来判断是盘体固件和 Linux 电源管理之间的兼容问题。解决办法是用 openSeaChest 固件工具禁用 EPC(Idle A/B 全关)，让盘永不停转。代价是每年多花点电费，换来错误计数归零。

4.2 第二个问题:6.0Gbps 下的链路错误

开机后 1~3 分钟，这块盘在 6.0Gbps 下会报 interface fatal error 和 CommWake LinkSeq，偶尔还会出现 I/O 错误，内核随后自动限速。我做了三轮交叉测试，每次只变一个变量:

• 换口换线:WD 14T 仍报错，原口接 4T 盘零错误，排除了线和主板口
• 把它和希捷互换盘位(电源线、数据线全换):第一次开机全净，一度误判是供电问题
• 换盘托并恢复原线缆:在新盘位再次复现，最后判断是盘体在 6.0Gbps 下信号不达标

最后把 libata.force=3.0G 写进全部内核条目，四个 SATA 口强制 3.0Gbps 。机械硬盘的持续传输峰值本来就低于这个速度，实际读写没有受到影响。之后开机再没出过同类错误。

4.3 第三个问题:Scrutiny 的重复告警

Scrutiny 每天 00:00 发报警邮件。查了半天，发现是盘内的持久 SMART 错误日志无法清空，属于历史错误留痕，当前并没有新的盘面故障。这个告警我保留记录，但不再把它当成新的硬盘故障处理。

4.4 最后的处理决定

SMART 关键指标全为 0 ，读取测试也没有问题，所以我没有迁移数据，也没有 RMA ，而是让这块盘继续服役。前提是链路问题已经被 3.0Gbps 限速解决，重要数据也有备份。这个决定不适合直接套到别人的机器上，但它符合我自己的风险边界。

---

5. 安全纵深

常被问”用通用系统自己搭，安全吗？”我的回答是:安全设置要自己设计，也要自己验证。下面几部分分别解决不同的问题。

5.1 网络入口

远程架构见 3.3 节，这里只补充一点:frp 启用了 token 认证，即使隧道这一层出了问题，外部也不会直接拿到整台主机的所有服务。

5.2 容器边界

大多数容器以 rootless 方式运行，并且只挂载自己需要的目录。家目录和 Tools 目录(里面有带凭据的脚本)不会 bind 进容器。唯一例外是 webtop(见 3.2):rootful ，挂着四块盘的读写目录。它的 VNC 桌面可通过 frp/Xray 隧道远程访问，我靠隧道认证加 VNC 密码来降低这部分风险。

5.3 备份和内容类型

备份走网盘官方 GUI 客户端（见 1.2 ），不用非官方 CLI 接口(例如 BaiduPCS-Go):一方面避免账号风险，另一方面让备份过程保持在可观察范围内。

下载内容与需长期保存的数据分开处理，分类策略见 1.1 、1.2 节。

5.4 SELinux 的实际作用

Fedora Server 默认启用 SELinux Enforcing 。容器共享、Samba 导出卷、GPU 直通都有对应的布尔开关，遇到权限问题时可以从服务域、文件标签和策略入手排查。

近期公开的飞牛路径穿越问题，让我更直观地看到这层隔离的价值。我在 Fedora Server 上做过测试:用 runcon 把命令切到 httpd_t 这类服务域，再去读本不该它读的文件(比如系统口令文件、数据盘上的敏感目录)，都被策略拦了下来。只要 SELinux 策略、服务运行域和文件标签写得正确，同样的路径穿越请求即使到达应用，也无法越过策略读取或修改受保护路径，这类越权访问可以被完全拦住。前提是服务不能运行在不受限域，挂载路径标签要正确，容器也尽量保持在不加 label=disable 参数的情况。相关背景可参见公开文章。

---

6. 为什么选 Fedora Server

“不用现成的 NAS 系统”只回答了一半。剩下的问题是，同为通用 Linux ，我为什么选 Fedora Server ？

6.1 内核更新快

2.1 节那段折腾 NTFS 驱动的经历让我确定:NAS 对内核和文件系统的依赖很深。Fedora Server 的内核更新比较快，现在 44 已经用上 7.1.x ，老硬件和文件系统相关的修复能较早拿到。至于当初那套驱动，我已经不再依赖。

6.2 Podman 用起来顺手

Podman 是 Red Hat 参与维护的项目，和 Fedora Server 的组合比较顺手。我在 3.2 节用到的 rootless 、linger 、podman-restart.service 这些能力都能直接用上。换到 Debian 系也能做，只是往往需要自己补版本和配置。

6.3 SELinux 默认 Enforcing

SELinux 默认 Enforcing （隔离效果实测见 5.4 ），权限排查手段现成，不用从零设计一套安全模型，目前正在测试安全性，慢慢补洞。

6.4 Cockpit

Fedora Server 自带 Cockpit ，磁盘、服务、日志、更新和终端都能从 9090 端口进入。日常管理用它就够了，需要更细的操作再进 SSH 。

6.5 软件较新，升级有节奏

Fedora Server 的软件包通常比较新，但系统仍然按版本发布，升级也有官方路径。我愿意用这种节奏换取较新的内核和工具，同时保留明确的升级窗口。

6.6 Server 版和桌面版

Server 版更干净:没有 GUI ，没有多余桌面依赖，安装后就能按服务器方式使用。我的 NAS 不需要桌面，唯一需要图形界面的地方，用 rootful 的 Ubuntu-Xfce 桌面容器 webtop(见 3.2)解决。

---

7. 为什么不选现成的 NAS 系统(只讲要点)

我的重点是这台 NAS 本身，这里的对照只讲要点。

7.1 飞牛(fnOS)

飞牛(fnOS)是我在公司环境里实际接触过的方案。 公司用它做 NAS 。它免费、中文、能装在普通 x86 机器上，还开放 root ，SSH 、sudo 、iptables 和 Docker 都能自己管，特别是最近更新的权限管理，使用 GUI 即可开放用户权限，这一点很实在。

我对公司这台飞牛并不太信任，重要数据每天都会备份到云端，不会只留下这一份。它的管理面、存储卷和升级节奏都有自己的框架，安全上也没有 SELinux 和 rootless 容器这层默认能力。用 root 权限可以绕过去，但需要自己维护这些改动，且可能会与官方更新不兼容。个人主 NAS 选择 Fedora Server ，是因为我愿意自己管内核、容器和文件系统，也希望这些东西直接由我控制。

7.2 TrueNAS 和 OMV

TrueNAS / OMV 。 ZFS 很强，但它的生态讲究 ECC 内存、冗余和快照，和我的单盘直挂方案不太合拍。OMV 更开放，但依然是以 NAS 面板为中心的系统，不完全符合我想要的服务器形态。

7.3 Windows Server

Windows Server 。 用了这么多年，最劝退我的是它的更新方式，还有功耗问题，用轻量级探针看空载 CPU 占用，经常保持在 30 以上。

7.4 群晖和威联通

群晖/威联通。 我没实际用过，不云评。从公开资料看，它们的管理框架比飞牛更封闭，硬件平台绑定，全家桶生态，和我的哲学冲突点只会更多。

对照到此为止，不再展开。

---

8. 什么人适合这条路线，什么人千万别试

选择 Fedora Server 这条路，意味着我自愿承担更多维护工作。诚实地说:

8.1 适合这条路线的人

• 家里有闲置/退役电脑，愿意花半天做初始配置
• 熟悉或愿意学 shell 、systemd 、容器基础
• 有稳定执行备份的习惯(没有备份，就不建议采用这条路线，或者可以自己手搓 RAID)
• 享受掌控感:能查日志、能改内核参数、能自己写脚本

8.2 不适合这条路线的人

• 想要开箱即用、不想读文档
• 数据重要但没有备份习惯(自建 NAS + 无备份 = 灾难现场)
• 需要厂商售后与官方技术支持
• 全家桶重度用户(Drive/Photos/Note 生态深度绑定)

---

9. 结语

9.1 我的答案

回到开头那个问题:为什么用 Fedora Server 做 NAS ？

因为我的存储哲学(第 1 章那七条)和现成 NAS 系统的默认方案不完全重合——具体对照在第 7 章。Fedora Server 让我从一套普通 Linux 服务器开始搭，存储、容器和服务都可以按自己的需要安排。

9.2 这套方案的代价

现在它稳稳管理着 33TB 的存储和 14 个容器，CPU 常年个位数负载。期间出过几次问题，我都留下了排查记录，下一次遇到类似情况时知道该从哪里下手。

缺点也有:配置要自己维护，网友问起来还得解释十分钟。对我来说，这份工作量换来了足够的可见性和调整空间。

对我来说，Fedora Server 就是一台可以按自己方式维护的 Linux 服务器。它承担了 NAS 的功能，但没有把我限制在某种 NAS 用法里。

---

附录:相关资源

• 维护手册:《 Fedora Server 系统安装与维护手册.md 》(与本文同目录，含全部配置细节与踩坑记录，未完善，暂时不放出)
• 目录浏览 App:DiskTree-GUI(Kotlin Multiplatform ，开源)