langgenius/dify
1
0
Fork 0
mirror of https://github.com/langgenius/dify.git synced 2026-07-21 12:05:30 -04:00
Code Issues 775 Packages Projects Releases 10 Wiki Activity

The list of model results returned by ollama after successfully adding a model is empty #13929

New Issue
Closed
opened 2026-02-21 19:14:35 -05:00 by yindo · 16 comments
yindo commented 2026-02-21 19:14:35 -05:00
Owner
Copy Link
Copy Source

Originally created by @XGMagiie on GitHub (May 15, 2025).

Self Checks

  • 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 (我已阅读并同意 Language Policy).
  • [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:)
  • Please do not modify this template :) and fill in all the required fields.

Dify version

1.3.1

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

When I add a model using ollam, it says add successful.

Image

However the list of models returned is empty.

Image

The ollama plugin I'm using is version 0.0.6.

Image

✔️ Expected Behavior

In the lower versions, however, it is possible to add

Image

❌ Actual Behavior

ollama's model has not been added.

Image

Originally created by @XGMagiie on GitHub (May 15, 2025). ### Self Checks - [x] This is only for bug report, if you would like to ask a question, please head to [Discussions](https://github.com/langgenius/dify/discussions/categories/general). - [x] I have searched for existing issues [search for existing issues](https://github.com/langgenius/dify/issues), including closed ones. - [x] I confirm that I am using English to submit this report (我已阅读并同意 [Language Policy](https://github.com/langgenius/dify/issues/1542)). - [x] [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:) - [x] Please do not modify this template :) and fill in all the required fields. ### Dify version 1.3.1 ### Cloud or Self Hosted Self Hosted (Docker) ### Steps to reproduce When I add a model using ollam, it says add successful. ![Image](https://github.com/user-attachments/assets/fe4dafa6-f127-4680-b58e-ee9b3a85ba24) However the list of models returned is empty. ![Image](https://github.com/user-attachments/assets/99e0954d-4fbf-410c-89c5-dd866ee941fa) The ollama plugin I'm using is version 0.0.6. ![Image](https://github.com/user-attachments/assets/85f00fcd-589e-4b1e-b106-c233f734dc92) ### ✔️ Expected Behavior In the lower versions, however, it is possible to add ![Image](https://github.com/user-attachments/assets/b0c5001e-11e3-475e-b04c-36e02c343b8a) ### ❌ Actual Behavior ollama's model has not been added. ![Image](https://github.com/user-attachments/assets/1e34ff48-5605-438a-978f-65d4759cd9d3)
yindo closed this issue 2026-02-21 19:14:35 -05:00
yindo commented 2026-02-21 19:14:36 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (May 15, 2025):

Hello @XGMagiie! I'm Dosu, a friendly bot here to help you with bugs, answer questions, and guide you through becoming a contributor. I'm ready to assist while you wait for a human maintainer. Let's tackle that issue together!

To resolve the issue of an empty model list being returned after adding a model in Dify with the Ollama plugin version 0.0.6, you can try the following steps:

  1. Uninstall and Reinstall the Model: Sometimes, a complete uninstall followed by a fresh installation can resolve issues related to model listing.

  2. Downgrade Dify Version: Consider downgrading Dify to an earlier version, as this has been noted to resolve similar issues [1].

  3. Check Docker Logs: Examine the logs for the docker-plugin_daemon-1 during the installation process for any error messages that might provide additional insights into the problem [1].

These steps should help in troubleshooting and potentially resolving the issue with the model list not displaying correctly.

To continue talking to Dosu, mention @dosu.

Help Dosu learn! Give it feedback: Great Response | Irrelevant Answer | Incorrect Sources | Too Verbose | Hallucination | Bug Report | Other

@dosubot[bot] commented on GitHub (May 15, 2025): <!-- Greeting --> Hello @XGMagiie! I'm [Dosu](https://dosu.dev), a friendly bot here to help you with bugs, answer questions, and guide you through becoming a contributor. I'm ready to assist while you wait for a human maintainer. Let's tackle that issue together! <!-- Answer --> To resolve the issue of an empty model list being returned after adding a model in Dify with the Ollama plugin version 0.0.6, you can try the following steps: 1. **Uninstall and Reinstall the Model:** Sometimes, a complete uninstall followed by a fresh installation can resolve issues related to model listing. 2. **Downgrade Dify Version:** Consider downgrading Dify to an earlier version, as this has been noted to resolve similar issues <sup>[[1]](https://github.com/langgenius/dify/issues/19258)</sup>. 3. **Check Docker Logs:** Examine the logs for the `docker-plugin_daemon-1` during the installation process for any error messages that might provide additional insights into the problem <sup>[[1]](https://github.com/langgenius/dify/issues/19258)</sup>. These steps should help in troubleshooting and potentially resolving the issue with the model list not displaying correctly. <!-- Dosu Comment Footer --> *To continue talking to [Dosu](https://dosu.dev), mention @dosu.* --- <sup>Help Dosu learn! Give it feedback: [Great Response](https://app.dosu.dev/response-feedback/f8fa0e87-6dcb-4e3d-893b-a1ccb5c2ec7c?feedback_type=great_response) | [Irrelevant Answer](https://app.dosu.dev/response-feedback/f8fa0e87-6dcb-4e3d-893b-a1ccb5c2ec7c?feedback_type=irrelevant_answer) | [Incorrect Sources](https://app.dosu.dev/response-feedback/f8fa0e87-6dcb-4e3d-893b-a1ccb5c2ec7c?feedback_type=incorrect_sources) | [Too Verbose](https://app.dosu.dev/response-feedback/f8fa0e87-6dcb-4e3d-893b-a1ccb5c2ec7c?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/f8fa0e87-6dcb-4e3d-893b-a1ccb5c2ec7c?feedback_type=hallucination) | [Bug Report](https://app.dosu.dev/response-feedback/f8fa0e87-6dcb-4e3d-893b-a1ccb5c2ec7c?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/f8fa0e87-6dcb-4e3d-893b-a1ccb5c2ec7c?feedback_type=other)</sup>
yindo commented 2026-02-21 19:14:36 -05:00
Author
Owner
Copy Link
Copy Source

