第一天不要急着迁主力服务，先验证路径、权限、端口和重启行为。

\n
FNOS 上手跑 Docker 的第一天，我不会急着迁主力服务。新的宿主机最需要先摸清四件事：应用目录在哪里，Docker 项目路径怎么管理，权限继承是什么样，备份从哪里下手。先用低风险容器跑通这些基础，再迁长期服务，会少很多返工。

先确认应用目录

不同系统对应用、共享目录和用户数据的组织方式不一样。FNOS 面板里看到的路径，和命令行里真实路径可能不是同一种表达。第一天要做的不是装很多服务，而是找出 Docker 项目默认放在哪里、手动创建的目录在哪里、哪些目录会被系统备份或快照覆盖。

我会先建一个统一根目录，比如专门放 compose 项目、配置、数据和备份的区域。目录结构不需要复杂，但要稳定：一个服务一个项目目录，项目里再区分 compose.yml、config、data、backup 或 cache。不要让面板创建的项目散落在不同位置，否则后续迁移和排障会变成找文件游戏。

Docker 项目路径要可复现

面板能创建容器，命令行也能管理 compose。两边都能用时，更要约定谁是事实来源。我更倾向把 compose 文件放在项目目录里，面板只作为查看和辅助操作入口。所有挂载路径尽量写成清楚的绝对路径，或者让相对路径只相对项目目录生效。

测试时可以跑一个简单 Nginx 或 whoami 容器，挂载一个只读 html 目录，再确认页面能访问。这个测试看似简单，却能验证端口映射、目录挂载、重启策略和日志位置。主力服务迁移前，先用低风险容器把平台行为摸清，比直接迁数据库或照片服务安全得多。

权限继承要用数字核对

NAS 系统常见问题就是权限看起来给了，容器里仍然不能写。面板创建目录、共享文件夹权限、Docker 运行用户、容器内用户之间可能有多层映射。第一天就应该用 id、ls -ln、stat 这类方式看数字 uid/gid，而不是只看用户名。

如果一个服务需要写配置目录，就让它只写自己的目录；如果只读取资料，就尽量只读挂载。不要用过度宽松权限掩盖问题。权限一旦放大，短期能跑，长期会让多个服务互相污染文件属主。FNOS 的目录权限规则摸清后，再迁复杂服务会更稳。

端口和访问范围分层测试

容器内服务启动、宿主机本机访问、局域网访问，是三件不同的事。第一天我会按层测试：容器是否运行，宿主机端口是否监听，同网段设备是否能打开，重启后是否自动恢复。如果前面还有反向入口或防火墙，也要单独记录规则。

端口规划也要提前写。HomeLab 服务越来越多后，随手映射端口会很快冲突。可以按用途分段：管理工具一段，生活服务一段，测试服务一段。至少要有一张端口表，写清服务名、宿主机端口、容器端口、访问范围和是否需要认证。

备份从第一天开始

新系统最容易忽略备份，因为“还没什么数据”。但目录结构、compose 文件和权限规则一旦确定，就已经值得备份。第一天至少要确认配置目录能被复制出来，项目目录能整体打包，关键服务的数据目录未来会进哪套备份任务。

正式迁移前，我会留下第一天的基线记录：系统版本、Docker 版本、项目根目录、测试容器 compose、端口访问结果、目录权限样例和备份计划。FNOS 能不能稳定跑 HomeLab，不取决于第一天装了多少应用，而取决于这些基础规则是否清楚。

日志位置也要在第一天弄明白。面板能看到一部分日志，但命令行里 docker logs、compose 项目日志和系统事件可能分散在不同入口。遇到服务没反应时，知道去哪看日志，比多装一个管理工具更重要。我会用测试容器故意输出几行日志，确认面板和命令行看到的是同一件事。

最后再测一次重启。手动重启容器、重启 Docker 服务、重启整台机器，结果可能不同。主力服务迁进来之前，先确认低风险容器在整机重启后能按预期恢复，挂载目录没有变，端口仍然可访问。这个动作很朴素，却能提前发现很多启动顺序和路径问题。

我还会在第一天就写一份端口和目录小表。服务名、项目路径、宿主机端口、容器端口、访问范围、备份状态各占一列。以后新增服务就照表补，不靠脑子记。表格不需要复杂，但它能避免端口冲突和目录散落。

如果面板支持导出项目配置，也要试一次。能导出、能读懂、能和本地 compose 对上，后续迁移才不慌。