Mintplex-Labs/anything-llm
1
0
Fork 0
mirror of https://github.com/Mintplex-Labs/anything-llm.git synced 2026-07-19 22:23:50 -04:00
Code Issues 328 Packages Projects Releases 10 Wiki Activity

[GH-ISSUE #5182] [BUG]: Ollama returns “invalid option provided: use_mlock” in version 1.11.1 – Deprecated parameter still being sent #4957

New Issue
Closed
opened 2026-06-05 14:51:07 -04:00 by yindo · 4 comments
yindo commented 2026-06-05 14:51:07 -04:00
Owner
Copy Link
Copy Source

Originally created by @raucodes on GitHub (Mar 10, 2026).
Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/5182

How are you running AnythingLLM?

Docker (local)

What happened?

Da ich als KI keinen direkten Zugriff auf das GitHub-Repository habe, um eine echte Issue zu erstellen (dafür bräuchte ich deinen GitHub-Login), habe ich dir den vollständigen Text für das Issue vorbereitet. Du kannst diesen Inhalt kopieren und direkt auf GitHub einfügen.

Das Issue ist so formuliert, dass es klarstellt, dass der Parameter use_mlock in der Version 1.11.1 gesendet wird, von Ollama jedoch als ungültig abgelehnt wird, und fordert die Entwickler auf, diesen Parameter aus der Anfrage zu entfernen.

Description

I am running AnythingLLM version 1.11.1 connected to a local Ollama instance. When attempting to load or chat with a model, the Ollama server logs show the following error:

invalid option provided option=use_mlock

It appears that AnythingLLM is still including the use_mlock parameter in its API requests to Ollama. This parameter seems to be deprecated or no longer supported by the current version of Ollama, causing the request to fail or the model to refuse loading.

According to Ollama documentation and behavior, mlock (memory locking) is often handled automatically via mmap or via specific environment variables, rather than as a direct API request option in the current API spec. Sending this parameter explicitly triggers an "invalid option" error.

Expected Behavior

AnythingLLM should either:

  1. Detect that use_mlock is invalid/supported and remove it from the request payload before sending it to Ollama.
  2. Or, rely on Ollama's default behavior for memory management without forcing this specific flag via the API.

Steps to Reproduce

  1. Install AnythingLLM Docker version 1.11.1.
  2. Configure an Ollama instance as the LLM provider.
  3. Attempt to select or load a model.
  4. Check the Ollama server logs.
  5. Observe the error: invalid option provided option=use_mlock.

Suggested Fix

Please review the code responsible for constructing the Ollama API request body in version 1.11.1 and remove the use_mlock parameter from the payload unless it is explicitly supported by the target Ollama version. Ollama should be allowed to handle memory locking internally if needed.

Environment

  • AnythingLLM Version: 1.11.1
  • Ollama Version: 0.17.8
  • OS: macOS
  • Connection: localhost

Additional Context

This error prevents smooth integration. Removing the obsolete parameter should restore full functionality.

Are there known steps to reproduce?

No response

Originally created by @raucodes on GitHub (Mar 10, 2026). Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/5182 ### How are you running AnythingLLM? Docker (local) ### What happened? Da ich als KI keinen direkten Zugriff auf das GitHub-Repository habe, um eine echte Issue zu erstellen (dafür bräuchte ich deinen GitHub-Login), habe ich dir den **vollständigen Text** für das Issue vorbereitet. Du kannst diesen Inhalt kopieren und direkt auf GitHub einfügen. Das Issue ist so formuliert, dass es klarstellt, dass der Parameter `use_mlock` in der Version 1.11.1 gesendet wird, von Ollama jedoch als ungültig abgelehnt wird, und fordert die Entwickler auf, diesen Parameter aus der Anfrage zu entfernen. ### Description I am running **AnythingLLM version 1.11.1** connected to a local **Ollama** instance. When attempting to load or chat with a model, the Ollama server logs show the following error: ``` invalid option provided option=use_mlock ``` It appears that AnythingLLM is still including the `use_mlock` parameter in its API requests to Ollama. This parameter seems to be deprecated or no longer supported by the current version of Ollama, causing the request to fail or the model to refuse loading. According to Ollama documentation and behavior, `mlock` (memory locking) is often handled automatically via `mmap` or via specific environment variables, rather than as a direct API request option in the current API spec. Sending this parameter explicitly triggers an "invalid option" error. ### Expected Behavior AnythingLLM should either: 1. Detect that `use_mlock` is invalid/supported and **remove it from the request payload** before sending it to Ollama. 2. Or, rely on Ollama's default behavior for memory management without forcing this specific flag via the API. ### Steps to Reproduce 1. Install AnythingLLM Docker version **1.11.1**. 2. Configure an Ollama instance as the LLM provider. 3. Attempt to select or load a model. 4. Check the Ollama server logs. 5. Observe the error: `invalid option provided option=use_mlock`. ### Suggested Fix Please review the code responsible for constructing the Ollama API request body in version 1.11.1 and **remove the `use_mlock` parameter** from the payload unless it is explicitly supported by the target Ollama version. Ollama should be allowed to handle memory locking internally if needed. ### Environment - **AnythingLLM Version:** 1.11.1 - **Ollama Version:** 0.17.8 - **OS:** macOS - **Connection:** localhost ### Additional Context This error prevents smooth integration. Removing the obsolete parameter should restore full functionality. ### Are there known steps to reproduce? _No response_
yindo added the possible bugneeds info / can't replicateinvestigating labels 2026-06-05 14:51:07 -04:00
yindo closed this issue 2026-06-05 14:51:07 -04:00
yindo commented 2026-06-05 14:51:07 -04:00
Author
Owner
Copy Link
Copy Source

@timothycarambat commented on GitHub (Mar 10, 2026):

Image Image

Is this true or a limitation of specific models/hardware? I do not get this issue with any downloaded models nor even createed models with this parameter defined in the Modelfile.

The ollama repo still shows use_mlock is a possible upstream parameter, even if it is ignored. Can i ask what model you are using to produce this issue? I wonder if it is a new model GGUF thing.

<!-- gh-comment-id:4032109359 --> @timothycarambat commented on GitHub (Mar 10, 2026): <img width="467" height="33" alt="Image" src="https://github.com/user-attachments/assets/db76f2b7-636c-4842-a125-33ac6016f1f8" /> <img width="1161" height="310" alt="Image" src="https://github.com/user-attachments/assets/9f9936cb-38e3-4cab-9cfe-ee7676d77589" /> Is this true or a limitation of specific models/hardware? I do not get this issue with any downloaded models nor even `create`ed models with this parameter defined in the Modelfile. The ollama repo still shows `use_mlock` is a possible upstream parameter, even if it is ignored. Can i ask what model you are using to produce this issue? I wonder if it is a new model GGUF thing.
yindo commented 2026-06-05 14:51:07 -04:00
Author
Owner
Copy Link
Copy Source

@raucodes commented on GitHub (Mar 10, 2026):

Just saw it in the ollama logs

==> /tmp/ollama-chat.err <==
time=2026-03-10T07:05:35.675+01:00 level=INFO source=device.go:272 msg="total memory" size="5.9 GiB"
time=2026-03-10T07:05:35.675+01:00 level=INFO source=sched.go:565 msg="loaded runners" count=3
time=2026-03-10T07:05:35.675+01:00 level=INFO source=server.go:1350 msg="waiting for llama runner to start responding"
time=2026-03-10T07:05:35.675+01:00 level=INFO source=server.go:1384 msg="waiting for server to become available" status="llm server loading model"
time=2026-03-10T07:05:36.428+01:00 level=INFO source=server.go:1388 msg="llama runner started in 0.98 seconds"
time=2026-03-10T07:50:33.801+01:00 level=WARN source=types.go:976 msg="invalid option provided" option=use_mlock
time=2026-03-10T08:04:42.439+01:00 level=WARN source=types.go:976 msg="invalid option provided" option=use_mlock
time=2026-03-10T08:05:00.203+01:00 level=WARN source=types.go:976 msg="invalid option provided" option=use_mlock
time=2026-03-10T08:08:52.034+01:00 level=WARN source=types.go:976 msg="invalid option provided" option=use_mlock
time=2026-03-10T08:12:32.854+01:00 level=WARN source=types.go:976 msg="invalid option provided" option=use_mlock

I using qwen3.5:122b-a10b-q4_K_M 8b9d11d807c5 81 GB 6 days ago for chat

and qwen3-embedding:4b-q4_K_M df5bd2e3c74c 2.5 GB 6 days ago

for embedding

<!-- gh-comment-id:4032547790 --> @raucodes commented on GitHub (Mar 10, 2026): Just saw it in the ollama logs ==> /tmp/ollama-chat.err <== time=2026-03-10T07:05:35.675+01:00 level=INFO source=device.go:272 msg="total memory" size="5.9 GiB" time=2026-03-10T07:05:35.675+01:00 level=INFO source=sched.go:565 msg="loaded runners" count=3 time=2026-03-10T07:05:35.675+01:00 level=INFO source=server.go:1350 msg="waiting for llama runner to start responding" time=2026-03-10T07:05:35.675+01:00 level=INFO source=server.go:1384 msg="waiting for server to become available" status="llm server loading model" time=2026-03-10T07:05:36.428+01:00 level=INFO source=server.go:1388 msg="llama runner started in 0.98 seconds" time=2026-03-10T07:50:33.801+01:00 level=WARN source=types.go:976 msg="invalid option provided" option=use_mlock time=2026-03-10T08:04:42.439+01:00 level=WARN source=types.go:976 msg="invalid option provided" option=use_mlock time=2026-03-10T08:05:00.203+01:00 level=WARN source=types.go:976 msg="invalid option provided" option=use_mlock time=2026-03-10T08:08:52.034+01:00 level=WARN source=types.go:976 msg="invalid option provided" option=use_mlock time=2026-03-10T08:12:32.854+01:00 level=WARN source=types.go:976 msg="invalid option provided" option=use_mlock I using qwen3.5:122b-a10b-q4_K_M 8b9d11d807c5 81 GB 6 days ago for chat and qwen3-embedding:4b-q4_K_M df5bd2e3c74c 2.5 GB 6 days ago for embedding
yindo commented 2026-06-05 14:51:08 -04:00
Author
Owner
Copy Link
Copy Source

@timothycarambat commented on GitHub (Mar 10, 2026):

Does this result in chat failures or simply a WARN in ollama logs? Will remove it anyway though since the docs seem to no longer allow it

<!-- gh-comment-id:4032647246 --> @timothycarambat commented on GitHub (Mar 10, 2026): Does this result in chat failures or simply a `WARN` in ollama logs? Will remove it anyway though since the docs seem to no longer allow it
yindo commented 2026-06-05 14:51:08 -04:00
Author
Owner
Copy Link
Copy Source

@raucodes commented on GitHub (Mar 10, 2026):

Maybe an small delay, just informed you nothing critical

<!-- gh-comment-id:4032702907 --> @raucodes commented on GitHub (Mar 10, 2026): Maybe an small delay, just informed you nothing critical
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Desktop
Docker
Integration Request
Integration Request
OS: Linux
OS: Mobile
OS: Windows
UI/UX
blocked
bug
bug
core-team-only
documentation
duplicate
embed-widget
enhancement
feature request
github_actions
good first issue
investigating
needs info / can't replicate
possible bug
pull-request
Mirrored from GitHub Pull Request
 question
stage: specifications
wontfix
No Label investigating needs info / can't replicate possible bug
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: Mintplex-Labs/anything-llm#4957
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?