Sonarr/Radarr 只适合管理合法自有内容，先把目录、权限和质量规则写清楚。

\n
我在 HomeLab 里给 Sonarr 和 Radarr 留的位置很窄：它们只负责整理自己已经合法拥有的家庭录像、公开课程录屏、个人剪辑素材和购买后留存的本地视频文件。它们不应该变成“什么都自动处理”的黑盒，更不应该承担来源不清的任务。这个边界先写在文章开头，是因为后面的目录权限、命名规则、质量配置都围绕这一点展开。

先把整理边界写死

我会把可整理内容分成两类：一类是连续录制的节目资料，一类是单个作品或项目资料。Sonarr/Radarr 的作用只是帮我把这些文件改成可读、可检索、可备份的结构，例如年份、项目名、季节编号或版本说明。进入整理目录之前，文件来源、授权状态、保留原因已经由人确认过，工具只负责归档动作。

如果这个边界不清，后续问题会非常难排。一个自动重命名规则写错，可能把家庭素材改得面目全非；多个工具同时扫描同一目录，也会让文件在移动、重命名、索引之间来回变化。我的做法是把“待整理区”和“归档区”拆开，待整理区允许人工调整，归档区只接受规则明确的导入。

目录契约比功能开关重要

部署前我先画路径表，而不是先点页面设置。宿主机上可能是 /srv/video/personal、/srv/video/course、/srv/video/archive，容器里则统一映射成 /data/personal、/data/course、/data/archive。路径一旦确定，Sonarr、Radarr、备份脚本和日志记录都使用同一套容器内路径，避免一边写宿主机路径、一边写容器路径。

配置目录单独放，例如 ./config/sonarr:/config、./config/radarr:/config；视频资料目录和配置目录不要混在一起。配置目录保存应用数据库、命名规则和索引状态，归档目录保存真正的视频文件，备份策略不一样。配置目录适合在升级前快照，归档目录适合做长期校验和只读保护。

services:
  sonarr:
    image: lscr.io/linuxserver/sonarr:latest
    volumes:
      - ./config/sonarr:/config
      - /srv/video/personal:/data/personal
      - /srv/video/course:/data/course
  radarr:
    image: lscr.io/linuxserver/radarr:latest
    volumes:
      - ./config/radarr:/config
      - /srv/video/archive:/data/archive

权限只给需要写入的地方

整理工具必须能读待整理区，也要能写目标目录；但不是所有目录都该给写权限。已经归档且很少变化的家庭素材，我更倾向于只读挂载，真正需要写入的是导入目标、配置目录和临时工作目录。这样即使规则配置错误，损伤范围也会小很多。

PUID/PGID 要和宿主机目录属主对齐。页面提示“导入失败”时，我不会先改质量规则，而是先进容器看实际用户，再在宿主机上用 ls -ln、stat 核对目录编号。很多看起来像应用问题的失败，其实只是容器用户没有移动文件的权限。

质量配置别泛滥

Sonarr/Radarr 里的质量配置越多，越容易变成长期维护负担。我只保留自己真正会用的几个档位：原始家庭录制、公开课程压缩版、剪辑工作版、归档成品版。每个档位说明清楚用途、大小范围和保留规则，不为了追求“自动匹配更聪明”而塞满规则。

命名模板也一样。我的目标不是把文件名做得花哨，而是让十年后还能看懂：项目名、年份、序号、版本或来源设备即可。任何会频繁变化、需要猜测、容易和实际内容不一致的字段，我都不会放进最终文件名。归档系统最怕规则看起来高级，恢复时却没人敢动。

排障从路径和日志开始

我给这类服务准备的第一组命令很固定：docker compose config 看最终挂载，docker compose ps 看容器状态，docker inspect sonarr --format '{{json .Mounts}}' 看真实路径，最后再看应用日志。只要路径、权限、容器用户和目标目录能对上，大多数导入失败都能归类。

升级前我会导出应用配置，记录当前镜像版本和目录快照。升级后先用少量测试文件验证导入、重命名、回滚，再恢复日常自动整理。Sonarr/Radarr 在我这里不是内容来源系统，而是一个本地文件整理工位；它越克制，HomeLab 里的长期维护成本越低。