OFFSET偏移
← 文章目录OFFSET / FIELD NOTESNO. 132

NixOS 上的 Distrobox:包环境与宿主路径

在声明式宿主上配置 rootless 后端,诊断 Nix profile、图形与传统用户空间的边界。

所在专题Distrobox:用户空间、桌面集成与可恢复环境 ↗
约 34 分钟阅读开始阅读

本文的命令接口按 Distrobox 1.8.2.5 官方脚本核对;镜像标签与发行版包名是示例,使用前确认镜像仍受支持、仓库可用及本机实际版本。示例未做运行验证。

NixOS 通过声明式配置和只读 Nix store 管理软件;整个根文件系统并非全部不可写。Distrobox 在这个基础上提供传统发行版用户空间,适合需要原生 apt/pacman 生态或 FHS 假设的应用。

1. NixOS 为什么需要 Distrobox?#

1.1 不可变带来的两面性

NixOS 的核心理念是通过 /nix/store/ 实现声明式系统管理:所有软件被隔离在哈希路径下,通过符号链接拼装出最终的系统视图。这带来了:

  • 可复现性:锁文件固定 Nix 输入,结合配置可重建声明部分;用户数据、容器状态和外部资源需另行恢复
  • 原子升级/回滚:每次 rebuild 生成新的 system generation
  • 多版本共存:同一软件的不同版本可以互不干扰地存在

但代价也很明显:

问题 具体表现
FHS 不兼容 NixOS 没有 /lib、/usr/lib、/bin/bash 等传统路径,不少预编译程序因 ELF loader 或动态库路径缺失而无法启动,常见报错是 No such file or directory,并非普遍段错误
打包成本高 要用某个软件,要么等 nixpkgs 收录,要么自己写 derivation
临时实验受阻 apt install / pacman -S 这些在传统发行版上理所当然的操作在 NixOS 上不可用
动态链接地狱 二进制软件依赖的标准库路径与 NixOS 格格不入,patchelf 虽能缓解但并非万能

1.2 nix-shell 能解决一部分,但不是全部

NixOS 提供了 nix-shell -p 和 nix shell nixpkgs#xxx 作为临时环境方案:

# 临时启动一个带 python 和 gcc 的环境
nix-shell -p python3 gcc

# 或者用 flakes 语法
nix shell nixpkgs#python3 nixpkgs#gcc

普通 nix-shell -p / nix shell 提供 Nix 包的环境变量和可执行路径,不会把文件系统变成传统 FHS 布局。软件不在 nixpkgs 时仍可写 derivation;预编译软件也可采用 nix-ld、autoPatchelfHook 或 buildFHSEnv。因此闭源程序不是“几乎无解”,只是这些路线的维护成本与传统发行版包不同。

Distrobox 的价值在于复用 Debian/Ubuntu、Arch/AUR、Fedora 等已有用户空间与包管理流程。选哪条路线取决于实际兼容性、维护频率和所需可复现程度,不宜按过时包数量判断。

1.3 Distrobox 的填补逻辑

Distrobox 在容器内运行一个完整的传统发行版用户空间,同时将宿主机的关键资源穿透进容器:

+---------------------------------------------------+
|  NixOS Host (declarative packages)                      |
|  - Kernel, drivers, DE/WM (Hyprland)              |
|  - Core CLI tools (fish, git, neovim via nix)     |
|  - Container runtime (Podman)                     |
|                                                    |
|  +-- Distrobox Container (Arch Linux)             |
|  |   - AUR packages (yay/paru)                    |
|  |   - FHS-compliant filesystem (/usr/lib, /lib)  |
|  |   - Conventional package manager (pacman)      |
|  |   - Shared $HOME with host                     |
|  |                                                |
|  +-- Distrobox Container (Ubuntu 22.04)           |
|  |   - Binary-only software (.deb packages)       |
|  |   - Legacy toolchains with FHS assumptions     |
|  |   - Shared Wayland socket for GUI apps         |
+---------------------------------------------------+

协同效应:NixOS 提供不可变的底层稳定性和可复现的系统配置;Distrobox 提供灵活可变的用户空间和传统包管理体验。两者互补而非互斥。

Distrobox 需要先有可用的容器后端;在 NixOS 上应分别验证 Podman rootless 配置、容器创建、guest 初始化与桌面集成。


