重启后容器没起来

适用范围

NAS 重启，或者断电恢复之后，一部分或全部容器没有自动运行：docker ps 里看不到它们，或者状态是 Exited。

不适用：手动点上线也失败，见容器启动失败。

开始排查前

先理清开机时的先后顺序：

数据盘挂载（/srv/dev-disk-by-uuid-…）→ Docker 引擎启动 → 容器按重启策略恢复

• 容器开机之后能不能自动起来，取决于 compose 文件里的 restart 策略，这是 Docker 引擎自己的行为，不是 Compose 插件在开机时逐个「上线」。
• Compose 插件给 docker.service 加了一个附加配置，让它在 /srv 下所有挂载单元之后启动，另外有一个可选的启动延迟（Start delay）。

本页的改动会让容器重启

影响范围：修改 compose 文件的 restart 策略、Compose 设置里的启动延迟或 Docker 存储，都会重建容器或重启 Docker，应用会短暂中断。

前置条件：先记下改动之前的值；数据库类应用先备份，见更新与备份容器。

回退办法：把改动的值改回去，重新点上线，或者在 服务 → Compose → 设置（Services → Compose → Settings）里点重启 Docker。

排查步骤

1. 先看 Docker 引擎有没有起来

# 在 OMV 的 shell 里执行（只读）
systemctl status docker --no-pager
journalctl -u docker -b --no-pager | tail -n 40
docker ps -a

• Docker 没起来：日志里会写原因，常见的有 Docker 存储所在的磁盘没挂载或已满、/etc/docker/daemon.json 有错误，见容器启动失败的第 6 节。
• Docker 起来了，但 docker ps -a 里一个容器都没有：要警惕。可能是 Docker 启动时，它的存储所在的数据盘还没有挂载，Docker 在挂载点目录下新建了一个空的存储。先不要继续操作，确认磁盘的挂载状态：

# 在 OMV 的 shell 里执行（只读）；<UUID> 换成存放 Docker 存储的数据盘的 UUID
findmnt /srv/dev-disk-by-uuid-<UUID>

没有输出，说明盘没挂上，见磁盘或文件系统不见了。盘挂上之后，在 服务 → Compose → 设置 里点重启 Docker，原来的容器通常就回来了。盘没挂上期间写进系统盘的数据，处理方法见系统盘满了的第 4 节。

2. 检查重启策略

打开 compose 文件，看每个服务有没有 restart：

services:
  app:
    restart: unless-stopped

• 没有 restart：默认是 no，NAS 重启之后这个容器不会自动起来。加上 restart: unless-stopped，保存后点上线，让改动生效。
• unless-stopped：除非你手动停止过，否则开机会自动起来。你用停止或下线操作过的容器，重启后不会再起来。
• always：无论如何都会随 Docker 一起启动，包括手动停止过的。

omv-extras 的文档里，示例也是用 restart: unless-stopped，并解释为「除非你手动停止，否则总是启动」。

3. 检查计划任务有没有碰上重启

Compose 的计划任务里，备份和更新会先停止容器，做完再启动。如果 NAS 恰好在备份期间重启或断电，容器已经被「停止」过，使用 unless-stopped 的容器就不会自动恢复。

1. 看 服务 → Compose → 计划（Services → Compose → Schedule）里任务的执行时间，避开系统的重启、关机或休眠计划。
2. 查看这几个任务的日志：/var/log/omv-compose-backup.log、/var/log/omv-compose-update.log、/var/log/omv-compose-start.log、/var/log/omv-compose-stop.log。

4. 检查启动顺序：数据盘和 Docker

如果数据盘比 Docker 晚就绪（USB 或外接硬盘、阵列组装较慢、加密卷需要解锁），容器启动时路径不存在，就会失败，或者把数据写到系统盘上。

先看 Docker 到底排在谁后面：

# 在 OMV 的 shell 里执行（只读）
systemd-analyze critical-chain docker.service

Compose 插件让 Docker 在 /srv 下所有挂载单元之后启动，但这是弱依赖（Wants）：挂载失败时，Docker 仍然会启动，不会一直等。盘慢但最终能挂上的情况，可以用启动延迟：

1. 打开 服务 → Compose → 设置（Services → Compose → Settings）。
2. 找到启动延迟（Start delay），单位是秒，范围 0 到 300，默认 0。界面上的说明是：如果容器因为存储没能及时就绪而启动失败，就用这个选项。
3. 填一个合适的值（例如 60），保存，点应用。

启动延迟只能解决「慢」的问题，解决不了「盘没挂上」。盘没挂上要先让磁盘稳定，见磁盘或文件系统不见了。

5. 应用自己的依赖

容器起来之后又退出，要看应用自己的日志：数据库还没就绪、需要联网却还没有网络、DNS 没好。对依赖数据库的应用，在 compose 里用 depends_on 配合健康检查，并保留重启策略，让它在数据库就绪之后重试。

确认恢复

1. 重启 NAS，不做任何手动操作，等几分钟。
2. docker ps 里预期的容器都是 Up，服务 → Compose → 文件（Services → Compose → Files）里状态是「上线」。
3. 应用能正常访问。
4. 再重启一次，确认两次都正常。

仍未解决

附上：compose 文件里 restart 的部分、systemd-analyze critical-chain docker.service 的输出、journalctl -b -u docker 的开头部分、相关挂载的 findmnt 输出、docker ps -a，以及这台机器的启动顺序里有哪些外接或网络存储。读如何有效求助。

参考资料

• omv-extras wiki：Docker in OMV，其中解释了 compose 文件里的 restart 字段
• 本站：Compose 插件设置详解、写好 compose 文件：卷、端口、环境变量与网络