团队服务器 Docker 实战：如何在 Linux 服务器上搭建多人共用的 Docker 开发环境？（踩坑全记录）
文章目录
- 1）坑：docker 能运行，docker ps 却 permission denied
- 现象
- 根本原因
- 标准解决办法
- 2）坑：usermod: group 'docker' does not exist
- 现象
- 根本原因
- 解决办法
- 3）坑：systemctl restart docker 失败，提示找不到服务
- 现象
- 根本原因
- Snap 用户的处理方式
- 4）坑：Snap Docker 的“权限会反复失效”（经典噩梦）
- 现象
- 根本原因
- 排查方式（必做）
- 临时“绝杀”修复
- 5）坑：Snap 卸载 Docker 特别慢（甚至像卡死）
- 现象
- 根本原因
- 快速卸载（跳过备份）
- 6）最终推荐：换成标准 APT 版 Docker（稳定、团队首选）
- 7）坑：Compose 插件 apt 装不上 / 版本太老 / 找不到包
- 现象
- 手动安装 Compose（官方二进制）
- 坑：GitHub 下载失败 `curl: (56) Failure ...`
- 8）坑：多用户环境下 Docker 是“共享守护进程”，会互相打架
- 核心认知（非常重要）
- 团队规则（必须定）
- 9）坑：每人都有镜像压缩文件，但 docker load 失败：文件权限问题
- 现象
- 根本原因
- 解决办法（管理员执行）
- 10）每个用户如何运行“自己的容器”（正确姿势）
- Step 1：每个人先加载镜像（一次）
- Step 2：每人建立项目目录（推荐）
- Step 3：推荐用 Compose 管理（比 docker run 更不容易出错）
- 11）进阶坑：后面突然要开端口怎么办？（不用删容器，不丢数据）
- 做法
- 12）额外提醒：不写 --name 会怎样？
- 最终“团队稳定版”结论
团队共用一台服务器做开发，Docker 几乎是最省心的方式：环境一致、隔离强、迁移快。但现实往往是：第一次用就会被权限、安装方式、网络、多人冲突按在地上摩擦。
这篇文章记录一条完整的真实踩坑链路：
从 “docker ps 报 permission denied” 开始，一路踩到 Snap、Compose 下载失败、多用户运行冲突、.tar 镜像权限问题，最后落地成团队可复用的稳定方案。
1）坑：docker 能运行，docker ps 却 permission denied
现象
运行 docker 只显示帮助信息（看起来像“能用”）
但运行 docker ps / docker images 就报：
permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock
根本原因
Docker 是 C/S 架构：
docker：只是客户端程序，谁都能运行，所以会显示 helpdocker ps：必须通过 Unix Socket/var/run/docker.sock去请求后台守护进程dockerd
这个 socket 默认权限通常是：只允许 root 和 docker 组访问
所以：
用户不在 docker 组里 → 无权访问 socket → 报错
标准解决办法
把用户加进 docker 组：
sudo usermod -aG docker $USER
让权限立刻生效（二选一）：
不重登（推荐）：
newgrp docker
或者最彻底：退出 SSH 重新登录。
验证：
docker ps
2）坑：usermod: group ‘docker’ does not exist
现象
执行：
sudo usermod -aG docker $USER
直接报：docker 组不存在。
根本原因
有些系统 / 安装方式不会自动创建 docker 组（常见于精简系统、非标准安装路径）。
解决办法
手动创建 docker 组并重新加入：
sudo groupadd docker
sudo usermod -aG docker $USER
newgrp docker
3）坑：systemctl restart docker 失败，提示找不到服务
现象
想重启 Docker 让权限生效：
sudo systemctl restart docker
但报错：找不到 docker 服务。
根本原因
通常说明：你装的 Docker 不是 systemd 管理的标准服务。常见原因：
- Docker 是通过 Snap 安装的
- 在 WSL / Docker Desktop 环境
- 或者你在 容器里跑 Docker（Docker-in-Docker）
Snap 用户的处理方式
Snap 的服务控制方式不是 systemctl，而是：
sudo snap restart docker
4）坑：Snap Docker 的“权限会反复失效”（经典噩梦）
现象
- 一个用户解决好了
- 过一会 / 重启后又不行
- 即便大家都进了 docker 组，还是
permission denied
根本原因
Snap 的 Docker 跑在沙盒里，有时会把 /var/run/docker.sock 的属组重置回 root:root。
结果就是：用户在 docker 组也没用，因为门锁换回去了。
排查方式（必做）
看 socket 权限：
ls -l /var/run/docker.sock
- 如果是
root root：说明锁被重置了 - 如果是
root docker：说明锁正常，可能只是用户组没刷新
临时“绝杀”修复
把 socket 属组改回 docker：
sudo chown root:docker /var/run/docker.sock
然后用户刷新组：
newgrp docker
⚠️ 但这只是 治标
因为 Snap 可能下次又重置。真正的治本方案在下一节。
5）坑：Snap 卸载 Docker 特别慢（甚至像卡死）
现象
执行：
sudo snap remove docker
很慢、转圈、像卡住。
根本原因
Snap 默认卸载前会做 数据快照（snapshot）：
镜像 / 容器 / 卷很多时会压缩备份，巨慢。
快速卸载（跳过备份）
直接 purge：
sudo snap remove docker --purge
如果中途 Ctrl+C 了：可能会留下快照垃圾。
查看快照：
sudo snap saved
删掉快照（比如 ID=1）：
sudo snap forget 1
然后再 purge：
sudo snap remove docker --purge
6）最终推荐：换成标准 APT 版 Docker（稳定、团队首选）
Snap Docker 在团队服务器上经常带来奇怪的权限 / 挂载 / 网络问题。
最省心的做法是：卸载 Snap → 安装 APT 标准版（docker.io）。
sudo apt update
sudo apt install docker.io
启动并开机自启：
sudo systemctl start docker
sudo systemctl enable docker
把所有团队成员加到 docker 组：
sudo usermod -aG docker user1
sudo usermod -aG docker user2
提醒大家：重新登录 SSH（或者 newgrp docker）才会生效。
这一步之后，Snap 的“权限反复失效”基本就结束了。
7）坑：Compose 插件 apt 装不上 / 版本太老 / 找不到包
现象
希望使用 docker compose ...（空格写法），但：
docker compose version报不存在sudo apt install docker-compose-plugin找不到包 / 版本不对
手动安装 Compose（官方二进制）
创建插件目录：
sudo mkdir -p /usr/local/lib/docker/cli-plugins
下载：
sudo curl -SL https://github.com/docker/compose/releases/download/v2.29.1/docker-compose-linux-x86_64
-o /usr/local/lib/docker/cli-plugins/docker-compose
授权：
sudo chmod +x /usr/local/lib/docker/cli-plugins/docker-compose
验证：
docker compose version
坑：GitHub 下载失败 curl: (56) Failure ...
国内网络经常连不上 GitHub。可以用镜像加速：
sudo curl -SL https://ghproxy.net/https://github.com/docker/compose/releases/download/v2.29.1/docker-compose-linux-x86_64
-o /usr/local/lib/docker/cli-plugins/docker-compose
8）坑：多用户环境下 Docker 是“共享守护进程”，会互相打架
核心认知（非常重要）
即使服务器上有多个 Linux 用户，Docker 依然是系统级服务。
所有人共用同一个 dockerd，所以：
- 容器名重复会冲突：
Conflict. The container name is already in use - 端口映射重复会冲突：
bind: address already in use
团队规则（必须定）
要做到互不干扰，必须制定三件事：
- 容器命名规范：推荐
用户名-项目名-dev - 每人独立工作目录（挂载到容器）
- 端口分配策略（每人一个段）
9）坑：每人都有镜像压缩文件，但 docker load 失败：文件权限问题
现象
把镜像压缩文件复制到每个用户家目录，但用户执行：
docker load -i 镜像压缩文件
读不到或报权限相关问题。
根本原因
复制时用了 sudo cp，文件 owner 变成 root。
文件在用户目录里，但属于 root，普通用户没权限读（或删）。
解决办法（管理员执行）
把文件 owner 改回对应用户：
sudo chown user1:user1 /home/user1/ai-dev-base.tar
验证：
ls -l ~/ai-dev-base.tar
确保显示的是 user1 user1，而不是 root root。
10）每个用户如何运行“自己的容器”（正确姿势）
Step 1：每个人先加载镜像（一次）
docker load -i 镜像压缩文件
docker images
确认镜像名。
Step 2：每人建立项目目录（推荐）
mkdir -p ~/project1
cd ~/project1
Step 3：推荐用 Compose 管理（比 docker run 更不容易出错）
docker-compose.yml 示例（每个人把 container_name 改成自己的）：
services:
dev-env:
image: 镜像名
container_name: 容器名
restart: unless-stopped
volumes:
- .:/workspace
command: tail -f /dev/null
启动：
docker compose up -d
进入：
docker exec -it 容器名 bash
11）进阶坑：后面突然要开端口怎么办？（不用删容器，不丢数据）
很多人一开始不配置端口，后来突然要跑：
- TensorBoard：6006
- Web Demo：5000
做法
在宿主机改 docker-compose.yml，加 ports：
ports:
- "20002:6006"
- "20003:5000"
应用配置：
docker compose up -d
Compose 会检测变更并重建 / 重启容器来生效。
如果代码挂载在宿主机目录（volumes），代码数据不会丢失。
12）额外提醒：不写 --name 会怎样？
如果你用 docker run 不加 --name，Docker 会自动生成一个随机名字（例如 focused_morse）。
这不会影响运行，但会带来两个麻烦：
- 你很难记住容器名（进容器、看日志不方便）
- 团队协作时更难管理和排查
所以团队环境强烈推荐统一命名规则。
最终“团队稳定版”结论
在团队服务器上，想要 Docker 用得舒服，建议按这个顺序落地：
- 避免 Snap Docker，用 APT 标准版（docker.io）
- 把所有成员加入 docker 组（并要求重新登录）
- Compose 如果 apt 没有，就手动装插件（必要时用国内加速）
- 制定团队规则：容器名规范 + 端口分段 + 每人独立挂载目录
.tar文件复制后记得chown，避免 root owner 坑人- 端口需求变化时：只改 compose 文件 +
docker compose up -d
本文地址：https://www.yitenyun.com/837.html