2. 安装方式对比#

在 NixOS 上安装 Distrobox 有两种路线:声明式 Nix 安装 和 curl 脚本安装。

2.1 方式一:Nix 声明式安装(推荐)

这是符合 NixOS 哲学的安装方式,将 Distrobox 纳入系统或用户的 Nix 配置中管理。

系统级安装(configuration.nix)

# /etc/nixos/configuration.nix
{ config, pkgs, ... }:

{
  # 启用 Podman + Docker 兼容层
  virtualisation.podman = {
    enable = true;
    dockerCompat = true;        # 创建 docker -> podman 符号链接
    defaultNetwork.settings.dns_enabled = true;
  };

  # 安装 Distrobox(后端用 Podman)
  environment.systemPackages = with pkgs; [
    distrobox
    podman
  ];

  # Rootless 容器所需的 subuid/subgid 映射
  users.users.user = {
    subUidRanges = [
      { startUid = 100000; count = 65536; }
    ];
    subGidRanges = [
      { startGid = 100000; count = 65536; }
    ];
  };
}

配置应用分两步:先 dry-build 检查构建,再由操作者确认切换。以下 switch 会改变宿主状态:

nixos-rebuild dry-build
# 确认构建及配置后再应用:
# sudo nixos-rebuild switch

Home Manager 安装

# ~/nixos-config/home/packages.nix 或对应的 home.nix
{ config, pkgs, ... }:

{
  home.packages = with pkgs; [
    distrobox
    podman
  ];
}

先检查 Home Manager 构建,再由操作者决定应用;这仅安装用户包,不代替宿主 Podman/UID 配置:

home-manager build
# home-manager switch

Flake 开发 Shell 安装(临时使用)

如果不想持久安装,可以通过 flake 提供临时环境:

# flake.nix
{
  inputs = {
    nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
    flake-utils.url = "github:numtide/flake-utils";
  };

  outputs = { self, nixpkgs, flake-utils }:
    flake-utils.lib.eachDefaultSystem (system:
      let pkgs = nixpkgs.legacyPackages.${system};
      in {
        devShells.default = pkgs.mkShell {
          packages = with pkgs; [ distrobox podman ];
          shellHook = ''
            echo "Distrobox version: $(distrobox --version | head -1)"
          '';
        };
      });
}
nix develop
对比维度 Nix 声明式 curl 脚本
版本来源 nixpkgs(由锁定 revision 决定) upstream latest
更新方式 nix flake update + rebuild 手动重新执行 curl
可复现性 flake.lock 锁定 Nix 输入版本 浮动安装缺少锁定;固定源码也可管理版本
NixOS 合规 完全合规 不符合"一切变更经 Nix"原则
卸载方式 从配置中移除 + rebuild 手动删除二进制和配置
适用场景 日常使用、生产环境 尝鲜上游新特性、紧急修复

推荐策略 优先使用 Nix 声明式安装。如果 nixpkgs 中的 Distrobox 版本过旧且急需上游新特性,可以用 flake 锁定特定 nixpkgs revision 或 overlay 引入新版,而不是直接绕开 Nix。

2.2 方式二:curl 脚本安装(非声明式,不推荐)

curl -s https://raw.githubusercontent.com/89luca89/distrobox/main/install \
  | sh -s -- --prefix ~/.local

违反 NixOS 核心原则 这种方式安装的 Distrobox 不被 Nix 管理,nixos-rebuild 和 home-manager switch 不会感知它的存在。虽然它不会被 rebuild 覆盖(因为 Nix 不管理 ~/.local),但它也不享受声明式配置的版本锁定和可复现性。

手动安装可用于临时排障或比较上游版本,但应记录来源、避免 PATH 混用,验证后纳入声明式配置。


3. NixOS 特有的配置步骤#

NixOS 的文件系统布局与标准 Linux 发行版差异巨大,因此 Distrobox 在 NixOS 上的配置需要额外关注几个关键点。

3.1 Podman Rootless 配置

Rootless Podman 是 NixOS + Distrobox 组合的关键——它允许普通用户在不提权的情况下运行容器。

# /etc/nixos/configuration.nix
{ config, pkgs, ... }:

