群晖 Immich 图库部署记录（v3.3.1，含外网访问与 NAS 照片导入）
部署日期：2026-10-08 ~ 2026-10-09 设备：群晖 DS920+（DSM 7.2.2，HDD 存储池），用户 fei（administrators 组） 部署目录：
/volume2/docker/immich（SMB：\\FeiNas\docker\immich） 外网入口：https://immich.liufeisheng.cn 局域网入口：http://192.170.x.x:2283（内网直连，不走 frp/域名） 版本实测：Immich 3.3.1（4 容器：server / machine-learning / valkey / vectorchord-postgres）
一、整体架构
手机/浏览器
│ HTTPS
▼
阿里云 ECS 47.113.x.x
Nginx（*.liufeisheng.cn 通配符证书，acme.sh + DNSPod 自动续期）
frps :7000（HTTP 反代 vhost）
│ frp http 隧道（customDomains = immich.liufeisheng.cn）
▼
群晖 DS920+ frpc 套件（/volume2/@appdata/frpc/frpc.toml）
│ 127.0.0.1:2283
▼
immich_server 容器（2283）
├─ /data → /volume2/docker/immich/library （Immich 自有上传库）
└─ /srv/photo（只读） → /volume2/photo （外部库，既有照片）
要点：
- frp 的 http 类型隧道原生透传 WebSocket，Immich 的实时同步无需额外配置。
- immich.liufeisheng.cn 依赖域名泛解析（*.liufeisheng.cn → 47.113.x.x）与通配符证书，两者在 2026-10-08 的证书部署中已就绪，本次零新增 DNS/证书工作。
- Immich 官方不支持子路径（如 www.liufeisheng.cn/immich）：前端、API、手机 App 均按根路径设计，子路径会导致登录跳转、接口 404、App 无法连接。必须用独立子域名。
二、第一步：Docker 安装（已完成）
compose 基于 2026-10-08 官方 main 模板定制，关键内容：
| 服务 | 镜像 | 说明 |
|---|---|---|
| immich-server | ghcr.io/immich-app/immich-server:release |
端口 2283:2283，挂 library |
| immich-machine-learning | ghcr.io/immich-app/immich-machine-learning:release |
CPU 推理（DS920+ 无独显），model-cache 命名卷 |
| redis | valkey/valkey:9（sha256 固定） |
官方已弃 redis 旧镜像名 |
| database | ghcr.io/immich-app/postgres:14-vectorchord0.4.3-pgvectors0.2.0（sha256 固定） |
DB_STORAGE_TYPE: HDD，数据在本地卷 |
.env 关键项：
- UPLOAD_LOCATION=/volume2/docker/immich/library
- DB_DATA_LOCATION=/volume2/docker/immich/postgres（数据库必须本地卷，不支持 SMB/NFS）
- TZ=Asia/Shanghai；DB_PASSWORD 为 24 位纯字母数字
- 全部服务 restart: always
启动：Container Manager → 项目 → 路径 /volume2/docker/immich → 使用现有 compose；
或 SSH：cd /volume2/docker/immich && sudo docker compose up -d。
首个注册账号即管理员。
三、第二步：配置外网访问 immich.liufeisheng.cn（已完成）
在 root SSH 窗口向 /volume2/@appdata/frpc/frpc.toml 追加：
# Immich 图库（2026-10-09）：官方不支持子路径，只能独立子域名
[[proxies]]
name = "immich"
type = "http"
localIp = "127.0.0.1"
localPort = 2283
customDomains = ["immich.liufeisheng.cn"]
校验与生效：
/volume2/@appstore/frpc/bin/frpc verify -c /volume2/@appdata/frpc/frpc.toml # syntax is ok
synopkg restart frpc
验证（已实测通过）：
- https://immich.liufeisheng.cn 返回 Immich 登录页（/api/server/ping → {"res":"pong"}）
- /api/server/version → {"major":3,"minor":3,"patch":1}
- 手机 App 服务器端点：https://immich.liufeisheng.cn
关于端口：
- frpc 的 localPort 对应 compose 端口映射 宿主机端口:容器端口 的左边。
- 容器内端口 2283 是 Immich 写死的，不能改；宿主机端口可改（如 8090:2283，需重建 server 容器并同步改 frpc），但该端口仅内网使用、不直接暴露公网，保持 2283 最简单。
四、第三步：让 Immich 读取 NAS 里既有照片（外部库）
4.1 两种数据来源的区别（先理解再操作）
| Immich 自有库（/data） | 外部库（External Library） | |
|---|---|---|
| 物理位置 | /volume2/docker/immich/library |
/volume2/photo（photo 共享文件夹），只读挂载给容器 |
| 写入方式 | 手机自动备份 / 网页拖拽上传 | Immich 不搬文件、不改原文件，只扫描建立索引 |
| 适合场景 | 今后新拍照片的自动备份 | 导入 NAS 上多年积累的既有照片/视频 |
| 删除行为 | Immich 内删除即删除文件 | 磁盘删文件 → 重扫后进回收站；Immich 内删除只移除索引 |
| 元数据 | 随 Immich 管理 | 加相册/改描述等只存在 Immich 数据库里；移动原文件后重扫，元数据丢失（被视为新资产） |
结论：既有照片 /volume2/photo（SMB：\\FeiNas\photo）走外部库；今后手机新照片走 App 自动备份进自有库。 不要手工往 library 目录里拷文件。
实测 photo 共享文件夹内容（SMB）：
- 2016-2025手机照片备份/（2016/2018/2019/2020/2021/2023/2024/2025）
- 24年前手机照片备份/（2016/2018/2019/2020/2021/2023/2024，与上者疑似重复，见 4.5）
- 2023~2024视频 荣耀70/
- sisi's photos/、生活视频图片/
4.2 操作 1：照片目录路径（已确认）
外部照片库绝对路径已确认为 /volume2/photo（photo 共享文件夹，与 docker 同在 volume2）。
SMB 访问为 \\FeiNas\photo。
4.3 操作 2：把照片目录只读挂进 immich-server 容器
编辑 /volume2/docker/immich/docker-compose.yml，在 immich-server 的 volumes 下增加一行：
volumes:
- ${UPLOAD_LOCATION}:/data
- /etc/localtime:/etc/localtime:ro
- /volume2/photo:/srv/photo:ro # 新增：外部照片库，只读，容器内路径固定 /srv/photo
在 immich 目录重建 server（只动 server，不动数据库）：
cd /volume2/docker/immich
sudo docker compose up -d immich-server
进容器验证可读：
sudo docker exec immich_server ls /srv/photo
能看到 2016-2025手机照片备份 等目录即挂载成功（2026-10-09 已完成挂载）。
4.4 操作 3：在 Immich 网页创建外部库并扫描
- 用管理员登录 https://immich.liufeisheng.cn
- 左上菜单 → 管理（Administration）→ 库（Libraries）→ 创建外部库
- 选择归属用户（外部库只能归属于一个用户）→ 命名如「NAS照片库」
- 进入该库 → 扫描设置 / Import Paths，逐条添加容器内路径（正斜杠）：
/srv/photo/2016-2025手机照片备份
/srv/photo/2023~2024视频 荣耀70
/srv/photo/生活视频图片
/srv/photo/sisi's photos
- 导入路径递归扫描，多个路径重复文件自动去重。
- 路径不存在或不可读时对话框会直接告警。 5. 需要排除的目录/文件用排除 glob，例如：
**/@eaDir/**（强烈建议：群晖缩略图目录）**/*.{tif,tiff}、**/Raw/**（按需） 6. 点 扫描全部（Scan All）。大量文件时耗时较长（CPU 生成缩略图/转码），完成后照片出现在主时间线，可加相册、看地图、被人脸/智能搜索索引。
日常维护： - 外部文件有新增/修改后，在库页面点「扫描」才会同步；也可在设置里开定时扫描。 - 想让新照片自动进 Immich，用手机 App 的「自动备份」，不要依赖外部库。 - 浏览器缓存激进，改动后看不到变化时 F12 → 长按刷新 → 清空缓存并硬性重新加载。
4.5 注意事项
2016-2025手机照片备份与24年前手机照片备份子目录高度重合：先只导入前者，确认无误后再决定是否加后者；Immich 对完全相同文件会去重，但内容近似、文件名不同的不会，可能产生重复时间线条目。- 外部库挂载务必加
:ro：Immich 不会、也不应修改原始文件。 - 不要在导入路径中使用符号链接跨 docker 挂载。
- 外部资产加入相册/修改描述等元数据仅存于 Immich；移动原文件路径后重扫会被当作新资产、元数据丢失。
- DS920+ 无独显，首次大批量缩略图/视频转码为 CPU，属正常现象；后续可将 machine-learning 换 openvino 镜像利用核显。
六、外部库子文件夹加载后，如何继续整理这些照片？
核心原则：外部库是只读的，Immich 只是照片的"展示/管理界面"，不是文件管家。物理文件的整理在 Immich 之外做；Immich 内的整理只改数据库。
推荐的"双层管理"模式：
| 层级 | 工具 | 做什么 |
|---|---|---|
| 物理层（文件） | 群晖 File Station 或 SMB（\\FeiNas\photo） |
移动、改名、合并目录、去重、删除文件 |
| 逻辑层（视图） | Immich 网页/App | 建相册、收藏、归档、加描述、人脸/智能搜索 |
6.1 在文件系统中整理（要动物理文件时）
按这个顺序操作，可避免丢 Immich 元数据：
- 先在 Immich 中确认：管理 → 库 → 外部库 → 暂停或记住当前状态。
- 在 SMB/File Station 中整理文件（移动、改名、合并）。
- 两个疑似重复的大目录（
2016-2025手机照片备份与24年前手机照片备份）可在此阶段合并去重；建议用rsync -av --ignore-existing或 FreeFileSync「镜像+跳过已有」，不要盲目覆盖。 - 回 Immich 外部库点「扫描」： - 被移动/改名的文件会被当作新资产重新导入（旧条目进「离线」），原有的相册归属、描述等元数据丢失。 - 扫描后去「操作（Jobs）/回收站」确认旧的离线条目，可用「移除所有离线资产」清理索引（不删磁盘文件）。
- 因此：已在 Immich 里精心打过标签的目录，尽量少搬动物理路径；还没整理过的目录，建议"先整理完物理结构，再扫描导入"。
6.2 只在 Immich 内整理（推荐，不动原文件）
- 用相册做主题归集（家人、旅行、孩子成长），相册是虚拟的，同一照片可属多个相册。
- 用归档收束不想天天看到、但想保留的照片（截图、证件、过期内容）。
- 用收藏标精选。
- 这种整理完全不影响磁盘文件，随时可改。
6.3 实用工具（Administration / Tools）说明
- 重复检测（Duplicates）：3.x 的重复管理页可逐组对比、保留一张。对外部库资产执行移除时只删 Immich 索引，磁盘文件不动（挂载是
:ro）。 - 离线资产清理（Offline / Missing）：外部文件被移走或删除后，在此清除失效索引。
- 存储模板（Storage Template）：只对自有库（/data 上传的照片）生效，可按拍摄日期自动归档成
YYYY/MM；对只读外部库无效。
七、收藏、相册、归档等操作会不会影响原文件？
结论：以下操作对 /volume2/photo 里的原始文件零影响，全部只记录在 Immich 的 Postgres 数据库中。
| Immich 操作 | 对原文件的影响 | 说明 |
|---|---|---|
| 收藏（Favorite，♥） | 无 | 一个数据库标记，仅用于筛选 |
| 加入/移出相册（Album） | 无 | 相册是虚拟集合，不复制、不移动文件；一个照片可在多个相册 |
| 归档（Archive） | 无 | 只从主时间线隐藏，在「已归档」视图里仍可查看，可随时取消 |
| 修改描述/标签/评分/拍摄日期 | 无（外部库） | 只写数据库；外部库只读，不可能回写 EXIF |
| 堆叠（Stacks，连拍合并） | 无 | 仅展示层分组 |
| 人脸命名/合并、智能搜索 | 无 | 结果存数据库与向量库 |
| 从外部库「删除」（垃圾桶图标） | 不删磁盘文件 | 因挂载 :ro，只移除 Immich 索引；重扫还会回来 |
| 从自有库删除（手机上传的照片） | 会删文件 | /data 是可写的，删除先进 Immich 回收站（默认保留 30 天），清空后物理删除 |
唯一需要留意的写操作场景：手机 App 自动备份上传的照片属于自有库，在 Immich 里对它们执行删除/清空回收站会真正删除 /data（即 /volume2/docker/immich/library）里的文件。外部库的照片则怎么操作都安全。
八、从群晖 Photos 迁移到 Immich 的完整方案（含卸载）
8.1 已查明的群晖 Photos 数据现状（2026-10-09 实测）
群晖 Photos 的数据分两处：
| 位置 | SMB 路径 | 内容 |
|---|---|---|
| 个人空间-手机备份 | \\FeiNas\homes\fei\Photos\MobileBackup\iPhone |
按年/月：2014(1)、2022(1)、2023(4)、2024(60)、2025(4565)、2026(504)，共 5135 个文件 |
| 共享空间 | \\FeiNas\photo（即 /volume2/photo） |
就是现在的 photo 共享文件夹本身（含历史的手机备份目录、视频等） |
| 其他用户 | homes\admin、homes\sisi、homes\woniu | 均无照片数据（Photos 目录为空或不存在），迁移只需处理 fei 账号 |
关于"有些照片/视频无法上传备份"：这些文件根本没传上 NAS，它们只存在于手机本地。群晖 Photos 端无法补救，只能靠手机侧重新备份（见 8.4）。
8.2 迁移顺序（重要：先迁移、验证，最后再卸载）
第 1 步：把 MobileBackup 复制进 /volume2/photo
在 File Station 或 SMB 中操作（复制，不要剪切）：
源：homes\fei\Photos\MobileBackup
目标：\\FeiNas\photo\2014-2026_iPhone手机备份\MobileBackup
- 与
2016-2025手机照片备份可能有大量重复，先保留两份，Immich 扫描后用「重复检测」处理；或复制时用跳过已存在同名文件策略。 - 复制完成后核对文件数：目标目录应为 5135 个文件（含可能被跳过的则对差异心中有数）。
第 2 步：在 Immich 外部库加入新路径并扫描
管理 → 库 → 外部库 → Import Paths 增加：
/srv/photo/2014-2026_iPhone手机备份
排除 glob 保持 **/@eaDir/**。扫描完成后：
- 在 Immich 中查看重复管理页，清理重复条目（只删索引不删文件）。
- 抽几个月份对比照片数量，确认 MobileBackup 的文件已被识别。
第 3 步：处理手机上"当年没传成功"的遗漏照片（关键）
这是群晖 Photos 遗留遗漏的唯一补救途径：
- 在手机安装 Immich App（iOS App Store / 安卓 Google Play 或 F-Droid/GitHub Release）。
- 服务器填
https://immich.liufeisheng.cn（外网）或http://192.170.x.x:2283（内网），登录账号。 - 开启自动备份，选择备份整个相机胶卷（含全部相册/视频，按需）。
- Immich 会跳过已备份过的文件；当年遗漏的老照片会被全部补传到自有库（/data）。
- 等待备份进度 100%（注意大视频在局域网内传更快）。
第 4 步：全面核对
- 时间线按年份翻看，重点检查 2024/2025（文件最多）。
- 确认照片+视频总数与手机相册、NAS 目录量级一致。
- 建议稳定运行观察 1~2 周再卸载群晖 Photos。
第 5 步：卸载群晖 Photos（套件中心 → 已安装 → Synology Photos → 卸载）
- 卸载只移除应用程序与其数据库（相册、分享设置等应用层信息）。
- 不会删除
\\FeiNas\photo共享文件夹中的任何文件。 - 不会删除
homes\fei\Photos里的备份文件（属于用户主目录数据，DSM 卸载套件不触碰）。 - 卸载后，确认 Immich 一切正常，再把
homes\fei\Photos\MobileBackup原件删除（此前复制进 /volume2/photo 的副本保留），释放主目录空间。删前再核对一次副本文件数。
注：群晖 Photos 的"网页相册/共享相册"是逻辑组织，物理文件仍在上述两处，卸载不会额外产生需要导出的文件；相册结构在 Immich 里按需重建即可。
九、目标：所有照片统一归集到 /volume2/photo
现状问题：手机 App 自动备份的新照片默认进自有库 /volume2/docker/immich/library（/data），不在 /volume2/photo 内。两个可选方案：
方案 A（推荐，零风险）：保持现状，以 /volume2/photo 为"统一总库"定期归档
- 物理分布：历史照片在
/volume2/photo（外部库只读）；新备份在 immich/library（自有库可写）。 - 用 Immich 自带备份功能：管理 → 备份（Backups），可把数据库导出到
/data/backups，照片层面则定期用 Job「存储模板迁移」后，通过 File Station 把 library/upload 中已归档的文件复制进 /volume2/photo 对应年份目录，再让外部库扫描收录，最后从自有库删除原件。 - 适合：不想折腾挂载、求稳。两个位置在 Immich 时间线里是合并展示的，浏览无差别。
方案 B（物理上真正统一）：把 /data 改挂到 /volume2/photo 内的子目录
让手机新备份直接落在 /volume2/photo 里面：
- 先建目录：
/volume2/photo/_immich_upload（SMB：\\FeiNas\photo\_immich_upload）。 - 停止服务：
cd /volume2/docker/immich && sudo docker compose stop immich-server。 - 把现有 library 整体移动到新目录（SSH，权限/属主原样保留，不要用 SMB 剪切）：
bash
sudo mv /volume2/docker/immich/library /volume2/photo/_immich_upload
- 修改
.env：UPLOAD_LOCATION=/volume2/photo/_immich_upload。 - 启动：
sudo docker compose up -d immich-server，检查照片、缩略图、登录正常。 - 外部库的导入路径保持只指向具体子文件夹（如
/srv/photo/2016-2025手机照片备份、/srv/photo/2014-2026_iPhone手机备份），不要把整个/srv/photo或/srv/photo/_immich_upload加入外部库，否则自有库文件被重复索引。 - 注意：compose 中
/volume2/photo:/srv/photo:ro挂载不变；容器通过 /data（现在指向 _immich_upload，可写）写新文件，两条挂载指向同一磁盘的不同路径，互不冲突。
此后全部照片物理上都在 /volume2/photo：历史目录（只读外部库）+ _immich_upload（可写自有库）。
最终目录规划建议
/volume2/photo/
├─ 2016-2025手机照片备份/ （外部库索引）
├─ 2014-2026_iPhone手机备份/ （外部库索引，MobileBackup 迁入）
├─ 2023~2024视频 荣耀70/ （外部库索引）
├─ 生活视频图片/ （外部库索引）
├─ sisi's photos/ （外部库索引）
├─ _immich_upload/ （自有库 /data，手机自动备份落点，方案B）
├─ 24年前手机照片备份/ （去重合并后可删除）
└─ 根目录散文件（建议归入对应年份目录后扫描）
9.5 全量归集 + 内容去重（2026-10-09 已执行）
盘点结论
经只读全盘盘点，NAS 上的照片/视频来源已全部确认，并已物理归集到 /volume2/photo：
- 群晖 Photos 个人手机备份（homes/fei/Photos/MobileBackup）此前已转入 photo，homes 下原件已空。
- homes 的 admin / sisi / woniu、fei/Backup/OneDrive（Obsidian 笔记备份）均无照片遗漏。
- homes 真实路径为
/volume2/homes，与 photo 同卷，本地移动为瞬时改名。
去重方法（脚本可复现）
脚本 /tmp/dedup_scan.py（本机临时副本 C:\Users\41456\AppData\Local\Temp\dedup_scan.py）：
- 先按文件大小分组，再对同大小文件算 SHA256，判定"内容完全相同"。
- 跳过 @eaDir、#recycle、@tmp。
- 只读，生成报告 /volume2/photo/_dedup_report.txt。
扫描结果：总 21896 文件，重复组 7409，冗余 10802，可释放 50.7GB。
删除脚本 /tmp/dedup_remove.py（本机副本 AppData\Local\Temp\dedup_remove.py），按目录优先级每组留 1 份：
| 优先级 | 保留目录 | 说明 |
|---|---|---|
| 1 | 2016-2025手机照片备份 | 历史手机备份正本 |
| 2 | 2014-2026_iPhone手机备份 | iPhone 备份正本 |
| 3 | 2023~2024视频 荣耀70（顶层） | 荣耀视频正本 |
| 4 | sisi's photos | |
| 5 | 生活视频图片 | 内含多套嵌套副本 |
| 6 | 24年前手机照片备份 | 与 2016-2025 高度重复 |
| 7 | iPhone | MobileBackup 第二份副本 |
同目录内优先保留不带 -长hex 后缀的干净文件名。
执行结果（--apply 实测）
- 已移动 10740 个冗余文件，0 失败，释放 51GB；不是直接删除，全部移入暂存目录
/volume2/photo/_dup_trash/（保留原相对路径，可整体还原）。 - 62 个报告中已不存在的文件自动跳过。
去重后各目录剩余文件：
| 文件数 | 目录 |
|---|---|
| 4452 | 2016-2025手机照片备份 |
| 3018 | 2014-2026_iPhone手机备份 |
| 2902 | 生活视频图片 |
| 1293 | 2026（独立备份：微信/截图类，未与他处重复，保留） |
| 325 | sisi's photos |
| 54 | 2023~2024视频 荣耀70 |
| 0 | iPhone、24年前手机照片备份（内容全部为副本，已腾空） |
后续动作：
1. 在 Immich 外部库重新扫描，对已移走的文件用「移除离线资产」清索引（不影响磁盘）。
2. 确认 Immich 浏览无缺失、稳定运行 1~2 周后，再删除 _dup_trash 彻底释放空间；在此之前它是后悔药。
3. 外部库扫描排除规则需同时包含 **/@eaDir/**、**/_dup_trash/**、**/_immich_upload/**。
4. 内容哈希相同才算重复；画面近似但哈希不同的照片不在本次范围，交 Immich 智能重复检测/人工判断。
9.6 目录合并、荣耀并入、非媒体清理、2026-2 去重并入（2026-10-09 已执行）
1) 两个正本库合并
将 2016-2025手机照片备份（4452）与 2014-2026_iPhone手机备份（3018）合并为一个库：
- 最终结构：
2014-2026_iPhone手机备份/YYYY/MM/文件（目标原路径 MobileBackup/iPhone/ 提升到顶层）。 - 两边文件名零冲突（源为日期命名、目标为 IMG_ 命名），共 7470 个文件，零丢失。
- 已删除：
24年前手机照片备份（全为 @eaDir 副本）、iPhone（全为副本）、源目录空壳。
2) 荣耀70视频并入
- 53 个 MP4 按文件名
VID_YYYYMMDD解析年月，并入对应YYYY/MM（1 个无匹配的 info.txt 作为非媒体移出）。 - 荣耀空壳目录已删除。可在 Immich 建「荣耀70视频」相册做来源标记。
3) 生活视频图片：移出非媒体
- 共移出 193 个非媒体文件（pdf 49、epub 46、zip 34、m4a 16、docx、pptx、apk、mp3 等），约 477MB。
- 去向：
/volume2/Inbox/photo_extras/生活视频图片/（保留原相对路径）。 - NEF（尼康 RAW）、MTS（婚礼视频）视为媒体保留。
- 媒体部分保持事件文件夹（婚礼/大理等），不拍平到年月。
4) 2026-2 查重后并入 2026
2026-2 为完全扁平的 1888 个文件（微信/反馈图，几乎无日期命名；mtime 全是复制月，不可用于判拍摄月）。
脚本 /tmp/merge2026fast.py（本机副本 AppData\Local\Temp\merge2026fast.py）：
- 快速指纹 = size + 前 2MB + 后 2MB sha256；
- 判定为重复的候选，移动前再做全文件 SHA256 最终确认，防误删。
结果：
| 类别 | 数量 | 处理 |
|---|---|---|
| 与 2026 完全重复 | 254 | 入 _dup_trash/2026-2/ |
| 2026-2 内部重复 | 399 | 入 _dup_trash/2026-2/ |
| 独有文件 | 1235 | 并入 2026/10/（无日期统一10月） |
- 已入 trash 653、已并入 1235，快判误报 0。
- 并入后
2026/共 1731 个文件（01~10 各月子目录）。 2026-2/仅剩 @eaDir（3054 个缩略图）和空目录「1」，可整体删除。
第二批（同日 19:10）：2026-2 又出现 132 个新文件（jpg 100、png 16、mov 11、heic 3、mp4 2，约 918MB）。脚本 /tmp/merge2026b.py（本机副本 AppData\Local\Temp\merge2026b.py）：与 2026 重复、内部重复两类判定均做全文件 SHA256 确认；trash 独立到 _dup_trash/2026-2-batch2/ 防覆盖；目标重名自动加 _uN 后缀。
| 类别 | 数量 | 处理 |
|---|---|---|
| 与 2026 完全重复 | 1（41.HEIC） | 入 _dup_trash/2026-2-batch2/ |
| 2026-2 内部重复 | 0 | — |
| 独有文件 | 131 | 并入 2026/10/ |
- 并入后
2026/共 1862 个文件（其中 10 月 1365），2026-2/真文件清零（仍有 @eaDir 与空目录「1」）。 - 用户选择不手动触发重扫，等 Immich 每日定时扫描自动入库。
5) 最终外部库配置（API 实测）
通过 /api/libraries 配置为 3 个外部库：
| 库名 | 导入路径（容器内） | 结果 |
|---|---|---|
| 家庭照片2014-2026 | /srv/photo/2014、2016、2018…2026（11 个年份目录，不含 2026-2） | 7727 |
| sisi's photos | /srv/photo/sisi's photos | 298 |
| 生活视频图片（事件） | /srv/photo/生活视频图片 | 2710 |
统一排除规则：
**/@eaDir/** **/._* **/#recycle/** **/#snapshot/**
**/.stversions/** **/.stfolder/** **/_dup_trash/**
**/*.aae **/*.db **/*.DS_Store
扫描后全服务器资产 10688（photos 9703 + videos 985）。
待办：
1. 删除 2026-2（仅剩 @eaDir/空目录）——属目录删除，需用户确认后执行。
2. 稳定 1~2 周后清空 _dup_trash（含本次新增 653 个）彻底释放空间。
3. 按需建相册：荣耀70视频、婚礼、大理旅行等。
十、踩坑汇总
- 不要凭记忆写镜像名：Immich 已换 valkey + vectorchord 定制 postgres，务必拉当期官方模板。
- Immich 不支持子路径反代，只能用独立子域名；泛解析 + 通配符证书已覆盖，无需额外 DNS/证书。
- 数据库目录必须放群晖本地卷，不能在 SMB/NFS 上。
- frpc 的
localPort对应端口映射左侧宿主机端口；容器内 2283 不可改。 - 外部库必须在 compose 里给 immich-server 加挂载，import path 填的是容器内路径（
/srv/photo/...），不是 NAS 路径；挂载用:ro。 - 群晖照片目录下有
@eaDir缩略图目录，外部库扫描要排除。 - 外部库元数据不回写文件、移动文件即丢元数据；照片备份优先用 App 自动备份。
- 首次启动 server 短暂 unhealthy、postgres health: starting 属数据库初始化，数分钟后自动转绿；长时间不恢复再查
docker logs immich_server。 - 外部库移动/改名物理文件后重扫 = 新资产，元数据丢、旧条目变离线；整理顺序应是"先整理文件、后扫描"，已打标签的目录少动路径。
- 群晖 Photos 卸载不删 photo 共享文件夹与 homes 下的备份文件；但务必在卸载前完成复制+扫描+手机 App 全量补备份。
- 当年群晖 Photos 上传失败的文件只在手机本地，NAS 上不存在，唯一补救方式是 Immich App 对整个相机胶卷做自动备份。
- 方案 B 移动 library 必须用 SSH
mv（保留属主权限），不能用 SMB 剪切；外部库导入路径绝不能包含_immich_upload，否则重复索引。