mirror of
https://github.com/langgenius/dify-official-plugins.git
synced 2026-07-21 17:45:23 -04:00
The updated ollama model is no longer usable. #625
Reference in New Issue
Block a user
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?
Originally created by @Ooooovini on GitHub (Sep 5, 2025).
Self Checks
Dify version
1.8.1
Cloud or Self Hosted
Self Hosted (Docker)
Steps to reproduce
After the update, the Ollama model became 0, but in the credential management section, there is my original model. Therefore, the Ollama model cannot be used now. Why is this?
✔️ Expected Behavior
Hope you can provide me with a solution.
❌ Actual Behavior
No response
@dosubot[bot] commented on GitHub (Sep 5, 2025):
This is a known issue caused by breaking changes in credential management starting with Dify v1.8.0. During the upgrade, model credentials were migrated to new tables. If the migration was incomplete or references broke, your Ollama models may now point to credential IDs that no longer exist, which results in the model count showing as zero and the models being unusable—even though the credentials still appear in the UI.
To fix this, you need to manually check your database: make sure each Ollama model’s
credential_idin theprovider_modelstable matches a valid entry inprovider_model_credentials. If not, create a new credential entry and update the reference. Newly created Ollama models after the upgrade should work, since their credentials are registered correctly. For more details and schema info, see this discussion and PRs langgenius/dify#24451 and langgenius/dify#24545.If you continue to have issues after correcting the database, check your backend logs for errors when you try to use or edit Ollama models—these can help pinpoint any remaining problems.
To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other
@Ooooovini commented on GitHub (Sep 5, 2025):
@dosu.However, I didn't receive any error message，e.g.Credential with id xxxxx not found. Instead, it showed that the modification was successful, but still, it indicated that there were 0 models. Moreover, even after deleting the original ollama model and rebuilding a new one, it didn't work.
@dosubot[bot] commented on GitHub (Sep 5, 2025):
This is a known issue in recent Dify versions: the UI can show "modification successful" even if the Ollama model isn't actually registered due to silent backend failures or validation problems. Common causes include missing required fields, credential/model reference mismatches, or caching issues in Docker setups. Restarting all related containers (
dify,plugin_daemon,ssrf_proxy) can sometimes resolve cache problems, but if the issue persists after recreating the model, it's likely a bug in credential/model management logic [source 1] [source 2].Recent updates (PRs #24994 and #25009, merged 2025-09-03) refactored credential and model registration, fixed UI refresh bugs, and improved backend validation. Upgrading to the latest Dify version should resolve the issue and restore Ollama model usability. If you can't upgrade immediately, double-check your database for correct credential references and restart all containers after any config changes [source 3].
If the problem continues, check backend logs for errors during model creation—even if the UI shows success, there may be silent exceptions preventing registration.
To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other
@Ooooovini commented on GitHub (Sep 5, 2025):
Is the latest version you mentioned 2.0.0? And how to check if the database has the correct credential references@dosu
@dosubot[bot] commented on GitHub (Sep 5, 2025):
There’s no confirmation in the repo that 2.0.0 is the latest Dify version as of now—recent PRs mention semantic versioning improvements but don’t reference a 2.0.0 release.
To check if your database has correct credential references for Ollama models, you’ll need direct DB access. In your database, look at the provider_models table: each Ollama model should have a credential_id. For each credential_id, make sure there’s a matching id in the provider_model_credentials table, and that tenant_id, provider_name, model_name, and model_type match in both tables. If any credential_id is missing or mismatched, update it so the reference is valid. This relationship is defined in the Dify codebase and is required for models to be usable [source].
Example SQL to find mismatches (PostgreSQL syntax):
If this returns any rows, those models have missing or broken credential references. Fix by updating credential_id to a valid one from provider_model_credentials.
To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other
@Ooooovini commented on GitHub (Sep 6, 2025):
@dosuI cleared the browser cache and checked the database to ensure that there were correct credential references for the Ollama models. However, there were still no models. Are there any other solutions?
@dosubot[bot] commented on GitHub (Sep 6, 2025):
Here are some additional steps you can try:
Restart all related Docker containers (
dify,plugin_daemon,ssrf_proxy, andollama). This often resolves issues where Ollama models don't appear in the UI even after a "modification successful" message, due to cache or backend state problems [source].Make sure your Ollama service is accessible from inside the Dify container. Use
host.docker.internalor your host's LAN IP as the base URL, and setOLLAMA_HOST=0.0.0.0on your host machine [source]. After changing these, restart both Ollama and Dify services.Check that your models are actually loaded in Ollama by running
ollama listorcurl http://<ollama-host>:11434/v1/modelsinside the container. If the result is empty, pull the models first using the Ollama client (e.g.,ollama pull <model-name>) [source].Review backend logs (API, plugin_daemon) for errors or warnings when you try to add or list Ollama models. Silent backend failures can prevent models from being registered or displayed, even if the UI shows success.
Double-check that the
is_validflag in theprovider_modelstable and theenabledflag inProviderModelSettingare set toTruefor your Ollama models. If not, update them in the database [source].If you recently upgraded Dify, it may take up to 2 hours for Ollama models to reappear as the system reinitializes connections [source].
If none of these steps work, gather logs and configuration details for further analysis. Let me know what you find!
To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other
@Ooooovini commented on GitHub (Sep 6, 2025):
When I added the model, the backend log plugin_daemon showed an error:
@dosubot[bot] commented on GitHub (Sep 6, 2025):
Yes, the Go runtime panic in plugin_daemon is directly related to your issue—this kind of backend error can prevent Ollama models from being registered or displayed, even if the UI shows a success message. The most common cause is missing or broken Python virtual environment symlinks inside the plugin_daemon Docker container, especially if Docker volumes were migrated using zip (which loses symlinks). To fix this, recreate the Python virtual environment inside the container, install the required packages, and copy the environment to the correct plugin directory. Using tar to package and migrate Docker volumes preserves symlinks and prevents this issue. After fixing the environment and symlinks, restart the containers and the panic should stop, making models usable again. More details and step-by-step instructions are in this thread: dify-official-plugins/issues/1045.
If you didn't migrate volumes or this doesn't apply, the panic may be caused by missing or malformed model/credential data or environment variables. In that case, check that all required fields and configs are present, and that the plugin_daemon container has access to all necessary dependencies. Improving error handling in plugin_daemon would prevent these panics, but for now, repairing the environment is the most effective workaround.
To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other