@XGMagiie commented on GitHub (May 15, 2025):

This is the error reported by docker-plugin_daemon-1 when uploading a model, how can I fix it? @dosu.

[GIN] 2025/05/16 - 02:42:25 | 500 | 1.443978ms | 172.21.0.9 | POST "/plugin/13df7f94-4111-4cf3-bd99-b10073659255/dispatch/model/schema"

2025/05/16 02:42:25 [Recovery] 2025/05/16 - 02:42:25 panic recovered:
runtime error: invalid memory address or nil pointer dereference
/usr/local/go/src/runtime/panic.go:262 (0x476858)
/usr/local/go/src/runtime/signal_unix.go:917 (0x476828)
/app/internal/core/plugin_manager/local_runtime/stdio.go:63 (0xdadb12)
/app/internal/core/plugin_manager/local_runtime/io.go:16 (0xdab4fa)
/app/internal/core/plugin_daemon/generic.go:28 (0xfa2736)
/app/internal/core/plugin_daemon/model_service.go:159 (0xfcad8c)
/app/internal/service/invoke_model.go:323 (0xfcad72)
/app/internal/service/base_sse.go:41 (0xfd8dfe)
/app/internal/service/invoke_model.go:321 (0xfcacfb)
/app/internal/server/controllers/model.go:163 (0x149baf0)
/app/internal/server/controllers/base.go:53 (0xffb614)
/app/internal/server/controllers/base.go:31 (0xffba94)
/app/internal/server/controllers/base.go:37 (0xffb515)
/app/internal/server/controllers/model.go:160 (0x149ba33)
/go/pkg/mod/github.com/gin-gonic/gin@v1.10.0/context.go:185 (0xf5f88a)
/app/internal/server/middleware.go:170 (0x149cf73)
/go/pkg/mod/github.com/gin-gonic/gin@v1.10.0/context.go:185 (0xf5f88a)
/app/internal/server/middleware.go:97 (0x149d013)
/go/pkg/mod/github.com/gin-gonic/gin@v1.10.0/context.go:185 (0xf5f88a)
/app/internal/server/middleware.go:66 (0x14a0ad1)
/go/pkg/mod/github.com/gin-gonic/gin@v1.10.0/context.go:185 (0xf5f88a)
/app/internal/server/middleware.go:24 (0x149ac54)
/go/pkg/mod/github.com/gin-gonic/gin@v1.10.0/context.go:185 (0xf6d3ee)
/go/pkg/mod/github.com/gin-gonic/gin@v1.10.0/recovery.go:102 (0xf6d3db)
/go/pkg/mod/github.com/gin-gonic/gin@v1.10.0/context.go:185 (0xf6c524)
/go/pkg/mod/github.com/gin-gonic/gin@v1.10.0/logger.go:249 (0xf6c50b)
/go/pkg/mod/github.com/gin-gonic/gin@v1.10.0/context.go:185 (0xf6b911)
/go/pkg/mod/github.com/gin-gonic/gin@v1.10.0/gin.go:633 (0xf6b380)
/go/pkg/mod/github.com/gin-gonic/gin@v1.10.0/gin.go:589 (0xf6aeb1)
/usr/local/go/src/net/http/server.go:3210 (0x7dc92d)
/usr/local/go/src/net/http/server.go:2092 (0x7bbe4f)
/usr/local/go/src/runtime/asm_amd64.s:1700 (0x47ca40)

@XGMagiie commented on GitHub (May 15, 2025): This is the error reported by ```docker-plugin_daemon-1``` when uploading a model, how can I fix it? @dosu. [GIN] 2025/05/16 - 02:42:25 | 500 | 1.443978ms | 172.21.0.9 | POST "/plugin/13df7f94-4111-4cf3-bd99-b10073659255/dispatch/model/schema" 2025/05/16 02:42:25 [Recovery] 2025/05/16 - 02:42:25 panic recovered: runtime error: invalid memory address or nil pointer dereference /usr/local/go/src/runtime/panic.go:262 (0x476858) /usr/local/go/src/runtime/signal_unix.go:917 (0x476828) /app/internal/core/plugin_manager/local_runtime/stdio.go:63 (0xdadb12) /app/internal/core/plugin_manager/local_runtime/io.go:16 (0xdab4fa) /app/internal/core/plugin_daemon/generic.go:28 (0xfa2736) /app/internal/core/plugin_daemon/model_service.go:159 (0xfcad8c) /app/internal/service/invoke_model.go:323 (0xfcad72) /app/internal/service/base_sse.go:41 (0xfd8dfe) /app/internal/service/invoke_model.go:321 (0xfcacfb) /app/internal/server/controllers/model.go:163 (0x149baf0) /app/internal/server/controllers/base.go:53 (0xffb614) /app/internal/server/controllers/base.go:31 (0xffba94) /app/internal/server/controllers/base.go:37 (0xffb515) /app/internal/server/controllers/model.go:160 (0x149ba33) /go/pkg/mod/github.com/gin-gonic/gin@v1.10.0/context.go:185 (0xf5f88a) /app/internal/server/middleware.go:170 (0x149cf73) /go/pkg/mod/github.com/gin-gonic/gin@v1.10.0/context.go:185 (0xf5f88a) /app/internal/server/middleware.go:97 (0x149d013) /go/pkg/mod/github.com/gin-gonic/gin@v1.10.0/context.go:185 (0xf5f88a) /app/internal/server/middleware.go:66 (0x14a0ad1) /go/pkg/mod/github.com/gin-gonic/gin@v1.10.0/context.go:185 (0xf5f88a) /app/internal/server/middleware.go:24 (0x149ac54) /go/pkg/mod/github.com/gin-gonic/gin@v1.10.0/context.go:185 (0xf6d3ee) /go/pkg/mod/github.com/gin-gonic/gin@v1.10.0/recovery.go:102 (0xf6d3db) /go/pkg/mod/github.com/gin-gonic/gin@v1.10.0/context.go:185 (0xf6c524) /go/pkg/mod/github.com/gin-gonic/gin@v1.10.0/logger.go:249 (0xf6c50b) /go/pkg/mod/github.com/gin-gonic/gin@v1.10.0/context.go:185 (0xf6b911) /go/pkg/mod/github.com/gin-gonic/gin@v1.10.0/gin.go:633 (0xf6b380) /go/pkg/mod/github.com/gin-gonic/gin@v1.10.0/gin.go:589 (0xf6aeb1) /usr/local/go/src/net/http/server.go:3210 (0x7dc92d) /usr/local/go/src/net/http/server.go:2092 (0x7bbe4f) /usr/local/go/src/runtime/asm_amd64.s:1700 (0x47ca40)
yindo commented 2026-02-21 19:14:36 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (May 15, 2025):

