释放小七猫的分享欲

NAS 从 Debian 到 Fedora 的迁移

tags: NAS
@ 12/06/2026

NAS 从 Debian 到 Fedora 的迁移

自从决定从专用 NAS 系统换成 Linux 之后,陆陆续续用了不少的发行版。最早用的是 PVE,功能强大,但比较浪费资源,首先是 PVE 本身就会吃掉一部分内存和磁盘空间,使用虚拟机时还要注意空间回收等问题,长期使用下来也没有发现有什么非用不可的理由,不同的虚拟机、LXC 容器一台一个独立 IP,反而不便于管理,于是放弃了,顺便把内存降成了 16G。

后面用了一段时间的 Ubuntu26.04,用起来挺稳定,但商业气息实在太重,整天在 SSH 首页打广告,但可以关掉。还有就是软件版本太旧了,内核常年不更新,podman 还停留在 5.7.0 版本。虽然没有特别影响使用的点,但对于我来说还是不太得劲。

后面就想着用 debian 养老,装上了 testing 版本的 debian,怎么说呢?理论上他确实解决了 ubuntu 不得劲的问题,但用的过程中,就感觉很折腾。网络、存储、都要自己配置,虽说都能解决,但用的过程就是觉得折腾……

最后决定换到 fedora,其实在这个过程中,我纠结了很多天。debian 和 ubuntu 毕竟都是基于 apt 包管理器的,里面软件的行为基本上相同,迁移过程基本不用折腾。但 fedora 不一样,dnf 的管理逻辑与 apt 是存在很大差异的,迁移肯定不会像前两者一样平滑。

但我最后还是成功了。

磁盘规划

如果经常迁移发行版,或者方便维修,避免丢失数据,/home 一定要单独分区。如果容器使用 podman(podman rootless 模式,所有配置、容器、镜像全在 .local/share/containers 目录下),那么 / 可以分小一点,docker 的话就要分大一点。

我的分区方案如下:

nvme0n1     259:0    0 465.8G  0 disk
├─nvme0n1p1 259:1    0     1G  0 part /boot/efi
├─nvme0n1p2 259:2    0    32G  0 part /
├─nvme0n1p3 259:3    0 427.1G  0 part /home
└─nvme0n1p4 259:4    0   5.6G  0 part [SWAP]

我个人使用 podman,因此只留了 32G 给 / 分区,完全足够(软件不多的话 16G 都够了,如果需要装编译环境啥的,就需要多分一点)。

文件系统                               大小  已用  可用 已用% 挂载点
/dev/nvme0n1p2                          32G  5.4G   27G   17% /

装好系统之后,/etc/fstab 如下

UUID=2095ed95-b940-4659-8e1d-12470c188a01  /      btrfs  defaults  0  0
UUID=C6F2-34F8 /boot/efi vfat umask=0077,shortname=winnt 0 2
UUID=06521c64-6896-4e73-848e-83d39224506a  /home  btrfs  defaults  0  0

基本配置

禁用 firewalld 和 selinux

sudo systemctl stop firewalld
sudo systemctl disable firewalld

注意,我是因为有路由器做防火墙,所以才禁了设备防火墙,如果没有其他的防火墙,绝不推荐直接关闭 firewalld,可以学学如何开放必要的端口,不难

修改 /etc/selinux/config

将 SELINUX=enforcing 改为 SELINUX=disabled

重启之后 selinux 就会被关闭,不过不用急着重启,配得差不多了再重启都行。

zsh(可选)

略过,以前有写,也可以就用 bash

SSH(可选)

首先配置免密登录:

❯ cat ~/.ssh/authorized_keys
ssh-ed25519 AAAAC3Nza....

如果需要这台设备 SSH 或 SCP 其他设备,可以把自己的公钥也拷过来:

❯ cat ~/.ssh/id_ed25519
-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXk....ZC5jb20BAgMEBQYH
-----END OPENSSH PRIVATE KEY-----

