Docker 目录权限
镜像默认使用 10001:10001 运行,媒体目录只读,数据目录可写。启动失败先查看日志,区分 /data 写权限、/media 读权限、目录不存在与重复实例锁。
数据库通过 SQLCipher 加密,密钥在单独的 drama_keys Docker 卷。迁移旧数据库时保留 Compose 项目名及 drama_data、drama_keys 两个卷;备份恢复要成对保留数据库和密钥,不能单独重建密钥卷。
默认命名卷适合新安装。自定义 UID/GID 时,须同步为数据卷和媒体目录设置相应权限;不会自动重置已有卷的属主。
授权绑定数据不可用
这个提示表示应用无法取得本地设备标识,或无法读写授权绑定文件。它与网络连接失败不同,反复刷新页面无法修复挂载或权限问题。
在 NAS 的容器终端中,以应用默认用户 10001:10001 执行下面的只读检查。命令只显示检查结果、路径和权限,不输出机器标识、密码或密钥内容:
sh
id
if [ -n "$ACTIVATION_DEVICE_ID" ]; then
echo "已配置设备标识环境变量(不显示内容)"
else
for p in /etc/machine-id /var/lib/dbus/machine-id; do
if [ -f "$p" ] && [ -r "$p" ] && [ -s "$p" ]; then
echo "$p: 存在、可读且非空"
else
echo "$p: 缺失、不可读、为空或不是文件"
fi
done
fi
binding_file="${ACTIVATION_DEVICE_BINDING_FILE:-${DRAMA_DATA_DIR:-/data}/keys/device-binding.key}"
ls -ld "${DRAMA_DATA_DIR:-/data}" "${binding_file%/*}" "$binding_file"- 两个机器标识文件都不可用:核对 Compose 是否保留了
/etc/machine-id:/etc/machine-id:ro。挂载来源必须是 NAS 上真实、非空且应用可读的机器标识文件。如果路径实际是目录,需先确认主机系统提供的正确文件路径。修正挂载后重建容器,保留原项目名和数据卷。 - 绑定文件或目录权限异常:默认文件位于
/data/keys/device-binding.key。应用用户需要能读写文件、在父目录创建文件,并将父目录权限设为700;已有绑定文件不能开放组或其他用户访问。自定义路径时检查对应目录,避免放在容器只读层或只读挂载中。 - 文件不存在:应用会在首次需要授权绑定时创建它;如果创建失败,应检查父目录权限。不要通过删除原绑定文件、重建密钥卷、填入随意的设备标识来修复,这些操作可能改变已有授权的绑定值。
上述检查用于定位当前实例,不能替代跨设备的授权换绑。提供检查结果时无需发送任何文件内容。
使用宿主数据目录
创建仅用于本应用的数据目录,在 .env 设置 DATA_DIR,使用绑定挂载配置:
sh
docker compose -f compose.yaml -f compose.bind.yaml up -d在普通 Linux 上,确认目录只属于此应用后,可在本机为它设置配置的 UID/GID:
sh
sudo chown -R 10001:10001 /你的独立应用数据目录
sudo chmod -R u+rwX /你的独立应用数据目录不要对共享媒体根目录、整块硬盘或其他应用目录执行上述命令。NAS 使用其文件权限界面授予应用读取媒体和写入独立数据目录的权限。Rootless Docker、用户命名空间及 Docker Desktop 的宿主映射不同,不能照搬 Linux UID。
媒体属于特定组时,可在 Compose 为 drama 增加 group_add,填写该组的数字 GID。不要为读取文件而启用 privileged 或挂载 Docker Socket。
数据目录被占用
日志出现「已有服务或迁移进程运行」时,停止正在使用同一数据卷的旧容器,再启动新服务。锁文件本身不代表仍有进程运行,不能通过删除锁文件来绕过检查。