Docker容器文件系统权限异常：Ubuntu与WSL中/tmp权限差异排查

• 文件系统创建：Docker默认采用联合文件系统（如overlay2），将镜像的多个只读层叠加，再为容器添加独立的可写层。容器内所有修改都会写入该可写层，镜像层保持只读，实现镜像复用与容器隔离。
• 根文件系统权限：容器根文件系统权限继承自镜像构建配置——包括基础镜像自带的目录/文件权限，以及Dockerfile中RUN chmod等指令设置的权限。容器启动时，还可通过--user指定运行用户，或挂载卷时用--mount指定卷权限，调整容器内权限环境。

迁移操作是否导致异常？ #

是，此次迁移大概率是诱因，具体原因及修复方案如下：

可能原因 #

1. 存储目录权限异常：迁移/var/lib/ubuntu过程中，可能误改Docker默认数据目录（/var/lib/docker）的权限或所属组，导致Docker创建容器tmpfs时无法应用默认的1777权限。
2. 系统tmpfs配置被干扰：迁移操作可能影响系统级tmpfs挂载参数，使Docker容器继承了异常的tmpfs权限规则。
3. Docker配置文件被篡改：迁移过程中误操作修改/etc/docker/daemon.json或Docker服务启动参数，覆盖了默认的tmpfs权限配置。

修复方案 #

1. 修复Docker数据目录权限
   执行以下命令重置Docker数据目录权限，确保服务正常读写：

sudo chown -R root:root /var/lib/docker
sudo chmod -R 700 /var/lib/docker
sudo systemctl restart docker

重启后重新启动容器，检查/tmp权限是否恢复。

2. 配置Docker全局tmpfs权限
   编辑或创建Docker守护进程配置文件/etc/docker/daemon.json，添加tmpfs默认权限设置：

{
  "tmpfs": {
    "/tmp": "rw,noexec,nosuid,nodev,mode=1777"
  }
}

保存后重启Docker服务：

sudo systemctl restart docker

3. 启动容器时手动指定tmpfs权限
   若不想修改全局配置，启动容器时直接指定/tmp的tmpfs参数：

docker run -it --tmpfs /tmp:rw,mode=1777 python:3.11-slim-buster /bin/bash

4. 检查AppArmor规则
   Ubuntu默认启用AppArmor，若规则限制容器内目录权限，可临时禁用测试：

sudo systemctl stop apparmor
sudo systemctl disable apparmor

若权限恢复，再调整AppArmor的容器相关规则。

其他可能的诱因及修复方法 #

如果迁移不是问题根源，可排查以下方向：

• 镜像缓存损坏：Ubuntu Server上的镜像缓存可能异常，重新拉取镜像测试：

  docker rmi python:3.11-slim-buster
  docker pull python:3.11-slim-buster
  

• Docker版本差异：对比WSL与Ubuntu Server的Docker版本，若差异较大，升级或降级到一致版本后测试。
• 系统内核参数：检查Ubuntu Server的tmpfs相关内核参数（如/proc/sys/vm/hugetlb_shm_group），或调整/etc/fstab中的tmpfs挂载规则，确保容器继承正确权限。

内容的提问来源于stack exchange，提问作者Code-Apprentice