Code execution module error: Operation not permitted

[MrYangming]

Self Checks

• I have read the Contributing Guide and Language Policy.
• This is only for bug report, if you would like to ask a question, please head to Discussions.
• I have searched for existing issues search for existing issues, including closed ones.
• I confirm that I am using English to submit this report, otherwise it will be closed.
• 【中文用户 & Non English User】请使用英语提交，否则会被关闭 ：）
• Please do not modify this template :) and fill in all the required fields.

Dify version

1.1.0

Cloud or Self Hosted

Self Hosted (Source)

Steps to reproduce

✔️ Expected Behavior

normal

❌ Actual Behavior

exception

[dosubot]

The "operation not permitted" error in the code execution node comes from the sandbox service that runs your code. By default, the sandbox restricts system calls using seccomp, and its config file (docker/volumes/sandbox/conf/config.yaml) leaves allowed_syscalls empty. If your code or its runtime needs a syscall that's not permitted, you'll get this error. To fix it, add the required syscall numbers to allowed_syscalls in the sandbox config and restart the sandbox container. You can also enable debug logging in the sandbox to help identify which syscall is being blocked.

If the issue persists, check the sandbox and Dify logs for more details, and try running different code snippets to see if the error is specific to certain operations or languages. For more info, see the code execution and sandbox config logic here and here.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[MrYangming]

sandbox log shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory

Is it related to this anomaly？

[MrYangming]

server log is

[dosubot]

The server log traceback confirms that the "operation not permitted" error is a permissions or sandbox restriction issue during code execution. This matches the shell-init error in your sandbox logs, which indicates the working directory is missing or inaccessible. This can happen if the sandbox container's working directory was deleted, unmounted, or is not writable, causing syscalls like getcwd to fail and be blocked by the sandbox security policy.

To resolve this, exec into your sandbox container and check that the working directory exists and is accessible. Also, verify that /tmp and /var/tmp exist and are writable. If you’re running in Docker, ensure the relevant host directories are mounted correctly and have the right permissions. You can also try switching to a more permissive sandbox image like svcvit/dify-sandbox-py:0.1.3 or set privileged: true for the sandbox, api, and worker services in your docker-compose.yaml if your security policy allows it. If the problem persists, check for external security layers (like SELinux or AppArmor) or user remapping that might block access. For more details and step-by-step checks, see this discussion and this issue.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[SomaLily]

server log is

use 3th sandbox

[Covfefeable]

server log is

use 3th sandbox

what's that mean? I encountered same problem:
getcwd: cannot access parent directories: No such file or directory

[SomaLily]

server log is

use 3th sandbox

what's that mean? I encountered same problem: getcwd: cannot access parent directories: No such file or directory

search svcvit