The error you're encountering, "invalid memory address or nil pointer dereference," suggests that there might be an issue with how pointers are being handled in the code. This typically occurs when the code attempts to access a memory location that hasn't been initialized.

Here are some steps you can take to troubleshoot and potentially resolve the issue:

  1. Check for Nil Pointers: Review the code in the files mentioned in the stack trace, particularly stdio.go, io.go, generic.go, model_service.go, and invoke_model.go. Look for any pointers that might not be properly initialized before being used.

  2. Add Nil Checks: Ensure that there are checks in place to verify that pointers are not nil before they are dereferenced. This can prevent runtime errors.

  3. Review Recent Changes: If this issue started occurring after recent changes, review those changes for any modifications related to pointer handling or memory allocation.

  4. Debugging: Use debugging tools to step through the code and identify where the nil pointer dereference is occurring. This can help pinpoint the exact line and variable causing the issue.

  5. Update Dependencies: Ensure that all dependencies, including the Gin framework, are up to date. Sometimes, issues can arise from outdated libraries.

  6. Consult Documentation: If available, consult the documentation for the specific functions or methods being used to ensure they are being implemented correctly.

These steps should help you identify and fix the issue causing the nil pointer dereference.

To continue talking to Dosu, mention @dosu.

Help Dosu learn! Give it feedback: Great Response | Irrelevant Answer | Incorrect Sources | Too Verbose | Hallucination | Bug Report | Other