{
  virtualisation.podman = {
    enable = true;

    # 创建 docker -> podman 符号链接,兼容 docker 命令
    dockerCompat = true;

    # 为 rootless 容器启用 DNS
    defaultNetwork.settings.dns_enabled = true;
  };

  # 为用户分配 subordinate UID/GID 范围
  # 这是 rootless 容器的核心前提:容器内的 root (UID 0)
  # 被映射到宿主机的非特权 UID 范围
  users.users.user = {
    subUidRanges = [
      {
        startUid = 100000;   # 从属 UID 范围示例,实际映射取决于 userns/keep-id
        count = 65536;       # 映射 65536 个 UID(标准 /etc/subuid 长度)
      }
    ];
    subGidRanges = [
      {
        startGid = 100000;
        count = 65536;
      }
    ];
  };
}

subuid/subgid 范围必须与其他用户的分配不重叠,不能只照抄某个 startUid。读取生成的 /etc/subuid、/etc/subgid 以及实际 uid_map/gid_map 判断。rootless Podman 不以加入一个“podman”组为基本前提;访问设备或共享 socket 是另一层权限。

重建后验证:

nixos-rebuild dry-build
# 确认后应用:sudo nixos-rebuild switch
# 停止相关容器后再迁移,可能影响当前用户所有容器
podman system migrate           # 确保 rootless 模式迁移完成
podman run --rm hello-world     # 验证 rootless 容器可用

3.2 Distrobox 配置文件

创建 Distrobox 全局配置,明确指定 Podman 为容器后端:

mkdir -p ~/.config/distrobox
cat > ~/.config/distrobox/distrobox.conf << 'EOF'
container_manager="podman"
# 0/1 设置只用于当前版本支持的选项
container_always_pull=0
EOF

1.8.2.5 脚本没有 skip_workspace_init、container_stop_ok 这两个设置;把它们写入配置不会实现对应功能。不要全局启用 init;仅有长期服务需求的容器在 create/assemble 中设置。

也可以通过 Nix 声明式管理这个配置文件(推荐):

# 在 Home Manager 中:
xdg.configFile."distrobox/distrobox.conf".text = ''
  container_manager="podman"
  container_always_pull=0
'';

3.3 Nix Profile 路径暴露

共享 HOME 与 PATH 不保证所有 Nix profile 符号链接、ELF loader 和运行依赖都在 guest 同路径可用。先用 type -a、readlink -f、file 检查实际路径;优先以 host-exec 在宿主执行需要宿主服务的工具。确需在 guest 直接执行 Nix 包时,可按诊断结果只读挂载完整 /nix 与所需 profiles:

# 通过 Home Manager 设置额外的挂载路径
xdg.configFile."distrobox/distrobox.conf".text = ''
  container_manager="podman"
  container_additional_volumes="/nix:/nix:ro /etc/profiles/per-user:/etc/profiles/per-user:ro"
'';

安全注意 将 /nix 挂载为只读(:ro)是关键——容器内的包管理器(apt/pacman/dnf)不能也不应该修改宿主机的 Nix store。

3.4 Wayland 与 GPU 加速

Wayland 会话下,Distrobox 自动检测并转发 Wayland socket。

AMD / Intel GPU

Mesa 图形路径通常可通过设备与 socket 共享工作,但需验证 guest 库和设备权限:

# 确保图形栈已启用
{ config, pkgs, ... }:
{
  hardware.graphics.enable = true;   # 启用 Mesa、/dev/dri 等
}
# 创建容器后验证 GPU 直通
distrobox create --name gpu-test --image ubuntu:22.04
distrobox enter gpu-test
sudo apt update && sudo apt install -y mesa-utils
glxinfo | grep "OpenGL renderer"
# 预期输出包含真实的 GPU 型号,而非 "llvmpipe"

NVIDIA GPU

原笔记记录的是 2025 年中 NixOS CDI/FHS 适配问题,不能作为当前所有 nixpkgs revision 的结论。NVIDIA 驱动选项(包括 open kernel module 适用硬件)、CDI 生成器与容器运行时必须按锁定 nixpkgs 和实际驱动核对;下面是配置形状而非任意硬件可直接应用的完整配置。

如果使用 NVIDIA GPU,基本配置如下:

{ config, pkgs, ... }:
{
  hardware.nvidia = {
    # open = true;             # 按 GPU 世代和驱动支持选择
    modesetting.enable = true;   # 按桌面/驱动要求启用
  };
  hardware.nvidia-container-toolkit.enable = true;
  services.xserver.videoDrivers = [ "nvidia" ];
}

