**核心问题**：您已经将用户 `maoyachun` 添加到了 `docker` 组，但在新终端中执行 `docker` 命令时依然出现 `permission denied` 错误。这通常是因为 **Linux 用户组（group）的变更没有立即应用到所有已存在的会话（终端）中**。当您通过 `usermod` 修改用户所属组后，该变更需要重新登录系统或启动一个新的登录会话（login session）才能完全生效。您之前成功的终端可能是在执行 `usermod` 命令后，通过某种方式（如执行了 `newgrp docker` 或重新登录）使新组权限生效了，而新打开的终端仍然使用的是旧的、未包含 `docker` 组的会话凭据 [ref_3][ref_4][ref_5][ref_6]。 ### **一、问题根源与解决方案对比** 下表清晰地说明了问题原因及对应的解决方案： | 现象 | 根本原因 | 解决方案 | 原理说明 | | :--- | :--- | :--- | :--- | | 终端A成功，新开终端B失败。 | **用户组信息缓存**：Linux 系统在用户登录时（启动一个 shell 会话）会加载其用户和组信息到该会话的环境中。使用 `sudo usermod` 修改组关系是系统级的更改，但不会自动更新已经存在的会话进程的环境。新终端B继承了旧的会话环境，因此仍“认为”用户不属于 `docker` 组 [ref_3][ref_5][ref_6]。 | **1. 完全重新登录**（推荐）<br>**2. 在当前失败终端执行 `newgrp docker`**<br>**3. 使用 `sg docker` 或启动一个子shell** | 这些操作都会触发系统重新读取用户的组数据库，将新的 `docker` 组身份加载到当前或新的 shell 环境中，从而获得访问 `/var/run/docker.sock` 的权限。 | ### **二、详细解决步骤与代码示例** 请在新开的、执行 `docker run` 失败的终端中，按顺序尝试以下方法。 #### **方法一：使用 `newgrp` 命令（最直接的临时解决方案）** `newgrp` 命令会启动一个新的 shell（子进程），并在该新 shell 中激活指定的组（这里是 `docker`）作为主要组（primary group）或补充组（supplementary group）。这是让组变更立即生效的经典方法。 ```bash # 1. 首先，确认当前用户确实在 docker 组中（您已执行过） maoyachun@ubuntu:~$ groups docker adm cdrom sudo dip plugdev lpadmin sambashare maoyachun # 输出中包含 docker # 2. 执行 newgrp 命令，切换到 docker 组环境 maoyachun@ubuntu:~$ newgrp docker # 3. 此时，您已经进入了一个新的子shell。再次验证组信息（可选） maoyachun@ubuntu:~$ groups docker adm cdrom sudo dip plugdev lpadmin sambashare maoyachun # 4. 现在尝试运行 Docker 命令（不带 sudo） maoyachun@ubuntu:~$ docker run --rm hello-world Hello from Docker! ... ``` **关键说明**：执行 `newgrp docker` 后，您会“感觉”还在同一个终端，但实际上已经进入了一个新的子 shell。在这个子 shell 中，`docker` 组的权限已经生效。要退出这个子 shell 并返回原来的 shell，可以按 `Ctrl+D` 或输入 `exit` [ref_3][ref_5][ref_6]。 #### **方法二：使用 `sg` 命令（单命令执行）** `sg` 命令与 `newgrp` 类似，但更灵活，允许您以另一个组的身份执行单个命令，而无需启动一个持久的子 shell。 ```bash # 以 docker 组成员的身份执行一次 docker run 命令 maoyachun@ubuntu:~$ sg docker -c "docker run --rm hello-world" Hello from Docker! ... ``` 这种方法适合临时运行一个命令，无需改变当前 shell 的会话环境 [ref_3]。 #### **方法三：注销并重新登录（一劳永逸的解决方案）** 这是确保所有新会话都能正确获取新组权限的最彻底方法。它涉及完全更新您的登录会话。 1. **保存所有工作**，关闭所有终端窗口。 2. **注销当前桌面会话**（或从 SSH 连接中退出）。 3. **重新登录**。 4. 登录后，打开一个新的终端，直接运行 `docker run hello-world`，此时应该可以成功执行，无需任何额外命令 [ref_4][ref_6]。 #### **方法四：检查并重启 Docker 服务（排除服务问题）** 在极少数情况下，Docker 守护进程本身可能存在问题。虽然这与组权限无关，但可以作为完整性检查。 ```bash # 检查 Docker 服务状态 sudo systemctl status docker # 如果状态异常，尝试重启 Docker 服务 sudo systemctl restart docker # 重启后，再次尝试（在应用了上述组权限解决方案的终端中） docker run --rm hello-world ``` [ref_2] ### **三、验证与后续操作** 1. **验证组权限生效**：在任何终端，执行 `id -nG` 或 `groups` 命令，确保输出中包含 `docker`。 2. **验证套接字文件权限**：执行 `ls -l /var/run/docker.sock`，确认其组所有者是 `docker`，且组权限包含读写 (`rw-`)。 ```bash srw-rw---- 1 root docker 0 Aug 28 10:00 /var/run/docker.sock ``` [ref_1][ref_4] 3. **持久性测试**：按照**方法三**重新登录后，打开多个新终端，分别执行 `docker ps`、`docker images` 等命令，均应能正常执行，无需 `sudo`。 ### **四、安全提醒** 虽然将用户加入 `docker` 组解决了权限问题，但必须意识到其安全含义：**`docker` 组的成员拥有等同于 `root` 的权限**，因为 Docker 守护进程以 root 身份运行，并能执行影响整个系统的操作（如挂载主机目录、操作网络、运行特权容器等）。因此，只应将此权限授予可信的用户账户 [ref_1][ref_4]。 **总结**：您遇到的问题是新终端会话未加载更新后的用户组信息。最根本的解决方法是**注销系统并重新登录**。在新开的失败终端中，可以立即使用 `newgrp docker` 命令启动一个具有新权限的子 shell，或使用 `sg docker -c "your_command"` 来执行单条 Docker 命令。完成这些操作后，您的普通用户即可在所有终端中直接使用 Docker，无需 `sudo` [ref_3][ref_4][ref_5][ref_6]。