最后添加一个 /etc/ssh/sshd_config.d/99-user.conf

# 放置在 /etc/ssh/sshd_config.d/,拒绝非内网密码登录
# 全局默认:禁止密码登录
PasswordAuthentication no

# 全局允许:密钥登录
PubkeyAuthentication yes

# 关闭交互式/二次验证,防止绕过密码限制
ChallengeResponseAuthentication no

# 禁止空密码、root 账号登录
PermitEmptyPasswords no
PermitRootLogin no

# 仅允许 10.0.0.0/24 网段内的设备使用密码登录
Match Address 10.0.0.0/24
        passwordAuthentication yes

作用如下,内网网段允许密码和密钥登录,外网仅允许密钥登陆,任何时候禁止 root 登录。

有了这份文件就可以大胆在公网暴露 IP 地址了,要是能被同时破解用户名和密钥,算黑客牛,小姐姐们请你拿去。

samba

安装 samba sudo dnf install samba

配置文件在 /etc/samba/smb.conf,这与 apt 系软件一样。

nfs

安装 nfs sudo dnf install nfs-utils

配置文件在 /etc/exports /etc/exports.d/,与 apt 系软件一样

crontab

与 apt 系一致

NUT 网络 UPS

配置文件在 /etc/ups/ ,与 apt 系有区别,apt 系配置在 /etc/nut/

配置方法完全一致

下载器

在迁移下载器之前,一定要备份好原来的配置,至少两份,方便还原,如果操作不当,很可能丢失做种数据,即使种子还在,重新校验的过程是非常费时费硬盘的,没有必要。

下面两个下载器都可以实现无缝迁移,直接开始做种。所以一定要做好备份,避免不必要的麻烦。

qbittorrent-nox

通过 sudo dnf install qibittorrent-nox 安装,配置文件分别在

  1. .local/share/qBittorrent
  2. ls .config/qBittorrent

与 apt 系一致的,如果之前配置没有删除,可以直接启动,数据不会丢失。

transmission-daemon

这个软件包与 apt 系差别较大,不能无脑迁移了,这也是最难迁移的一步。

区别 dnf apt
配置目录 /var/lib/transmission/.config/transmission-daemon /var/lib/transmission/.config/transmission-daemon
启动用户 transmission(982:982) debian-transmission
settings.json 配置文件 指向 /usr/share/... 某个文件的软链接
前端目录 /usr/share/transmission/public_html /usr/share/transmission/public_html

首先安装 transmission,sudo dnf install transmission-daemon,安装之后先不要启动,如果已经启动,关掉 sudo systemctl stop transmission-daemon

第一步,迁移配置目录:

进入 /var/lib/transmission/.config/transmission-daemon,备份一下 settings.json

然后通过 rsync,将备份的配置文件同步到现在的位置,一定要同步,不要直接 mv 或者 cp -r 覆盖。

同步之后大概是这样:

root@localhost:/var/lib/transmission/.config/transmission-daemon# ls
bandwidth-groups.json  resume ...  torrents
blocklists             settings.json          stats.json.tmp.BDSxxR  stats.json.tmp.grVPzc  stats.json.tmp.l8Psv3  stats.json.tmp.rd85wT  stats.json.tmp.XWF3Z2
...

修正目录权限:sudo chown transmission:transmission -R /var/lib/transmission/.config/transmission-daemon/

将之前备份的 settings.json,mv 过来,覆盖这个软链接文件。

第二步,修改 settings.json

{
    ...
    "download-dir": "下载目录",
    ...
    "incomplete-dir": "未完成缓存目录",
    ...
    "peer-port": 做种端口,
    ...
    "rpc-host-whitelist-enabled": false,
    "rpc-password": "你的密码",
    ...
    "rpc-username": "你的用户名",
    ...
    "rpc-whitelist-enabled": false,
    ...
}

改以上几处即可。

第三步,修正做种文件权限