@dosubot[bot] commented on GitHub (May 15, 2025): <!-- Answer --> The error you're encountering, "invalid memory address or nil pointer dereference," suggests that there might be an issue with how pointers are being handled in the code. This typically occurs when the code attempts to access a memory location that hasn't been initialized. Here are some steps you can take to troubleshoot and potentially resolve the issue: 1. **Check for Nil Pointers:** Review the code in the files mentioned in the stack trace, particularly `stdio.go`, `io.go`, `generic.go`, `model_service.go`, and `invoke_model.go`. Look for any pointers that might not be properly initialized before being used. 2. **Add Nil Checks:** Ensure that there are checks in place to verify that pointers are not nil before they are dereferenced. This can prevent runtime errors. 3. **Review Recent Changes:** If this issue started occurring after recent changes, review those changes for any modifications related to pointer handling or memory allocation. 4. **Debugging:** Use debugging tools to step through the code and identify where the nil pointer dereference is occurring. This can help pinpoint the exact line and variable causing the issue. 5. **Update Dependencies:** Ensure that all dependencies, including the Gin framework, are up to date. Sometimes, issues can arise from outdated libraries. 6. **Consult Documentation:** If available, consult the documentation for the specific functions or methods being used to ensure they are being implemented correctly. These steps should help you identify and fix the issue causing the nil pointer dereference. <!-- Dosu Comment Footer --> *To continue talking to [Dosu](https://dosu.dev), mention @dosu.* --- <sup>Help Dosu learn! Give it feedback: [Great Response](https://app.dosu.dev/response-feedback/66c79fb7-4af6-4169-a19e-a7bc0c0213af?feedback_type=great_response) | [Irrelevant Answer](https://app.dosu.dev/response-feedback/66c79fb7-4af6-4169-a19e-a7bc0c0213af?feedback_type=irrelevant_answer) | [Incorrect Sources](https://app.dosu.dev/response-feedback/66c79fb7-4af6-4169-a19e-a7bc0c0213af?feedback_type=incorrect_sources) | [Too Verbose](https://app.dosu.dev/response-feedback/66c79fb7-4af6-4169-a19e-a7bc0c0213af?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/66c79fb7-4af6-4169-a19e-a7bc0c0213af?feedback_type=hallucination) | [Bug Report](https://app.dosu.dev/response-feedback/66c79fb7-4af6-4169-a19e-a7bc0c0213af?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/66c79fb7-4af6-4169-a19e-a7bc0c0213af?feedback_type=other)</sup>
yindo commented 2026-02-21 19:14:36 -05:00
Author
Owner
Copy Link
Copy Source

@XGMagiie commented on GitHub (May 15, 2025):

This seems to be a bug in the internal program, what can we as people deploying the software use to fix it? @dosu

@XGMagiie commented on GitHub (May 15, 2025): This seems to be a bug in the internal program, what can we as people deploying the software use to fix it? @dosu
yindo commented 2026-02-21 19:14:36 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (May 15, 2025):

To address the nil pointer dereference issue in the internal program, you can try the following steps:

  1. Code Review: Carefully review the code in the files mentioned in the stack trace (stdio.go, io.go, generic.go, model_service.go, and invoke_model.go). Look for any pointers that might not be initialized before use and ensure they are properly checked for nil values.

  2. Add Nil Checks: Implement checks to ensure that pointers are not nil before dereferencing them. This can prevent runtime errors and improve the stability of the application.

  3. Debugging Tools: Use debugging tools to step through the code execution. This can help you identify the exact location and cause of the nil pointer dereference. Tools like GDB or Delve can be useful for this purpose.

  4. Update Software: Ensure that you are using the latest version of Dify and its dependencies. Sometimes, bugs are fixed in newer releases, so updating might resolve the issue.

  5. Consult Changelog: Review the changelog or release notes for any recent updates that might have affected pointer handling. This can provide insights into any changes that might have introduced the issue [1].

By following these steps, you should be able to identify and address the root cause of the nil pointer dereference in your deployment.

To continue talking to Dosu, mention @dosu.

Help Dosu learn! Give it feedback: Great Response | Irrelevant Answer | Incorrect Sources | Too Verbose | Hallucination | Bug Report | Other

@dosubot[bot] commented on GitHub (May 15, 2025): <!-- Answer --> To address the nil pointer dereference issue in the internal program, you can try the following steps: 1. **Code Review:** Carefully review the code in the files mentioned in the stack trace (`stdio.go`, `io.go`, `generic.go`, `model_service.go`, and `invoke_model.go`). Look for any pointers that might not be initialized before use and ensure they are properly checked for nil values. 2. **Add Nil Checks:** Implement checks to ensure that pointers are not nil before dereferencing them. This can prevent runtime errors and improve the stability of the application. 3. **Debugging Tools:** Use debugging tools to step through the code execution. This can help you identify the exact location and cause of the nil pointer dereference. Tools like GDB or Delve can be useful for this purpose. 4. **Update Software:** Ensure that you are using the latest version of Dify and its dependencies. Sometimes, bugs are fixed in newer releases, so updating might resolve the issue. 5. **Consult Changelog:** Review the changelog or release notes for any recent updates that might have affected pointer handling. This can provide insights into any changes that might have introduced the issue <sup>[[1]](https://github.com/langgenius/dify/blob/main/web/app/components/header/account-about/index.tsx)</sup>. By following these steps, you should be able to identify and address the root cause of the nil pointer dereference in your deployment. <!-- Dosu Comment Footer --> *To continue talking to [Dosu](https://dosu.dev), mention @dosu.* --- <sup>Help Dosu learn! Give it feedback: [Great Response](https://app.dosu.dev/response-feedback/c7e25c47-df6e-4e29-a4fc-184376b4aded?feedback_type=great_response) | [Irrelevant Answer](https://app.dosu.dev/response-feedback/c7e25c47-df6e-4e29-a4fc-184376b4aded?feedback_type=irrelevant_answer) | [Incorrect Sources](https://app.dosu.dev/response-feedback/c7e25c47-df6e-4e29-a4fc-184376b4aded?feedback_type=incorrect_sources) | [Too Verbose](https://app.dosu.dev/response-feedback/c7e25c47-df6e-4e29-a4fc-184376b4aded?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/c7e25c47-df6e-4e29-a4fc-184376b4aded?feedback_type=hallucination) | [Bug Report](https://app.dosu.dev/response-feedback/c7e25c47-df6e-4e29-a4fc-184376b4aded?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/c7e25c47-df6e-4e29-a4fc-184376b4aded?feedback_type=other)</sup>
yindo commented 2026-02-21 19:14:36 -05:00
Author
Owner
Copy Link
Copy Source

@XGMagiie commented on GitHub (May 15, 2025):

I deployed dedify on my intranet, how can I fix this? @dosu
[ERROR]init environment failed: failed to install dependencies: exit status 2, output: error: Failed to fetch: https://mirrors.aliyun.com/pypi/simple/numpy/
Caused by: Request failed after 3 retries
Caused by: error sending request for url (https://mirrors.aliyun.com/pypi/simple/numpy/)
Caused by: operation timed out
, retry in 30s

@XGMagiie commented on GitHub (May 15, 2025): I deployed dedify on my intranet, how can I fix this? @dosu [ERROR]init environment failed: failed to install dependencies: exit status 2, output: error: Failed to fetch: `https://mirrors.aliyun.com/pypi/simple/numpy/` Caused by: Request failed after 3 retries Caused by: error sending request for url (https://mirrors.aliyun.com/pypi/simple/numpy/) Caused by: operation timed out , retry in 30s
yindo commented 2026-02-21 19:14:36 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (May 15, 2025):

To resolve the issue of failed dependency installation due to a timeout when deploying Dedify on your intranet, you can try the following solutions:

  1. Check Network Connectivity: Ensure your server has stable network access to the specified PyPI mirror (https://mirrors.aliyun.com).

  2. Use a Different PyPI Mirror: Consider using a different PyPI mirror that is more accessible from your location. For example, you can set the PIP mirror URL to Tsinghua University's mirror:

    PIP_MIRROR_URL=https://pypi.tuna.tsinghua.edu.cn/simple

    Set this environment variable in your docker-compose.yaml file and restart the relevant services or containers.

  3. Increase Timeout Settings: Increase the timeout setting for the Python environment initialization by adding the following environment variable to your .env file:

    PLUGIN_PYTHON_ENV_INIT_TIMEOUT=720

    After making these changes, restart your Docker containers using:

    docker compose down && docker compose up -d

  4. Firewall and Proxy Settings: Ensure any firewalls or proxy settings allow access to the mirror URL [1][2][3][4][5].

To continue talking to Dosu, mention @dosu.

Help Dosu learn! Give it feedback: Great Response | Irrelevant Answer | Incorrect Sources | Too Verbose | Hallucination | Bug Report | Other

@dosubot[bot] commented on GitHub (May 15, 2025): <!-- Answer --> To resolve the issue of failed dependency installation due to a timeout when deploying Dedify on your intranet, you can try the following solutions: 1. **Check Network Connectivity**: Ensure your server has stable network access to the specified PyPI mirror (https://mirrors.aliyun.com). 2. **Use a Different PyPI Mirror**: Consider using a different PyPI mirror that is more accessible from your location. For example, you can set the PIP mirror URL to Tsinghua University's mirror: ```sh PIP_MIRROR_URL=https://pypi.tuna.tsinghua.edu.cn/simple ``` Set this environment variable in your `docker-compose.yaml` file and restart the relevant services or containers. 3. **Increase Timeout Settings**: Increase the timeout setting for the Python environment initialization by adding the following environment variable to your `.env` file: ```sh PLUGIN_PYTHON_ENV_INIT_TIMEOUT=720 ``` After making these changes, restart your Docker containers using: ```sh docker compose down && docker compose up -d ``` 4. **Firewall and Proxy Settings**: Ensure any firewalls or proxy settings allow access to the mirror URL <sup>[[1]](https://github.com/langgenius/dify/issues/19571)</sup><sup>[[2]](https://github.com/langgenius/dify/issues/16868)</sup><sup>[[3]](https://github.com/langgenius/dify/issues/14553)</sup><sup>[[4]](https://github.com/langgenius/dify/issues/16999)</sup><sup>[[5]](https://github.com/langgenius/dify/issues/16418)</sup>. <!-- Dosu Comment Footer --> *To continue talking to [Dosu](https://dosu.dev), mention @dosu.* --- <sup>Help Dosu learn! Give it feedback: [Great Response](https://app.dosu.dev/response-feedback/3281a259-b5a7-4439-afdb-3b52566746cf?feedback_type=great_response) | [Irrelevant Answer](https://app.dosu.dev/response-feedback/3281a259-b5a7-4439-afdb-3b52566746cf?feedback_type=irrelevant_answer) | [Incorrect Sources](https://app.dosu.dev/response-feedback/3281a259-b5a7-4439-afdb-3b52566746cf?feedback_type=incorrect_sources) | [Too Verbose](https://app.dosu.dev/response-feedback/3281a259-b5a7-4439-afdb-3b52566746cf?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/3281a259-b5a7-4439-afdb-3b52566746cf?feedback_type=hallucination) | [Bug Report](https://app.dosu.dev/response-feedback/3281a259-b5a7-4439-afdb-3b52566746cf?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/3281a259-b5a7-4439-afdb-3b52566746cf?feedback_type=other)</sup>
yindo commented 2026-02-21 19:14:37 -05:00
Author
Owner
Copy Link
Copy Source

@XiaoRanLiu3119 commented on GitHub (Jun 17, 2025):

Hello, I noticed you closed the issue. Could you please share how you resolved it? I also attempted an offline deployment and ran into the same problem. Following the robot's instructions, I added configurations to the .evn file, but the internal network still cannot access the image address.

你好，我看你关了issue，请问如何解决的，我尝试离线部署，也遇见这个问题了，按照机器人回复，为.env文件添加了配置，但内网无法访问镜像地址

@XiaoRanLiu3119 commented on GitHub (Jun 17, 2025): Hello, I noticed you closed the issue. Could you please share how you resolved it? I also attempted an offline deployment and ran into the same problem. Following the robot's instructions, I added configurations to the .evn file, but the internal network still cannot access the image address. 你好，我看你关了issue，请问如何解决的，我尝试离线部署，也遇见这个问题了，按照机器人回复，为.env文件添加了配置，但内网无法访问镜像地址
yindo commented 2026-02-21 19:14:37 -05:00
Author
Owner
Copy Link
Copy Source

@BobTwain commented on GitHub (Jun 20, 2025):

I met the same question.when I deployI encountered the same issue. When I privately deployed Dify, there was a lack of network configuration settings for plugins. So, I used a plugin packaging tool on the public network to package and integrate it into Dify. Now, when trying to use the plugin to access the internally deployed LLM, it prompts that the modification was successful, but returns an empty list. Upon checking the logs of the plugin Docker, it shows 'invalid memory address or nil pointer dereference'.

@BobTwain commented on GitHub (Jun 20, 2025): I met the same question.when I deployI encountered the same issue. When I privately deployed Dify, there was a lack of network configuration settings for plugins. So, I used a plugin packaging tool on the public network to package and integrate it into Dify. Now, when trying to use the plugin to access the internally deployed LLM, it prompts that the modification was successful, but returns an empty list. Upon checking the logs of the plugin Docker, it shows 'invalid memory address or nil pointer dereference'.
yindo commented 2026-02-21 19:14:37 -05:00
Author
Owner
Copy Link
Copy Source

@GHOSTHAOHAO commented on GitHub (Jun 23, 2025):

I met the same question.when I deployI encountered the same issue. When I privately deployed Dify, there was a lack of network configuration settings for plugins. So, I used a plugin packaging tool on the public network to package and integrate it into Dify. Now, when trying to use the plugin to access the internally deployed LLM, it prompts that the modification was successful, but returns an empty list. Upon checking the logs of the plugin Docker, it shows 'invalid memory address or nil pointer dereference'.

I met the same question too

@GHOSTHAOHAO commented on GitHub (Jun 23, 2025): > I met the same question.when I deployI encountered the same issue. When I privately deployed Dify, there was a lack of network configuration settings for plugins. So, I used a plugin packaging tool on the public network to package and integrate it into Dify. Now, when trying to use the plugin to access the internally deployed LLM, it prompts that the modification was successful, but returns an empty list. Upon checking the logs of the plugin Docker, it shows 'invalid memory address or nil pointer dereference'. I met the same question too
yindo commented 2026-02-21 19:14:37 -05:00
Author
Owner
Copy Link
Copy Source

@wangxm345566462 commented on GitHub (Jun 25, 2025):

I met the same question too

dify_plugin_daemon.3.7xm28g7ulz56@MiWiFi-R3600-srv    | 
dify_plugin_daemon.3.7xm28g7ulz56@MiWiFi-R3600-srv    | 2025/06/25 17:49:54 [Recovery] 2025/06/25 - 17:49:54 panic recovered:
dify_plugin_daemon.3.7xm28g7ulz56@MiWiFi-R3600-srv    | runtime error: invalid memory address or nil pointer dereference
dify_plugin_daemon.3.7xm28g7ulz56@MiWiFi-R3600-srv    | /usr/local/go/src/runtime/panic.go:262 (0x4771d8)
dify_plugin_daemon.3.7xm28g7ulz56@MiWiFi-R3600-srv    | /usr/local/go/src/runtime/signal_unix.go:917 (0x4771a8)
dify_plugin_daemon.3.7xm28g7ulz56@MiWiFi-R3600-srv    | /app/internal/core/plugin_manager/local_runtime/stdio.go:85 (0xdbec32)
dify_plugin_daemon.3.7xm28g7ulz56@MiWiFi-R3600-srv    | /app/internal/core/plugin_manager/local_runtime/io.go:16 (0xdbc59a)
dify_plugin_daemon.3.7xm28g7ulz56@MiWiFi-R3600-srv    | /app/internal/core/plugin_daemon/generic.go:27 (0xfdbc96)
dify_plugin_daemon.3.7xm28g7ulz56@MiWiFi-R3600-srv    | /app/internal/core/plugin_daemon/model.gen.go:18 (0xff3b2b)
dify_plugin_daemon.3.7xm28g7ulz56@MiWiFi-R3600-srv    | /app/internal/service/model.gen.go:23 (0xff3b12)
dify_plugin_daemon.3.7xm28g7ulz56@MiWiFi-R3600-srv    | /app/internal/service/base_sse.go:116 (0x1006e3a)
dify_plugin_daemon.3.7xm28g7ulz56@MiWiFi-R3600-srv    | /app/internal/service/base_sse.go:44 (0x100709e)
dify_plugin_daemon.3.7xm28g7ulz56@MiWiFi-R3600-srv    | /app/internal/service/base_sse.go:114 (0x1006d84)
dify_plugin_daemon.3.7xm28g7ulz56@MiWiFi-R3600-srv    | /app/internal/service/model.gen.go:21 (0xff3ad1)
dify_plugin_daemon.3.7xm28g7ulz56@MiWiFi-R3600-srv    | /app/internal/server/controllers/model.gen.go:20 (0x1eb1208)
dify_plugin_daemon.3.7xm28g7ulz56@MiWiFi-R3600-srv    | /app/internal/server/controllers/base.go:53 (0x102abdb)
dify_plugin_daemon.3.7xm28g7ulz56@MiWiFi-R3600-srv    | /app/internal/server/controllers/base.go:31 (0x102b041)
dify_plugin_daemon.3.7xm28g7ulz56@MiWiFi-R3600-srv    | /app/internal/server/controllers/base.go:37 (0x102aaf5)
dify_plugin_daemon.3.7xm28g7ulz56@MiWiFi-R3600-srv    | /app/internal/server/controllers/model.gen.go:17 (0x1eb1153)
dify_plugin_daemon.3.7xm28g7ulz56@MiWiFi-R3600-srv    | /go/pkg/mod/github.com/gin-gonic/gin@v1.10.0/context.go:185 (0xf7d48a)
dify_plugin_daemon.3.7xm28g7ulz56@MiWiFi-R3600-srv    | /app/internal/server/middleware.go:170 (0x1eb2cd3)
dify_plugin_daemon.3.7xm28g7ulz56@MiWiFi-R3600-srv    | /go/pkg/mod/github.com/gin-gonic/gin@v1.10.0/context.go:185 (0xf7d48a)
dify_plugin_daemon.3.7xm28g7ulz56@MiWiFi-R3600-srv    | /app/internal/server/middleware.go:97 (0x1eb2d73)
dify_plugin_daemon.3.7xm28g7ulz56@MiWiFi-R3600-srv    | /go/pkg/mod/github.com/gin-gonic/gin@v1.10.0/context.go:185 (0xf7d48a)
dify_plugin_daemon.3.7xm28g7ulz56@MiWiFi-R3600-srv    | /app/internal/server/middleware.go:66 (0x1eb6df1)
dify_plugin_daemon.3.7xm28g7ulz56@MiWiFi-R3600-srv    | /go/pkg/mod/github.com/gin-gonic/gin@v1.10.0/context.go:185 (0xf7d48a)
dify_plugin_daemon.3.7xm28g7ulz56@MiWiFi-R3600-srv    | /app/internal/server/middleware.go:24 (0x1eb2514)
dify_plugin_daemon.3.7xm28g7ulz56@MiWiFi-R3600-srv    | /go/pkg/mod/github.com/gin-gonic/gin@v1.10.0/context.go:185 (0xf8afee)
dify_plugin_daemon.3.7xm28g7ulz56@MiWiFi-R3600-srv    | /go/pkg/mod/github.com/gin-gonic/gin@v1.10.0/recovery.go:102 (0xf8afdb)
dify_plugin_daemon.3.7xm28g7ulz56@MiWiFi-R3600-srv    | /go/pkg/mod/github.com/gin-gonic/gin@v1.10.0/context.go:185 (0xf8a124)
dify_plugin_daemon.3.7xm28g7ulz56@MiWiFi-R3600-srv    | /go/pkg/mod/github.com/gin-gonic/gin@v1.10.0/logger.go:249 (0xf8a10b)
dify_plugin_daemon.3.7xm28g7ulz56@MiWiFi-R3600-srv    | /go/pkg/mod/github.com/gin-gonic/gin@v1.10.0/context.go:185 (0xf89511)
dify_plugin_daemon.3.7xm28g7ulz56@MiWiFi-R3600-srv    | /go/pkg/mod/github.com/gin-gonic/gin@v1.10.0/gin.go:633 (0xf88f80)
dify_plugin_daemon.3.7xm28g7ulz56@MiWiFi-R3600-srv    | /go/pkg/mod/github.com/gin-gonic/gin@v1.10.0/gin.go:589 (0xf88ab1)
dify_plugin_daemon.3.7xm28g7ulz56@MiWiFi-R3600-srv    | /usr/local/go/src/net/http/server.go:3210 (0x7e26ed)
dify_plugin_daemon.3.7xm28g7ulz56@MiWiFi-R3600-srv    | /usr/local/go/src/net/http/server.go:2092 (0x7c1c0f)
dify_plugin_daemon.3.7xm28g7ulz56@MiWiFi-R3600-srv    | /usr/local/go/src/runtime/asm_amd64.s:1700 (0x47d3c0)
dify_plugin_daemon.3.7xm28g7ulz56@MiWiFi-R3600-srv    |
@wangxm345566462 commented on GitHub (Jun 25, 2025): I met the same question too ``` dify_plugin_daemon.3.7xm28g7ulz56@MiWiFi-R3600-srv | dify_plugin_daemon.3.7xm28g7ulz56@MiWiFi-R3600-srv | 2025/06/25 17:49:54 [Recovery] 2025/06/25 - 17:49:54 panic recovered: dify_plugin_daemon.3.7xm28g7ulz56@MiWiFi-R3600-srv | runtime error: invalid memory address or nil pointer dereference dify_plugin_daemon.3.7xm28g7ulz56@MiWiFi-R3600-srv | /usr/local/go/src/runtime/panic.go:262 (0x4771d8) dify_plugin_daemon.3.7xm28g7ulz56@MiWiFi-R3600-srv | /usr/local/go/src/runtime/signal_unix.go:917 (0x4771a8) dify_plugin_daemon.3.7xm28g7ulz56@MiWiFi-R3600-srv | /app/internal/core/plugin_manager/local_runtime/stdio.go:85 (0xdbec32) dify_plugin_daemon.3.7xm28g7ulz56@MiWiFi-R3600-srv | /app/internal/core/plugin_manager/local_runtime/io.go:16 (0xdbc59a) dify_plugin_daemon.3.7xm28g7ulz56@MiWiFi-R3600-srv | /app/internal/core/plugin_daemon/generic.go:27 (0xfdbc96) dify_plugin_daemon.3.7xm28g7ulz56@MiWiFi-R3600-srv | /app/internal/core/plugin_daemon/model.gen.go:18 (0xff3b2b) dify_plugin_daemon.3.7xm28g7ulz56@MiWiFi-R3600-srv | /app/internal/service/model.gen.go:23 (0xff3b12) dify_plugin_daemon.3.7xm28g7ulz56@MiWiFi-R3600-srv | /app/internal/service/base_sse.go:116 (0x1006e3a) dify_plugin_daemon.3.7xm28g7ulz56@MiWiFi-R3600-srv | /app/internal/service/base_sse.go:44 (0x100709e) dify_plugin_daemon.3.7xm28g7ulz56@MiWiFi-R3600-srv | /app/internal/service/base_sse.go:114 (0x1006d84) dify_plugin_daemon.3.7xm28g7ulz56@MiWiFi-R3600-srv | /app/internal/service/model.gen.go:21 (0xff3ad1) dify_plugin_daemon.3.7xm28g7ulz56@MiWiFi-R3600-srv | /app/internal/server/controllers/model.gen.go:20 (0x1eb1208) dify_plugin_daemon.3.7xm28g7ulz56@MiWiFi-R3600-srv | /app/internal/server/controllers/base.go:53 (0x102abdb) dify_plugin_daemon.3.7xm28g7ulz56@MiWiFi-R3600-srv | /app/internal/server/controllers/base.go:31 (0x102b041) dify_plugin_daemon.3.7xm28g7ulz56@MiWiFi-R3600-srv | /app/internal/server/controllers/base.go:37 (0x102aaf5) dify_plugin_daemon.3.7xm28g7ulz56@MiWiFi-R3600-srv | /app/internal/server/controllers/model.gen.go:17 (0x1eb1153) dify_plugin_daemon.3.7xm28g7ulz56@MiWiFi-R3600-srv | /go/pkg/mod/github.com/gin-gonic/gin@v1.10.0/context.go:185 (0xf7d48a) dify_plugin_daemon.3.7xm28g7ulz56@MiWiFi-R3600-srv | /app/internal/server/middleware.go:170 (0x1eb2cd3) dify_plugin_daemon.3.7xm28g7ulz56@MiWiFi-R3600-srv | /go/pkg/mod/github.com/gin-gonic/gin@v1.10.0/context.go:185 (0xf7d48a) dify_plugin_daemon.3.7xm28g7ulz56@MiWiFi-R3600-srv | /app/internal/server/middleware.go:97 (0x1eb2d73) dify_plugin_daemon.3.7xm28g7ulz56@MiWiFi-R3600-srv | /go/pkg/mod/github.com/gin-gonic/gin@v1.10.0/context.go:185 (0xf7d48a) dify_plugin_daemon.3.7xm28g7ulz56@MiWiFi-R3600-srv | /app/internal/server/middleware.go:66 (0x1eb6df1) dify_plugin_daemon.3.7xm28g7ulz56@MiWiFi-R3600-srv | /go/pkg/mod/github.com/gin-gonic/gin@v1.10.0/context.go:185 (0xf7d48a) dify_plugin_daemon.3.7xm28g7ulz56@MiWiFi-R3600-srv | /app/internal/server/middleware.go:24 (0x1eb2514) dify_plugin_daemon.3.7xm28g7ulz56@MiWiFi-R3600-srv | /go/pkg/mod/github.com/gin-gonic/gin@v1.10.0/context.go:185 (0xf8afee) dify_plugin_daemon.3.7xm28g7ulz56@MiWiFi-R3600-srv | /go/pkg/mod/github.com/gin-gonic/gin@v1.10.0/recovery.go:102 (0xf8afdb) dify_plugin_daemon.3.7xm28g7ulz56@MiWiFi-R3600-srv | /go/pkg/mod/github.com/gin-gonic/gin@v1.10.0/context.go:185 (0xf8a124) dify_plugin_daemon.3.7xm28g7ulz56@MiWiFi-R3600-srv | /go/pkg/mod/github.com/gin-gonic/gin@v1.10.0/logger.go:249 (0xf8a10b) dify_plugin_daemon.3.7xm28g7ulz56@MiWiFi-R3600-srv | /go/pkg/mod/github.com/gin-gonic/gin@v1.10.0/context.go:185 (0xf89511) dify_plugin_daemon.3.7xm28g7ulz56@MiWiFi-R3600-srv | /go/pkg/mod/github.com/gin-gonic/gin@v1.10.0/gin.go:633 (0xf88f80) dify_plugin_daemon.3.7xm28g7ulz56@MiWiFi-R3600-srv | /go/pkg/mod/github.com/gin-gonic/gin@v1.10.0/gin.go:589 (0xf88ab1) dify_plugin_daemon.3.7xm28g7ulz56@MiWiFi-R3600-srv | /usr/local/go/src/net/http/server.go:3210 (0x7e26ed) dify_plugin_daemon.3.7xm28g7ulz56@MiWiFi-R3600-srv | /usr/local/go/src/net/http/server.go:2092 (0x7c1c0f) dify_plugin_daemon.3.7xm28g7ulz56@MiWiFi-R3600-srv | /usr/local/go/src/runtime/asm_amd64.s:1700 (0x47d3c0) dify_plugin_daemon.3.7xm28g7ulz56@MiWiFi-R3600-srv | ```
yindo commented 2026-02-21 19:14:37 -05:00
Author
Owner
Copy Link
Copy Source

@zhangchangwei commented on GitHub (Jul 7, 2025):

I met the same question too

@zhangchangwei commented on GitHub (Jul 7, 2025): I met the same question too
yindo commented 2026-02-21 19:14:37 -05:00
Author
Owner
Copy Link
Copy Source

@happy-dogsss commented on GitHub (Jul 14, 2025):

I met the same question too

@happy-dogsss commented on GitHub (Jul 14, 2025): I met the same question too
yindo commented 2026-02-21 19:14:37 -05:00
Author
Owner
Copy Link
Copy Source

@lyz04551 commented on GitHub (Jul 17, 2025):

I met the same question too

@lyz04551 commented on GitHub (Jul 17, 2025): I met the same question too
yindo commented 2026-02-21 19:14:37 -05:00
Author
Owner
Copy Link
Copy Source

@zhangxuan1 commented on GitHub (Aug 25, 2025):

我的方法是chmod -R 777 Qwen3-32B
我使用的是非root用户，在执行操作时需要使用sudo，我就怀疑是不是权限不足导致，尝试给777以后重启了一下llm和dify 然后这个问题就解决了。

@zhangxuan1 commented on GitHub (Aug 25, 2025): 我的方法是chmod -R 777 Qwen3-32B 我使用的是非root用户，在执行操作时需要使用sudo，我就怀疑是不是权限不足导致，尝试给777以后重启了一下llm和dify 然后这个问题就解决了。
yindo commented 2026-02-21 19:14:37 -05:00
Author
Owner
Copy Link
Copy Source

@haiya512 commented on GitHub (Sep 23, 2025):

我的方法是chmod -R 777 Qwen3-32B 我使用的是非root用户，在执行操作时需要使用sudo，我就怀疑是不是权限不足导致，尝试给777以后重启了一下llm和dify 然后这个问题就解决了。

我都没看到这个目录。还有哪里需要改权限吗？ rocky Linux8.9 root运行的

@haiya512 commented on GitHub (Sep 23, 2025): > 我的方法是chmod -R 777 Qwen3-32B 我使用的是非root用户，在执行操作时需要使用sudo，我就怀疑是不是权限不足导致，尝试给777以后重启了一下llm和dify 然后这个问题就解决了。 我都没看到这个目录。还有哪里需要改权限吗？ rocky Linux8.9 root运行的
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Knowledge Pipeline
Proposal
WIP
cloud
dependencies
feat:webapp
good first issue
outdated
performance
pull-request
Mirrored from GitHub Pull Request
 python:uv
refactor
size:L
stale
status: accepting prs
status: blocked
status: in discussion
stt & tts
vulnerablity
web
wont-fix
🌊 feat:workflow
🌚 invalid
🐞 bug
👻 feat:rag
💪 enhancement
📚 documentation
🔨 feat:tools
🙋‍♂️ question
🙏 help wanted
🤔 cant-reproduce
🤖 feat:agent
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: langgenius/dify#13929
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?