挂载本身不负责安装，而是为离线安装提供持久化运行环境；需挂载插件目录、配置目录，数据库用命名卷，离线包放只读挂载区，再通过初始化脚本解压启用。
直接用 Docker 持久化挂载实现“容器内应用的离线安装”，这个说法存在概念混淆——挂载本身不负责安装，而是为离线安装提供可复用、可保留的运行环境。真正要做的，是把离线资源（如 Nextcloud 插件包、配置文件、数据库数据等）通过挂载方式注入容器，并在容器启动时完成初始化或启用。下面分三块讲清楚怎么做、为什么这么设计、以及关键避坑点。
明确挂载目标：哪些内容必须持久化才能支撑离线安装
离线安装不是“把安装包扔进容器就完事”，而是确保每次容器重启后，已安装的应用、配置、用户数据都不丢失。这就要求你把以下几类内容挂载到宿主机：
-
应用插件目录：比如 Nextcloud 的
/var/www/html/apps，挂载到宿主机/opt/nc-data/apps，这样你手动解压 richdocuments 到宿主机目录后，容器一启动就自动可用； -
配置文件目录：如
/var/www/html/config，挂载为/opt/nc-data/config，避免每次重建容器都重置 admin 密码或数据库连接信息； -
数据卷（非挂载目录）：MySQL 数据库建议用命名卷（
docker volume create nc-db），而不是 bind mount，防止权限错乱和误删； -
离线资源暂存区（可选）：比如建个
/opt/nc-offline-pkgs目录，挂载进容器的/tmp/offline，方便脚本从中复制并解压插件。
典型操作流程：以 Nextcloud 安装 onlyoffice 插件为例
整个过程不依赖容器联网，全靠挂载 + 脚本驱动：
- 在外网机器下载
onlyoffice.tar.gz，校验 SHA256 后拷贝到宿主机/opt/nc-offline-pkgs/； - 启动 Nextcloud 容器时，用
-v /opt/nc-offline-pkgs:/tmp/offline:ro和-v /opt/nc-data/apps:/var/www/html/apps两个挂载； - 容器内执行初始化脚本（可通过
entrypoint.sh或docker exec触发）：tar -xzf /tmp/offline/onlyoffice.tar.gz -C /var/www/html/apps/sudo -u www-data php occ app:enable onlyoffice； - 后续重启容器，插件仍处于启用状态，因为 apps 目录和 config 都是持久化的。
必须检查的三项权限与路径细节
挂载后离线安装失败，90% 出在以下三点：
- UID/GID 匹配：Nextcloud 容器内 www-data 用户默认 UID=33，宿主机挂载目录需属组/属主设为 33，否则插件解压后无法被 PHP 进程读取；
-
SELinux 或 AppArmor 限制：CentOS/RHEL 环境下，挂载目录需加
:z或:Z标签（如-v /opt/nc-data:/var/www/html:z），否则容器无权写入； -
路径层级不能跨挂载点：不要把
/opt/nc-data挂载成/var/www，再单独挂载/var/www/html/config—— systemd 或容器引擎可能拒绝嵌套挂载，统一挂载/var/www/html更稳妥。
进阶建议：用 docker-compose 统一管理挂载与初始化
比起反复敲 docker run，推荐用 docker-compose.yml 固化离线部署逻辑：
- 定义 volumes 映射关系，含只读资源区（
offline-pkgs:ro）和读写应用区（nc-apps）； - 用
command:覆盖默认启动命令，先运行自定义 shell 脚本完成插件解压+启用，再 exec php-fpm； - 配合
depends_on和健康检查，确保数据库就绪后再执行应用初始化。
