不能通过 bind mount 挂载物理网卡 sys 目录实现容器内直控，因 sysfs 受 network namespace 隔离限制；唯一可行方式是使用 --network host 模式并配合最小能力集（如 --cap-add=net_admin）和只读挂载。
不能直接通过 bind mount 挂载物理网卡的 sys 目录（如 /sys/class/net/eth0/）来实现容器内“直控”网卡。
这不是权限或语法问题，而是 Linux 内核和容器隔离机制的根本限制。以下是关键原因和可行替代路径：
1. sysfs 是动态虚拟文件系统，挂载不等于授权/sys 下的内容由内核实时生成，反映当前命名空间（尤其是 netns）的视图。即使你用 --mount type=bind,src=/sys/class/net/eth0,dst=/sys/class/net/eth0 强行挂载：
- 容器默认运行在独立的 network namespace 中；
- 它看到的
/sys/class/net/里只有自己 netns 内的设备（如lo、eth0容器虚拟接口），不是宿主机的eth0； - 宿主机
/sys/class/net/eth0/的路径在容器 netns 中无对应设备，挂载后读取会失败或返回空/错误； - 即使挂载成功，写入（如
echo "down" > /sys/class/net/eth0/operstate）会因 namespace 隔离而无效，甚至触发Operation not permitted。
2. 真正“直控宿主机网卡”，需突破 network namespace 隔离
必须让容器共享宿主机的网络栈，方式只有一种：
docker run --network host ...
此时容器：
- 不创建独立 netns，直接使用宿主机的
/sys/class/net/； -
/sys/class/net/eth0/指向真实物理网卡； - 可读写其属性（如
device/speed,flags,operstate）； - ⚠️ 但这也意味着：容器完全暴露在宿主机网络中，失去网络隔离，端口冲突、防火墙规则失效、安全风险显著上升。
3. 更安全的替代方案（推荐）
若目标是配置、监控或触发网卡行为（如启用 offload、查看 stats、下发 ethtool 命令），应：
- 在宿主机上执行操作，容器仅作为调度/上报代理；
- 使用
host网络模式 + 限定能力（避免全权）：docker run --network host \ --cap-add=NET_ADMIN \ --cap-add=SYS_ADMIN \ -v /sys:/sys:ro \ -v /proc:/proc:ro \ alpine sh -c 'ethtool eth0 | grep Speed'
- 或通过宿主机守护进程（如 systemd service、netlink 监听器）接收容器发来的指令，再安全执行。
4. 绝对不要做的操作
- ❌
--privileged+ bind mount/sys：过度授权，等同于 root on host； - ❌ 在容器内
modprobe或ip link set dev eth0 down（非 host 网络模式下必然失败）； - ❌ 尝试
--mount type=bind,src=/sys/driver/...,dst=/sys/driver：驱动目录绑定无意义，且违反 namespace 边界。
简言之：Bind Mount 本身无法绕过 namespace 隔离。要控制宿主机网卡，必须放弃 network namespace 隔离（即 --network host），并辅以最小能力集（--cap-add）和只读挂载约束。否则，所有对 /sys/class/net/xxx 的挂载都只是镜花水月。