从表格中知道,启动 transmission 时,用户不一样,因此需要给这个新的 transmission 用户做种文件目录的读写权限。如果没给权限就启动了 transmisison,则所有种子都会红种。即便后面修复了,也需要重新校验。

如果不幸到了重新校验那一步,就关闭 transmission,重新同步之前备份的文件,重来一次。

假设做种目录是 /vol-mfs/视频/PT。由于修复权限的方法实在太多,这里我只给出一种参考方案。

情况:qbittorrent 下载,转种到 transmission,但 qbittorrent 是用户启动的,下载的文件所属是 1000:1000,转种之后,transmission 无法读取用户 1000 的文件,就无法做种。

核心目标就是让 transmission 用户能够访问需要的文件,解决方案:

  • 使用户 1000 与 transmission 可以互访:sudo usermod -aG transmission 1000 ,sudo usermod -aG 1000 transmission,注销用户重新登陆,测试能否互相读写文件。
  • 也可以引入 users 组(100),将做种目录权限的用户组设为 users,将 1000 和 transmission 都加入 users 组,就可以共同访问下载文件。但你依然需要 sudo usermod -aG transmission 1000,因为刚下载的文件可能用户组不是 users 而是 1000
  • 以上两种方案共同使用(推荐)
  • 引入 ACL 统一管理(也推荐),ACL 可以直接赋予某用户某目录的权限,可以根除该问题。如果你已经有 ACL 功能,就用这个。

最后,启动 transmisison,查看做种是否正常 sudo systemctl start transmission-daemon

最后提一下前端 UI,我推荐 TrguiNG

进入 /usr/share/transmission/,将原来的 public_html 重命名或删除,解压 TrguiNg 的 Web 资源文件,命名为 public_html,重启 transmission 即可。

root@localhost:/usr/share/transmission# ll
总计 0
drwxr-xr-x 1 root root 1288  6月11日 22:37 public_html
drwxr-xr-x 1 root root  276  6月11日 22:16 public_html_bak

Podman 容器

podman 容器的数据目录主要在 .local/share/containers/,在新系统中,podman 的数据不会丢失,可以直接使用 podman images 查看以前的镜像,

❯ pm_ls_pod
POD ID        NAME                STATUS      CREATED       INFRA ID    # OF CONTAINERS
82ab3b7d37d8  pod_zhihu-download  Running     23 hours ago              1
ee5f92b556c9  pod_cloudbak        Running     23 hours ago              1
8a5eab9c40f6 ....

debian、ubuntu 相互迁移,在 podman 版本号相同的情况下,这些镜像可以直接使用,但 fedora 由于发行版差异较大,直接使用非常可能出问题,还是建议删掉以前的数据重头再来。

podman 的主要坑点在于数据库。

对于不使用数据库相关镜像的 compose,是直接使用podman-compose up -d可以跑起来的。

但以 halo 为例,

❯ ll
总计 8
drwx------. 1 sukipai sukipai   74  6月 1日 14:39 .
drwxr-xr-x. 1 sukipai sukipai  254  6月 9日 09:55 ..
drwxr-xr-x. 1 sukipai sukipai   92  5月 2日 22:42 data
drwx------. 1  100998 sukipai  512  6月11日 23:56 db
-rw-r--r--. 1 sukipai sukipai  259  6月 9日 10:18 halo2.service
-rw-------. 1 sukipai sukipai 1190  5月 8日 00:42 podman-compose.yml
drwx------. 1  100998 sukipai  512  6月11日 23:56 db

可以看到数据库这个文件夹的用户是 100998,但这个用户在 fedora 上,不一定是 100998 这样的用户。这导致迁移之后,podman 没有数据库的权限,因此容器起不来。

修复方法很简单,直接修改属组

sudo chown 1000:1000 -R db

然后再 podman-compose up -d,podman 会自动修复权限。

drwx------. 1  525286 sukipai  512  6月11日 23:56 db

我遇到需要修复数据库的容器主要有:immich、gitea、halo、qmediasync 等。