强制卸载Snap版Docker：解决快照保存卡住的终极指南

1. 为什么Snap版Docker卸载会卡在快照保存？

最近在帮同事处理服务器问题时，遇到了一个典型场景：用sudo snap remove docker命令卸载Docker时，终端一直卡在"Save data of snap docker in automatic snapshot set #3"的提示。这种情况其实很常见，特别是当系统中有大量容器镜像或卷数据时。我后来发现，这本质上是Snap的自动快照机制与Docker存储结构的兼容性问题。

Snap设计了一套完善的数据保护机制，每次卸载应用前会自动创建快照。但对于Docker这种会产生大量动态数据的服务，快照过程可能遇到两个致命问题：首先是/var/snap/docker目录下的overlay2存储驱动数据量过大，其次是正在运行的容器进程会锁定某些文件。有次我在生产环境就遇到过20GB的Docker数据导致快照超时的情况，最终只能强制中断。

2. 强制卸载前的必要准备

2.1 检查Docker运行状态

在开始任何卸载操作前，建议先用这三个命令确认当前状态：

docker ps -a # 查看所有容器 docker volume ls # 列出数据卷 sudo snap list # 确认snap安装的docker版本

上周处理的一个案例特别典型：用户以为Docker已经停止，但实际上还有个MySQL容器在后台运行。这导致后续的快照操作一直卡在文件锁定状态。正确的做法是先完整停止所有容器：

docker stop $(docker ps -q) # 停止所有运行中的容器 docker system prune -a # 清理所有未使用的资源

2.2 备份关键数据

虽然我们要强制卸载，但重要数据还是要备份。Docker的数据主要存放在三个位置：

• /var/snap/docker/common/var-lib-docker：默认存储驱动数据
• /var/snap/docker/current：当前版本配置
• /home/你的用户/.docker：客户端配置

建议用rsync进行快速备份：

sudo rsync -av /var/snap/docker/ ~/docker_backup/

3. 分步强制卸载方案

3.1 彻底停止Snap服务

常规的systemctl stop snapd有时不够彻底，我推荐组合拳：

sudo systemctl stop snapd.service sudo systemctl disable snapd.socket sudo pkill -9 snapd

有次在Ubuntu 20.04上，即使这样还是有snapd子进程残留。这时候需要检查：

ps aux | grep snapd

如果发现残留进程，直接用kill -9 [PID]结束。

3.2 清除快照数据

Snap的快照数据存放在/var/lib/snapd/snapshots，但直接删除可能不够。我建议先列出所有docker相关快照：

sudo snap saved --id | grep docker

然后用这个命令删除特定快照：

sudo snap forget [快照ID]

3.3 深度清理残留文件

除了常见的/var/snap/docker，这些隐藏目录也需要清理：

sudo rm -rf /var/lib/snapd/cache/* sudo rm -rf /var/lib/snapd/void/* sudo rm -rf /tmp/snap.*

特别注意：如果之前修改过Docker的存储路径，还需要检查/etc/docker/daemon.json中定义的data-root位置。

4. 验证与后续处理

4.1 确认卸载结果

执行完所有步骤后，建议用这些命令交叉验证：

which docker # 检查二进制文件 docker --version # 验证命令是否失效 sudo snap services # 查看snap服务状态

4.2 替代安装方案

如果仍需使用Docker，我推荐官方APT源安装：

sudo apt-get update sudo apt-get install docker.io

这种安装方式比Snap版更易管理，存储结构也更透明。最近在测试服务器上对比发现，APT版的Docker启动速度比Snap版快约30%。

5. 疑难问题排查

遇到特别顽固的残留时，可以检查systemd单元文件：

systemctl list-unit-files | grep docker

有时候旧的service文件会阻止新安装。另外推荐使用lsof命令查找被锁定的文件：

sudo lsof /var/lib/snapd/snaps/docker*

有次在AWS EC2实例上，发现是apparmor导致了问题。这时候需要临时禁用apparmor profile：

sudo apparmor_parser -R /etc/apparmor.d/snap.docker.docker

最后提醒下，如果系统中有多个用户使用docker，记得检查/etc/passwd和/etc/group中的docker相关用户组，避免权限残留。