由对应 NixOS 模块管理 CDI 生成与更新,再检查生成的 device 列表。不要用手写 /etc 文件替代声明式配置;可把诊断输出放到临时文件。容器创建示例仅在 CDI 设备存在后适用:

systemctl status nvidia-container-toolkit-cdi-generator.service
# 按当前 nixpkgs 文档检查模块生成的 CDI;路径仍应与锁定 revision 核对
nix run nixpkgs#jq -- -r '.devices[].name' < /var/run/cdi/nvidia-container-toolkit.json
# 已安装相应工具时也可使用 nvidia-ctk cdi list
# 诊断输出(是否需权限由驱动/版本决定):
# nvidia-ctk cdi generate --output=/tmp/nvidia-cdi-diagnostic.yaml
distrobox create --name cuda-box --image nvidia/cuda:12.4.0-devel-ubuntu22.04 \
  --additional-flags "--device nvidia.com/gpu=all --security-opt=label=disable"

3.5 NixOS 独有的怪癖与注意事项

怪癖 原因 处理方式
宿主机无 /bin/bash NixOS 将 bash 放在 /nix/store/*/bin/bash 容器自带 shell,不影响使用
$HOME 在容器内外共享 Distrobox 默认挂载 HOME 不要在容器内 sudo 修改 HOME 下由 Nix 管理的文件
容器内无法执行宿主机 Nix 二进制 库路径不同 需要时检查符号链接和 ELF loader,必要时只读挂载完整 /nix;服务相关工具用 host-exec
distrobox-host-exec 行为 从容器执行宿主机命令 宿主机需在 $PATH 中有对应程序;在 NixOS 上可能需指定完整路径
Shell 集成 宿主机使用 fish,容器内可用任何 shell distrobox-enter 对 fish/bash/zsh 均支持良好

4. NixOS + Distrobox 最佳实践#

4.1 分工原则:什么放 Nix,什么放 Distrobox

NixOS 层(声明式软件与系统配置)
├── 系统核心:kernel, systemd, bootloader
├── 驱动层:GPU drivers, firmware, 硬件管理
├── DE/WM:Hyprland, waybar, rofi
├── 核心 CLI:git, fish, neovim, tmux, fzf
├── 开发语言运行时(可选):rustup, go, python(通过 nix shell)
└── 容器运行时:podman, distrobox

Distrobox 层(可变)
├── AUR 包:yay, paru, 小众工具
├── 二进制闭源软件:微信(deepin-wine)、Teams、FPGA 工具
├── FHS 依赖的开发环境:某些嵌入式交叉编译工具链
├── 快速实验:临时测试某个工具而不污染 Nix 环境
└── 特定发行版工具:需要特定版本 glibc 或库的旧程序

判断规则 在决定用 Nix 还是 Distrobox 时,依次问自己:

  1. 这个工具在 nixpkgs 中吗? → 是 → 用 Nix
  2. 需要频繁更新/实验吗? → 是 → 考虑 Distrobox
  3. 是二进制闭源软件或强制要求 FHS 吗? → 是 → 用 Distrobox
  4. 是系统核心组件(驱动、内核模块)吗? → 是 → 必须用 Nix

4.2 推荐工作流

工作流一:AUR 辅助

在 NixOS 上使用 Arch Linux 的 AUR 生态:

# 1. 创建 Arch 容器,预装构建工具链
distrobox create --name aur-space --image archlinux:latest \
  --additional-packages "base-devel git"
distrobox enter aur-space

# 2. 在容器内安装 AUR helper
sudo pacman -Syu --needed git base-devel
git clone https://aur.archlinux.org/paru.git
cd paru
# 先审查 PKGBUILD 与下载源,再以普通 guest 用户构建
makepkg -si

# 3. 正常使用 AUR
paru -S some-aur-package

工作流二:运行 FHS 依赖的二进制

# 为需要经典 Linux 文件系统的程序创建 Ubuntu 容器
distrobox create --name fhs-runner --image ubuntu:22.04
distrobox enter fhs-runner

# 在容器内安装依赖
sudo apt update && sudo apt install -y libssl3 libgtk-3-0

# 运行宿主机的预编译二进制(通过 HOME 共享)
./some-binary-that-expects-fhs

工作流三:隔离的开发环境(按项目)

# Python 项目 —— Fedora 有较新的 Python 版本
distrobox create --name proj-ml --image fedora:latest \
  --additional-packages "python3 python3-pip python3-devel gcc"

# Rust 项目 —— Arch 滚动更新适合 Rust 工具链
distrobox create --name proj-rust --image archlinux:latest \
  --additional-packages "rustup mold gcc"

# C/C++ 遗留项目 —— Ubuntu LTS 稳定性最好
distrobox create --name proj-legacy-cpp --image ubuntu:22.04 \
  --additional-packages "build-essential cmake gdb"

工作流四:在 Distrobox 中导出应用到宿主机

# 在容器中安装 GUI 应用
distrobox enter aur-space
paru -S freecad

# 导出 .desktop 文件到宿主机
distrobox-export --app freecad

# 宿主机上现在可以直接从启动器打开 FreeCAD
# Wayland socket 自动转发,无需额外配置

4.3 边界与禁忌

不要做的事情

禁忌操作 原因
在 Distrobox 内 sudo 修改 $HOME 下的文件 HOME 与宿主机共享,可能破坏 Nix 管理的配置文件
无意中在共享路径安装第二套 Nix 独立 Nix 测试有合理用途,但要明确 store、daemon 和 HOME 边界
用一个"全能容器"装所有东西 包环境职责混杂,出了问题难以定位
在 Distrobox 内修改宿主机 /etc 即使技术上可行(挂载写入),会绕过配置管理,部分生成文件可能被重建覆盖,其他修改则可能残留
用 Distrobox 替代 Nix 安装系统工具 Git、编辑器等核心工具应走 Nix,享受声明式管理

应该做的事情

推荐实践 理由
按用途(语言、项目、工具类别)创建独立容器 环境隔离、干净卸载
用 distrobox-export 导出常用应用 无缝融入宿主机桌面体验
定期 distrobox upgrade --all 保持容器内软件更新
用 ~/.config/distrobox/distrobox.conf 统一管理配置 避免每次创建容器时重复设置
仅有 init 服务需求时设置 --init 普通开发容器不必增加服务管理复杂度

4.4 常见容器镜像选择

场景 推荐镜像 理由
AUR 包、滚动更新 archlinux:latest pacman + AUR 生态最丰富
兼容性、二进制软件 ubuntu:22.04 或 ubuntu:24.04 FHS 最标准,商业软件支持最好
较新的工具链 fedora:latest 包版本新但不过于激进
最小化、脚本自动化 alpine:latest 体积最小,适合 CI/脚本
科学计算、数据科学 nvidia/cuda:*-devel-ubuntu* 预装 CUDA 工具链

5. 故障排查#

5.1 potentially insufficient UIDs or GIDs

症状:创建容器时报错 Error: potentially insufficient UIDs or GIDs available in user namespace。

可能原因:未分配或范围不足、范围重叠,或现有 rootless pause 进程仍使用旧映射。

解决:

# 在 configuration.nix 中确认以下配置已存在:
users.users.user.subUidRanges = [
  { startUid = 100000; count = 65536; }
];
users.users.user.subGidRanges = [
  { startGid = 100000; count = 65536; }
];

重建后执行 podman system migrate。

5.2 容器内 $HOME 配置冲突

症状:进入容器后,shell 配置(如 .bashrc、.config/fish/)行为异常,或 Nix 安装的 CLI 工具报错。

原因:Distrobox 默认共享 $HOME,宿主机的 shell 配置和容器内的 shell 可能互相干扰。

解决:在容器的 ~/.bashrc 或 ~/.profile 中做判断:

# ~/.bashrc 或对应的 shell 配置
if [ -n "$CONTAINER_ID" ]; then
  # 在 Distrobox 容器内 —— 使用容器内路径
  export PATH="/usr/local/bin:/usr/bin:/bin:$HOME/.local/bin"
else
  # 在宿主机 —— 保持 Nix 路径
  # (此处内容不动)
fi

5.3 Wayland GUI 应用无法启动

症状:distrobox-export --app 导出后,GUI 应用黑屏或无响应。

排查步骤:

# 1. 确认宿主机 Wayland 环境变量
echo $WAYLAND_DISPLAY
echo $XDG_RUNTIME_DIR

# 2. 在容器内验证 Wayland socket 可见
distrobox enter your-box
ls -la $XDG_RUNTIME_DIR/$WAYLAND_DISPLAY

# 3. xeyes 验证 X11/XWayland,不单独证明原生 Wayland 通路
sudo apt install -y x11-apps
xeyes  # 应该弹出窗口

如果 socket 不可见,检查 ~/.config/distrobox/distrobox.conf 中是否误配置了挂载覆盖。

5.4 容器无法访问网络

症状:容器内 ping 或 apt update 失败,但宿主机网络正常。

排查:默认 Distrobox 使用宿主网络,先检查 guest resolv.conf 和宿主 DNS;只有 unshare-netns/自定义网络才主要检查 Podman 网络 DNS。

# 检查 Podman 网络
podman network ls
podman network inspect podman
# 默认 host 网络的 Distrobox 不走这个独立网络;需先检查实际 NetworkMode

# 确保 NixOS 配置中 DNS 已启用
# configuration.nix:
#   virtualisation.podman.defaultNetwork.settings.dns_enabled = true;

5.5 NVIDIA GPU 在容器内不可见

症状:nvidia-smi 报错 "NVIDIA-SMI has failed"。

历史手工诊断思路:设备与驱动库必须匹配;NixOS 驱动目录里的符号链接可能继续指向 /nix/store,仅挂载 /run/opengl-driver 不足。优先验证 --nvidia 或已生成的 CDI,下面的手工挂载不是通用修复:

# 备选方案:手动挂载 NVIDIA 库
distrobox create --name nvidia-box --image ubuntu:22.04 \
  --additional-flags "
    --device /dev/nvidia0
    --device /dev/nvidiactl
    --device /dev/nvidia-modeset
    --device /dev/nvidia-uvm
    --volume /run/opengl-driver:/run/opengl-driver:ro
  "

# 在容器内
export LD_LIBRARY_PATH=/run/opengl-driver/lib:$LD_LIBRARY_PATH

AMD/Intel 用户不需要 NVIDIA 专用设备配置,但仍应分别验证 Mesa 图形、OpenCL/ROCm 等实际工作负载;图形窗口可见不等于计算框架获得加速。


6. 小结#

NixOS 和 Distrobox 是互补关系,不是替代关系:

  • NixOS 声明式管理系统基础层:内核、驱动、桌面环境、核心工具链——通过声明式配置保证可复现和可回滚。
  • Distrobox 提供可变的应用层:传统包管理、二进制闭源软件、AUR 生态——把 guest 包管理与宿主 Nix 包管理分开;共享 HOME 和宿主调用仍可改变宿主状态。

对于 NixOS 用户而言,学会在 Nix 环境和 Distrobox 容器之间自如切换,意味着同时拥有了声明式系统管理的稳定性和传统 Linux 发行版的灵活性。这是 NixOS 区别于其他不可变发行版(Fedora Silverblue、openSUSE MicroOS)的独特优势:你不是在被"锁定",而是在自由地选择每一层用什么工具来管理。

进一步阅读



参考与延伸

  1. Distrobox security implications ↗
  2. Distrobox create ↗
  3. Distrobox enter ↗
  4. Nixpkgs NVIDIA toolkit module ↗
  5. Nixpkgs CUDA container documentation ↗
  6. Nixpkgs Podman module ↗
  7. Distrobox 1.8.2.5 create implementation ↗
  8. NVIDIA CDI ↗

根据技术笔记重新整理,示例使用通用名称。

沿专题继续阅读

Distrobox:用户空间、桌面集成与可恢复环境

  1. 01Distrobox 核心原理:用户空间与宿主集成
  2. 02Distrobox 安装与后端配置
  3. 03Distrobox 镜像与容器生命周期
  4. 04Distrobox 导出的,到底是什么?
  5. 05Distrobox 桌面发现与后台服务集成
  6. 06Distrobox 声明式清单与高级工作流
  7. 07NixOS 上的 Distrobox:包环境与宿主路径
  8. 08Distrobox 备份:镜像、包清单与共享数据
  9. 09Distrobox 内部机制:包、配置与命令解析
CONTINUE READING / 下一篇Distrobox 备份:镜像、包清单与共享数据

用三种互补方式保存 guest 环境,并明确共享目录和应用数据的独立恢复责任。