Dify 的代码执行节点一直是个让人又爱又恨的东西。爱的是它能把 Python 直接跑在工作流里数据处理、接口调用、文本加工全都能塞进去恨的是默认沙箱权限收得太紧经常莫名奇妙抛一句operation not permitted而且不同系统上报错还不一样。我这次在本地部署 Dify 1.17.1 社区版把沙箱权限从报错到配置彻底捋了一遍踩了不少坑也把原理弄明白了整理出来给遇到同样问题的朋友参考。先说结论operation not permitted在 Dify 沙箱场景里绝大多数时候不是真的权限不够而是沙箱容器在 seccomp、capabilities、文件系统挂载这几个层面做了限制你的代码触发了其中某一条。盲目加--privileged或者 chmod 777 是治标不治本甚至会把沙箱的隔离能力直接废掉。这篇我按排查顺序来写从报错原理到配置改动再到分平台的差异处理读完基本能自己搞定。1. 先搞清楚沙箱到底拦了什么1.1 operation not permitted 并不是一个具体原因很多人看到这个报错就懵了第一反应是是不是没给权限。实际上 Linux 内核返回Operation not permittederrno 1, EPERM时背后可能有好几种完全不同的原因文件系统层挂载目录是只读的或者当前用户对目标目录没有写权限。Linux capability 缺失进程缺少某项能力比如CAP_NET_ADMIN导致无法配置网络、CAP_SYS_PTRACE导致无法调试进程。seccomp 拦截系统调用被 seccomp 过滤器拒绝了。Docker 默认 seccomp 配置会拦截unshare、mount、pivot_root这些高危 syscall。AppArmor/SELinux 拦截Ubuntu 的 AppArmor、CentOS 的 SELinux 会在更上层做路径和权限限制报错同样是 EPERM。我见过最典型的一个案例代码执行节点里只是调用os.makedirs创建一层目录就报了[Errno 1] Operation not permitted。排查到最后发现不是目录权限问题而是 seccomp 把mkdir相关的某个 syscall 给拦了。所以看到这个报错先别急着改权限要一层层拆开看。1.2 Dify 沙箱的默认安全策略到底有多严Dify 的沙箱镜像langgenius/dify-sandbox默认做了三层隔离。理解这三层你就知道改配置时该动哪里。第一层是 seccomp 系统调用过滤。Docker 的默认 seccomp profile 已经挺严格Dify 的 sandbox 镜像又在 Docker 基础上加了一层白名单只允许执行 Python 代码所需的最小 syscall 集合。像mount、umount2、pivot_root、swapon这类高危调用默认直接拒绝。第二层是 Linux capabilities 裁剪。容器默认没有CAP_SYS_ADMIN、CAP_NET_ADMIN、CAP_SYS_PTRACE等这意味着很多需要系统管理员权限的操作根本没戏。你就算在容器里拿到 root 用户缺了 capability 照样 EPERM。第三层是文件系统挂载。沙箱工作目录是独立的宿主机的目录不会自动挂载进沙箱容器除非你在docker-compose.yml里显式配置卷映射。这三层是叠加生效的。哪怕你chmod 777了宿主机目录只要容器内进程没有对应的 capability写文件时依然会报 EPERM哪怕你加了--privileged如果 seccomp 还在拦unshare照样失败。所以排查时需要一层层确认。1.3 三种部署方式下的沙箱差异Dify 社区版 1.17.1 的主流启动方式还是 docker compose。但沙箱在不同操作系统上的表现差异很大我三套环境都测过报错文本完全不同环境报错文本问题层Linux Docker Composeos.makedirs: [Errno 1] Operation not permitted挂载目录权限或 seccompmacOS Docker Desktopcould not set environment: 150: operation not permittedDocker Desktop 虚拟机层限制Windows WSL2failed to get d-bus connection: operation not permittedWSL2 内核兼容性这里有个很关键的点同一个operation not permitted在不同平台上根因可能完全不同。Mac 和 Windows 的 Docker 都跑在虚拟机/WSL2 里多了一层虚拟化有些 syscall 行为会被宿主系统额外拦一道。所以你在 Mac 上遇到问题时光改容器配置可能没用还要看 Docker Desktop 本身的设置。2. 沙箱权限配置的完整实操2.1 修改 docker-compose.yml 里的 sandbox 服务Dify 1.17.1 的 docker-compose 文件里sandbox 服务默认大概是这样的sandbox: image: langgenius/dify-sandbox:1.17.1 container_name: dify-sandbox environment: - API_KEY${SANDBOX_API_KEY:-dify-sandbox} volumes: - ./volumes/sandbox:/sandbox networks: - ssrf_proxy_network restart: always默认情况下./volumes/sandbox这个宿主机目录是挂载进容器的但挂载目录的属主是 root而容器内实际运行代码的用户是 sandbox 用户UID 通常是 1000 左右。如果你在代码执行节点里往/sandbox直接写文件大概率会遇到 EPERM。我的做法是把挂载目录的属主改成容器内用户的 UID同时把 seccomp 配置调整为更宽松的模式sandbox: image: langgenius/dify-sandbox:1.17.1 container_name: dify-sandbox environment: - API_KEY${SANDBOX_API_KEY:-dify-sandbox} volumes: - ./volumes/sandbox:/sandbox security_opt: - seccomp:unconfined networks: - ssrf_proxy_network restart: always然后在宿主机执行# 查看容器内实际用户 UID docker exec dify-sandbox id sandbox # 假设输出是 uid1001(sandbox) sudo chown -R 1001:1001 ./volumes/sandbox这里解释一下这两个改动背后的逻辑。第一个是seccomp:unconfined。这个参数让 Docker 不加载任何 seccomp 过滤器容器内进程可以使用任意 syscall。它不等于--privileged因为 capabilities 和 AppArmor 还在生效。在 Dify 沙箱场景下代码执行节点本身跑在一个隔离环境里外面又套了一层 Docker再放开 seccomp实际风险是可控的。但如果你的场景是多租户允许不可信用户提交代码执行那我强烈不建议直接 unconfined而应该按白名单逐步放开方法在本文第 5 节讲。第二个是 chown 挂载目录到容器用户。很多人忽略这一步直接在 compose 里加user: root让容器以 root 运行。这样做确实能绕过大部分文件权限问题但代价是容器里所有进程都是 root一旦代码执行节点里的代码有恶意操作它能做的就太多了。相比之下把挂载目录的属主改成容器内 sandbox 用户既保住了非 root 运行又解决了文件读写问题。注意如果你用的是 Docker DesktopMac/Windowschown -R在宿主机执行可能没有效果因为挂载目录的文件实际存放在 Docker 的虚拟机里。这种情况下你要么进容器里执行chown要么直接用下一节的自检代码确认权限状况。2.2 在 Dify 代码执行节点里做权限自检改完配置只是第一步。你需要在 Dify 里创建一个测试工作流用代码执行节点跑一段权限自检代码确认到底哪些操作被拦截。这段代码可以覆盖文件写入、临时目录、网络请求三大常见场景import os import tempfile import shutil def main(workflow_variables: dict): results {} # 检查当前用户 results[user] os.getuid() # 检查能不能创建临时目录 try: tmp_dir tempfile.mkdtemp() results[tempdir] tmp_dir with open(os.path.join(tmp_dir, test.txt), w) as f: f.write(hello) results[tempdir_write] ok shutil.rmtree(tmp_dir) except Exception as e: results[tempdir] str(e) # 检查能不能写工作目录 try: with open(/sandbox/test_write.txt, w) as f: f.write(hello) results[sandbox_write] os.path.abspath(/sandbox/test_write.txt) os.remove(/sandbox/test_write.txt) except Exception as e: results[sandbox_write] str(e) # 检查网络访问 try: import urllib.request resp urllib.request.urlopen(http://www.baidu.com, timeout3).status results[network] resp except Exception as e: results[network] str(e) return results执行完你会得到类似这样的结果{ user: 1001, tempdir: /tmp/tmp123456, tempdir_write: ok, sandbox_write: /sandbox/test_write.txt, network: 200 }如果sandbox_write报错说明挂载目录属主有问题去 chown。如果tempdir_write报错说明沙箱连 /tmp 都写不了这不是目录权限的问题而是 seccomp 或 capability 拦截需要调 compose 配置。如果network报错那是沙箱默认禁止外网访问需要在 compose 里配代理或调整网络模型。这一步自检的价值在于把权限不足这个大帽子拆成具体的小问题之后改配置就有明确目标了。2.3 用 strace 定位具体被拦截的 syscall有时候开了seccomp:unconfined问题依然存在。这种情况大概率是 capabilities 层拦截或者是 AppArmor 在起作用。这时候就不要再猜了直接进容器用 strace 拉一把系统调用记录。Dify 的 sandbox 镜像默认不带 strace需要临时安装docker exec -it dify-sandbox bash apt-get update apt-get install -y strace然后找到沙箱进程并附加跟踪# 找到 sandbox 相关进程 ps aux | grep python # 附加跟踪只跟踪文件和进程相关 syscall strace -f -p PID -e tracefile,process,network -o /tmp/strace.log跑完再去看/tmp/strace.log重点找EPERM。举个例子如果看到openat(AT_FDCWD, /sys/fs/cgroup/cpu.max, O_WRONLY) -1 EPERM (Operation not permitted)那就说明进程想写 cgroup 文件被 capabilities 拦了需要加CAP_SYS_ADMIN。如果看到unshare(CLONE_NEWUSER) -1 EPERM (Operation not permitted)就是 seccomp 拦了用户命名空间创建对应解法是改 seccomp 配置。实操心得Mac 上用 Docker Desktop 时docker exec进去可能看不到完整的 syscall 输出因为虚拟机层会拦截一部分 ptrace 请求。我的建议是优先在 Linux 宿主机上排查完再回到 Mac/Windows 验证。跨平台排查时很多权限问题实际上是 Docker Desktop 的资源限制导致的间接后果比如默认 2GB 内存不够进程被 OOM 杀掉表现也是操作失败。2.4 沙箱外网访问的单独配置代码执行节点里如果需要访问外部 API比如调用远程模型接口或者拉取数据沙箱默认是不通的。1.17.1 版本里sandbox 服务连的是ssrf_proxy_network这个网络的出站规则很严格。如果你确认工作流需要联网可以在 compose 里给 sandbox 服务加网络配置networks: - ssrf_proxy_network extra_hosts: - host.docker.internal:host-gateway environment: - HTTP_PROXYhttp://host.docker.internal:端口 - HTTPS_PROXYhttp://host.docker.internal:端口这里有个大坑很多人的第一反应是Dify 主服务能上网沙箱应该也能。实际上沙箱是独立容器默认不在宿主机网络上出站流量会被 ssrf_proxy 拦掉。我之前在工作流里让代码执行节点去访问内网某个服务一直超时排查了半天最后发现是沙箱网络压根没通。补充一点如果只是访问外部公开 API很多时候不需要配代理把network_mode: host打开就行但这样会牺牲一层隔离。我个人的建议是默认保持沙箱无外网只有明确可信的场景才打开而且最好通过代理加上目标地址白名单防止沙箱被当作 SSRF 跳板。3. 不同平台报错的处理逻辑3.1 macOS 上could not set environment: 150的根因这个报错我第一次遇到也很懵完整文本一般是could not set environment: 150: operation not permitted while system integrity protection is enabled。system integrity protection 是 macOS 的 SIP 机制Docker Desktop 在 macOS 上跑容器时文件系统操作会经过 macOS 的虚拟化框架像/System、/usr/bin这些路径即使容器里是 root 也没法写入。如果遇到这种报错问题基本不在 Dify 配置而在 Docker Desktop 的文件共享设置。打开 Docker Desktop 的 Settings - Resources - File sharing把项目目录加进去然后重启 Docker。另一个 macOS 特有问题是挂载目录的 uid/gid。macOS 的文件权限模型和 Linux 不一样你在 compose 里写的uid:gid映射在 Docker Desktop 的 virtiofs 下不一定完全生效。所以我在 Mac 上的做法是不让沙箱直接写宿主机挂载目录而是把数据写到容器内/tmp需要持久化再通过 API 传回 Dify 应用节点。3.2 Windows 上failed to get d-bus connection的坑Windows 上跑 Dify sandbox报failed to get d-bus connection: operation not permitted看着跟你的代码毫无关系其实是容器内某些初始化服务比如 dbus-daemon启动时访问内核接口被 seccomp 拦了或者因为容器非特权模式dbus 启动脚本无法读写/run目录。解法分两步。第一步检查 Docker Desktop 的 WSL2 后端确认wsl --update到最新版本旧版 WSL 内核的 seccomp 支持不完整。第二步在 compose 里给 sandbox 加环境变量绕开 dbus 启动environment: - DBUS_SESSION_BUS_ADDRESS/dev/null - NO_AT_BRIDGE1但说实话Windows 上跑 Dify sandbox 我是不太推荐的。Windows 的 Docker 环境多了一层 WSL2问题出现概率比 Linux 高很多。如果只是体验 Dify我更推荐用 Linux 虚拟机或者云服务器稳定性和排查效率都不是一个量级。3.3 Linux 上最容易被忽略的 AppArmorUbuntu 系统里有个隐藏角色叫 AppArmor它和 seccomp 是两套独立机制。seccomp 管的是你能发起哪些 syscallAppArmor 管的是你能访问哪些文件路径、具备哪些能力。Docker 在 Ubuntu 上默认会给容器加载一份 AppArmor profile这层策略有时候会把容器内写操作拦下来报错同样是operation not permitted。如果你在 Ubuntu 上改了seccomp:unconfined和 chown 之后依然报错可以看看容器实际加载的 AppArmor profiledocker inspect dify-sandbox | grep -A5 AppArmorProfile如果看到有内容在 compose 里把 AppArmor 也放开security_opt: - seccomp:unconfined - apparmor:unconfined看到这里你可能会问那干脆全 unconfined 不就行了表面看确实可以但我要多说一句AppArmor 的 unconfined 意味着容器内进程的文件访问不再受 AppArmor 约束完全靠 Docker 权限体系和 capabilities 管理。对于 Dify 这种跑工作流的平台如果执行的是你自己写的代码问题不大如果是团队使用让新人随便创建代码执行节点我还是建议保留 AppArmor只放开 seccomp。4. 常见问题速查表我把这段时间排查过程中碰到的高频问题整理成了一张表建议收藏备用。现象可能原因解决方案代码执行节点写/sandbox失败 EPERM挂载目录属主不对chown -R 容器UID:容器GID挂载目录创建/tmp临时文件失败seccomp 拦截 syscallsecurity_opt: seccomp:unconfined代码执行节点无法访问外网沙箱网络受限配置代理或调整网络模型Mac 上报SIP/environment 150Docker Desktop 文件共享设置File sharing 加目录并重启 DockerWindows 上报dbus connectionWSL2 内核兼容问题更新 WSL设置 dbus 环境变量代码执行节点可运行但容器内时间不对时区未设置挂载/etc/localtime或设置TZ环境变量高并发调用沙箱偶发 EPERM容器被 OOM 杀掉部分进程检查 Docker 资源上限提高内存4.1 最容易忽悠人的坑容器内 root 不等于宿主机 root排查同事问题时遇到过这种情况他说我进了容器whoami 是 root怎么往 /opt 下写文件还是 EPERM。这就是典型的理解偏差。容器内的 root 拥有的是容器内全量权限但对外依然受 capabilities 约束。Docker 默认给容器内的 root 也是裁剪过 capabilities 的不是宿主机 root 的全量权限。进容器后用capsh --print看一下当前 capabilities你会看到缺了不少项。如果要在容器内模拟宿主机 root 的完整权限需要在 docker run 或 compose 里显式加 capabilitiescap_add: - ALL但这是一个非常重的决定生产环境要慎重。一般情况下按需添加缺失的 capability 就够了比如SYS_PTRACE或者NET_ADMIN。4.2 从报错堆栈定位具体代码的技巧Dify 的代码执行节点报错时工作流运行详情里会展示错误堆栈。但如果代码里用了subprocess或者动态加载模块堆栈往往不够定位。我的做法是在代码里封装一个safe_call函数把每个关键操作包一层出错时打印足够的上下文def safe_call(fn, *args, **kwargs): try: return fn(*args, **kwargs) except Exception as e: print(f[ERROR] {fn.__name__} failed: {e}) import sys print(f[ERROR] errno: {getattr(e, errno, None)}) raise这样能快速确认是os.makedirs还是open先炸的是Permission denied还是Operation not permitted两者排查方向完全不同。4.3 权限放开后的回退策略权限调整是个反复过程今天放开一个配置可能过两天发现要收回来。如果你在改docker-compose.yml之前没备份回退时对照文档重新改会非常痛苦。我的习惯是每次改 compose 前先备份一份带日期的文件比如docker-compose.yml.bak-20250101。然后每放开一项限制在文件注释里写清楚为什么要加、解决哪个报错。这样后面出了问题你知道哪行是临时绕过哪行是核心必须不用从头猜。5. 多租户场景下的沙箱隔离5.1 不要一刀切全放权限如果你搭的 Dify 是给团队或外部用户使用的多个租户都会创建代码执行节点那你肯定不希望所有人都在一个seccomp:unconfined的沙箱里跑代码。这时候更好的方案是保持 seccomp 默认按租户拆分独立的 sandbox 容器。Dify 社区版本身不直接支持沙箱多租户拆分但你可以通过编排做到起两个 sandbox 服务比如sandbox-tenant-a和sandbox-tenant-b在 API 或网关层根据租户信息路由到不同沙箱地址。这样就算某个租户代码把容器搞挂了其他租户不受影响权限配置也可以按租户需求单独调整。5.2 自定义 seccomp profile 而不是一刀切 unconfined如果你不想完全关闭 seccomp又要允许某些特定 syscall可以自己写一个 seccomp profile。Docker 的 seccomp profile 是一个 JSON 文件核心结构是这样{ defaultAction: SCMP_ACT_ERRNO, architectures: [SCMP_ARCH_X86_64], syscalls: [ { names: [unshare, clone, openat, mkdir, mount], action: SCMP_ACT_ALLOW } ] }然后在 compose 里引用security_opt: - seccomp:/path/to/profile.json写 profile 时要特别注意defaultAction 如果是SCMP_ACT_ERRNO漏掉任何一个 Python 运行所需的 syscall都会导致执行失败。我建议基于 Docker 默认 seccomp profile 去改不推荐从零手写白名单Docker 源码里的default.json已经很全面网上也有很多维护好的版本在这个基础上增删更靠谱。5.3 沙箱资源限制同样重要除了权限和系统调用沙箱还受 CPU、内存、文件描述符数量限制。代码执行节点里跑重型任务比如 pandas 读大 CSV时可能因为内存超限被 OOM kill表现是代码跑到一半中断或者子进程退出码 137。在 compose 里可以给 sandbox 加资源上限deploy: resources: limits: memory: 512M cpus: 1.0这个配置在docker composev2 下有效老式docker-compose可能不识别deploy字段如果环境还是旧工具需要先升级。6. 一次完整的排查实录最后分享一个完整的排查案例把前面所有方法串起来。有次做个数据清洗工作流代码执行节点要读/sandbox/input/下的 CSV处理后写/sandbox/output/result.csv。第一次跑报错很干脆[Errno 1] Operation not permitted: /sandbox/output/result.csv我第一反应不是去改 compose而是先看挂载目录到底是不是真的可写。我先把当前工作目录打出来import os def main(workflow_variables: dict): return {cwd: os.getcwd()}结果是/tmp/sandbox不是/sandbox。这就发现了一个重要信息Dify 代码执行节点的实际工作目录是/tmp/sandbox不是你挂载的/sandbox。你挂载的/sandbox只有在代码里显式指定路径时才会用到。接着我用docker exec进容器看目录权限发现docker-compose.yml里挂载的宿主机目录属主是 root而容器内进程用户是 1001写/sandbox自然被拒。按第 2 节的方法chown -R 1001:1001挂载目录问题解决。这个案例里最有价值的一点是报错文本是同一个但如果你不去确认工作目录和挂载目录很容易把力气使错地方。很多人一上来就开seccomp:unconfined结果问题是目录属主误打误撞也可能解决但如果你把 seccomp 也关了之后排查真正需要 seccomp 拦截的问题时反而缺少了一个重要线索。7. 关于 Dify 1.17.1 的几点补充这次排查过程中我还确认了几个 1.17.1 版本相关的细节。第一1.17.1 的沙箱镜像对 Python 版本做了升级部分第三方库的编译环境要求变了。如果你的代码节点里装了numpy、pandas这类需要二进制编译的包报错可能不是权限问题而是镜像里缺编译链。表现为pip install时报gcc相关错误这时候要从依赖安装入手不是调沙箱权限。第二1.17.1 对工作流编排界面做了不少改动代码执行节点的错误输出展示更友好了运行详情里可以直接看到更完整的异常堆栈对排查很有帮助。建议把 Dify 升级到 1.17.1 再排查老版本的报错信息确实太简陋。第三升级版本后 compose 配置字段可能变化。我遇到过在线升级之后原来用的SANDBOX_API_KEY环境变量失效原因是新版本换成了别的变量名。升级前最好先看 release note升级后跑一遍第 2 节的自检代码确认沙箱状态没有因为升级而改变。8. 最后的实在建议这篇文章写到这里该讲的配置和排查方法都讲完了。最后分享几条个人经验不是总结只是实在话。如果你是本地跑着玩Dify 沙箱报operation not permitted最快的解决路径是先看挂载目录属主再开seccomp:unconfined最后再看网络。这三板斧能解决绝大多数本地开发场景的问题。如果你是给团队部署生产环境我建议从一开始就把沙箱权限当成安全边界来设计。不要贪图方便全部unconfined至少保留一层 seccomp 或 AppArmor同时把代码执行节点能访问的网络范围控制住。Dify 本身提供 SSRF 防护但你自己把沙箱权限放得太开再好的防护也白搭。最后再分享一个小技巧排查权限问题时把docker inspect dify-sandbox的输出和代码执行节点的完整错误堆栈一起贴出来无论是发到社区还是找同事帮忙有这两样信息别人定位问题的速度会快非常多。权限类问题最怕信息不全只有一行 EPERM谁也没法隔空猜出你卡在哪一步。先自检、再贴日志、最后动手改这个顺序能帮你省掉很多折腾时间。