Dify Custom Sandbox Stuck in Infinite Loop: After Fixing "Operation not permitted", "ModuleNotFoundError" Appears — Both Cannot Coexist

Help Me Build Seeking help
1

Environment Information:

  • System: Windows 11 + WSL2 (Ubuntu 22.04)

  • Deployment: Docker Compose source code deployment

  • Requirement: Run mathematical modeling code in Sandbox (requires networkx and pulp + system-level solvers glpk/cbc).

Problem Description: I customized the sandbox image and modified docker-compose.yml, but now I’m stuck in a bizarre “error loop” where I cannot simultaneously satisfy dependency existence and sufficient permissions:

Core Contradiction (The Loop):

  1. State A: Error “ModuleNotFoundError”

    • When I rebuild the image to ensure libraries exist, the web interface reports missing libraries.

    • However, when I enter the container via docker exec to check, the libraries are present.

  2. State B: Error “error: operation not permitted”

    • To resolve the PuLP solver permission issue, I configured security_opt: seccomp:unconfined and privileged: true in docker-compose.yml.

    • Once permissions seem to take effect (or after restarting the service to refresh the configuration), the error changes to “No module named ‘networkx’”.

    • If I manage to make the libraries discoverable, the code fails again at prob.solve() with “operation not permitted”.

My Configuration:

1. Dockerfile.sandbox (as follows)

FROM langgenius/dify-sandbox:latest
USER root
RUN apt-get update && apt-get install -y coinor-cbc glpk-utils

RUN pip install --no-cache-dir --default-timeout=1000 -i https://mirrors.aliyun.com/pypi/simple/ \
numpy \
pandas \
scipy

RUN pip install --no-cache-dir --default-timeout=1000 -i https://mirrors.aliyun.com/pypi/simple/ \
networkx \
pulp \
scikit-opt \
statsmodels \
scikit-learn \
scienceplots \
openpyxl

2. docker-compose.yml (ensuring permissions are relaxed)

sandbox:
   image: my-math-sandbox:local
   container_name: docker-sandbox-1
   restart: always

   privileged: true
   security_opt:
       - seccomp:unconfined
       - apparmor:unconfined
   cap_add:
       - SYS_PTRACE

Verified Facts:

  1. Image builds correctly: Tested with docker run --rm -it my-math-sandbox:local python3 -c "import pulp; print('ok')", both libraries and solvers work normally.

  2. Container is running: docker ps confirms the sandbox is indeed loading the my-math-sandbox:local image.

  3. Exec tests succeed: While the container is running, manually executing scripts via docker exec -it docker-sandbox-1 python3 works perfectly, with no permission errors or missing library errors.

Core Question: Why does the Dify Web UI (Go Runner) execution environment behave so differently from the environment I enter via docker exec?

  • Does Dify’s Runner ignore security_opt from Docker Compose when launching Python processes?

  • Or does enabling privileged mode cause the Runner to mount a different filesystem, rendering my pip install ineffective?

Please kindly advise on troubleshooting directions! I’ve been stuck in this loop for two days.

2

@Mahu
Hi,

Dify Sandbox provides a sandbox environment based on Seccomp.
This is implemented independently within the Dify Sandbox service and is not related to the container-level security_opt.seccomp settings.
Because of this, there are restrictions on which Python modules are available, and which system calls can be executed, for the code block.

I haven’t been able to test all of this thoroughly myself, but hopefully the following information will give you some hints.

Custom Dockerfile

Adding packages with apt should probably work just as you’ve tried. However, pip won’t have any effect here, so the following three lines in your Dockerfile should be enough.

FROM langgenius/dify-sandbox:latest
USER root
RUN apt-get update && apt-get install -y coinor-cbc glpk-utils

Alternatively, you could leave your pip commands as-is and later add a system-wide module path using the python_lib_path setting in config.yaml (which I’ll explain below), but I haven’t tried this method myself.

Adding Python Modules

In Dify Sandbox, if you place a /dependencies/python-requirements.txt file inside the container, it will be installed automatically.

The format is the same as a standard requirements.txt file.
Any modules you tried to install with pip should be listed in this file. I recommend bind-mounting this file from the host to the container.

Default is empty: dify-sandbox/dependencies/python-requirements.txt at main · langgenius/dify-sandbox · GitHub

Controlling System Calls

An operation not permitted error usually happens when a required system call isn’t permitted.
You can control Dify Sandbox’s settings in the /conf/config.yaml file inside the container — there’s a default file in the repository: dify/docker/volumes/sandbox/conf/config.yaml at main · langgenius/dify · GitHub

Here, you’ll find the allowed_syscalls key; by passing an array of integers, you can allow the corresponding system calls.

...
allowed_syscalls:
  - 1
  - 2
  - 3
  # add all the syscalls which you require
...

I recommend bind-mounting this file as same as python-requirements.txt.

Alternatively, you can likely achieve the same effect by passing a comma-separated list of numbers (1,2,3) to the ALLOWED_SYSCALLS environment variable.

It’s not easy to figure out exactly which system calls your Python code needs, but there are some hints in the FAQ: dify-sandbox/FAQ.md at main · langgenius/dify-sandbox · GitHub

If you can tolerate any possible security risks, one idea is to simply allow all system calls.

Alternative proposal

If the setup or troubleshooting process is too complicated or difficult for you, one workaround you can consider is developing a dedicated plugin.

With a plugin, you won’t be affected by Seccomp restrictions, and you’ll have more freedom to introduce any modules you need.

See: Dify Plugin - Dify Docs

Hope this helps!

3

I forgot to mention one thing.

By default, Dify Sandbox reinstalls Python modules every 30 minutes according to /dependencies/python-requirements.txt.

Depending on your environment, this could cause memory usage to continuously increase or periodically cause high CPU load.
If that’s a concern, please consider changing the module installation interval by adjusting the relevant environment variable PYTHON_DEPS_UPDATE_INTERVAL.

See: There is a memory leak issue with the sandbox version 0.2.11 when the service is deployed in a containerized environment. · Issue #168 · langgenius/dify-sandbox · GitHub

Since code blocks can be a bit restrictive, I personally tend to create plugins quite freely.
I encourage you to consider turning your ideas into plugins as well—if you have coding experience, it shouldn’t be too difficult.

4

Thank you very much for your help. I will try to solve the problem according to your method, and your ideas have been very inspiring to me.:smiley:

1 Like