Help：After I performed the migration, the plugin-daemon error occurred.

[zhaoyushang-zh]

Self Checks

• I have searched for existing issues search for existing issues, including closed ones.
• I confirm that I am using English to submit this report (我已阅读并同意 Language Policy).
• [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:)
• Please do not modify this template :) and fill in all the required fields.

1. Is this request related to a challenge you're experiencing? Tell me about your story.

I migrated Dify, transferring the data from an ARM system to an x86 system, and then encountered the following error. I have already replaced the plugin file with the one required for the x86 system.

Moreover, I can normally perform plugin deletion and addition operations in the plugin management, but errors occur when using them. The error messages are as follows:

2. Additional context or comments

No response

[dosubot[bot]]

Hi @zhaoyushang-zh! I'm Dosu and I’m helping the dify team.

Your plugin-daemon errors after migrating from ARM to x86 are almost certainly caused by architecture-specific Python dependencies (like gevent) and broken plugin environments. When you move Docker volumes or plugin directories between architectures, compiled Python packages and their C extensions (such as gevent._gevent_c_hub_local) will not work unless rebuilt for the new architecture. This results in the ModuleNotFoundError you’re seeing, even if plugin add/delete works—because actual code execution (and thus the error) only happens when you use the plugin, not when you manage it.

Here’s how to fix it:

1. Stop all Dify and plugin_daemon containers.
2. Clear plugin data and directories: Delete plugin-related directories (like /app/storage/cwd/plugins/plugin, /plugin-working, /persistence, /plugin-root) and clear plugin records from the database if possible.
3. Check Docker volume mount options: Make sure your plugin storage volumes are NOT mounted with the noexec flag. If they are, remount them with exec so Python can load C extensions (details, discussion).
4. Restart containers.
5. Reinstall all plugins from scratch so dependencies are rebuilt for x86. Do not copy plugin .venv or environment folders from ARM.
6. Ensure outbound network access for the plugin_daemon container so it can download dependencies.
7. Check and set environment variables: In your docker-compose.yaml under the plugin_daemon service, set PLUGIN_MAX_EXECUTION_TIMEOUT and PYTHON_ENV_INIT_TIMEOUT to higher values (e.g., 2400), and confirm SANDBOX_ENABLE_NETWORK=true and PLUGIN_DAEMON_URL are correct (reference, discussion).

For future migrations, always use tar czvf to package your Dify directory and volumes—this preserves symbolic links required by Python virtual environments, which are often broken by other copy methods (reference).

If you still see errors, check the plugin_daemon logs (docker logs plugin_daemon) for missing dependencies or network issues, and manually install any missing Python packages inside the plugin’s .venv directory if needed.

Let me know if you need more detailed steps for any part of this process!

To reply, just mention @dosu.

---

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

   

[zhaoyushang-zh]

@dosu Is there a detailed record of operations for clearing plugin records from the database?

[dosubot[bot]]

There isn’t an official or detailed record for clearing plugin records from the Dify database. Plugin state is split between the database and the plugin_daemon, so a full cleanup involves both.

For the database, plugin-related metadata is stored in tables like tool_oauth_system_clients, tool_oauth_tenant_clients, tool_builtin_providers, tool_api_providers, tool_label_bindings, tool_workflow_providers, tool_mcp_providers, and tool_model_invokes (source). You can clear plugin records by deleting rows from these tables, for example:

DELETE FROM tool_api_providers WHERE tenant_id = '<your_tenant_id>';
DELETE FROM tool_builtin_providers WHERE tenant_id = '<your_tenant_id>';
-- Repeat for other tables as needed

Make sure to back up your database before running any deletes, and check for foreign key dependencies (delete child records first if needed).

This only clears metadata. For a complete reset, you also need to delete plugin directories and caches managed by plugin_daemon (like /app/storage/cwd/plugins/plugin, /plugin-working, /persistence, /plugin-root), then restart all related services and reinstall plugins from scratch.

Let me know if you want more specific SQL examples or help identifying which records to target.

To reply, just mention @dosu.

---

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

   

[zhaoyushang-zh]

I cleared the old plugin cache files, and a new issue has emerged.@dosu