Docker Swarm容器挂载主机/dev/ttyS0后访问提示Operation not permitted问题

• 首先是Docker cgroup设备访问限制：即便你将主机/dev目录绑定挂载到容器内，Docker默认的cgroup设备规则会阻止容器访问未明确授权的设备。你挂载的ttyS0是主设备号4、次设备号64的字符设备，默认不在容器的允许访问设备列表中，因此即便文件权限是777，仍然会触发Operation not permitted报错。
• 其次是绑定挂载不等于设备授权：只有使用--device参数（docker run场景）或者compose的devices字段声明挂载设备时，Docker才会自动修改cgroup规则、放行对应设备的访问权限，单纯绑定挂载/dev目录不会触发这个授权逻辑。
• 额外可能的拦截因素：如果主机开启了SELinux或AppArmor，默认的容器安全策略也会阻止容器访问未明确授权的主机设备，哪怕文件权限足够。

你看到的容器内I have no name!提示是因为当前运行容器的UID在容器内部/etc/passwd中没有对应的用户条目，这个问题不影响设备访问，和本次报错无关。

针对Docker Swarm场景，推荐按优先级选择以下方案：

1. 明确声明需要访问的设备（最安全）
   在服务的docker-compose.yml中通过devices字段直接声明要挂载的设备，Docker会自动完成所有权限配置：

version: '3.8'
services:
  你的服务名:
    # 其他配置保持不变
    devices:
      - "/dev/ttyS0:/mydev/ttyS0"

2. 单独配置设备cgroup规则（适合需要挂载整个/dev目录的场景）
   如果确实需要挂载整个/dev目录到容器内，可以单独添加对应设备的放行规则，避免开启过高权限：

version: '3.8'
services:
  你的服务名:
    # 其他配置保持不变
    volumes:
      - "/dev:/mydev"
    device_cgroup_rules:
      - 'c 4:64 rwm'

3. 临时测试用方案（不推荐生产使用）
   可以给容器开启特权模式，跳过所有cgroup和安全策略限制，权限风险极高，仅建议临时排查问题使用：

version: '3.8'
services:
  你的服务名:
    # 其他配置保持不变
    privileged: true

如果主机开启了SELinux，上述方案执行后仍报错的话，可以临时执行主机命令chcon -t container_file_t /dev/ttyS0修改设备安全标签验证。

内容的提问来源于stack exchange，提问作者mnj