LightRAG Upload Fails with "NanoVectorDBStorage[entities] index flush failed: 404 page not found"

[MrMiningIR]

Hi everyone,

When uploading a .docx file in LightRAG, parsing and analysis complete successfully, but the process fails during the entity index flush stage.

Track ID: upload_20260628_195715_3a104b15

analyzing_end_time: 6/28/2026, 12:57:15 PM
analyzing_start_time: 6/28/2026, 12:57:15 PM
chunk_method: paragraph_semantic
chunk_opts: size=2000, overlap=100
parse_end_time: 6/28/2026, 12:57:15 PM
parse_engine: native
parse_format: lightrag
parse_start_time: 6/28/2026, 12:57:15 PM
process_end_time: 6/28/2026, 1:02:55 PM
process_options: teP
process_start_time: 6/28/2026, 12:57:15 PM
source_file: رشته HIT.docx

Error Message:
NanoVectorDBStorage[entities] index flush failed: 404 page not found
(status code: 404)

############################
### Data storage selection
############################
### Default storage: JSON/Nano/NetworkX (Recommended for test deployment)
LIGHTRAG_KV_STORAGE=JsonKVStorage
LIGHTRAG_DOC_STATUS_STORAGE=JsonDocStatusStorage
LIGHTRAG_GRAPH_STORAGE=NetworkXStorage
LIGHTRAG_VECTOR_STORAGE=NanoVectorDBStorage

This suggests the document is parsed and processed correctly, but LightRAG fails when flushing the entities index to the configured vector storage backend. The error looks like an incorrect vector DB endpoint, an unsupported API path, or a backend configuration mismatch.

[danielaskdd]

A 404 error during vector db index flush typically indicates an issue with accessing the embedded model, which can be diagnosed by reviewing backend logs. This error is usually caused by an incorrect model URL—for example, the URL may require the inclusion or removal of the 'v1' path, such as https://api.openai.com/v1 or https://api.myapi.com.

[MrMiningIR]

Thanks for the suggestion.

Since I’m running LightRAG with Docker Compose, could you clarify exactly where this model/vector endpoint configuration should be adjusted?

#LLM Request Timeout Setting (applies to all LLMs; 0 means no timeout for Ollama)
#LLM_TIMEOUT=240
LLM_BINDING=ollama
LLM_BINDING_HOST=host.docker.internal:12434
LLM_BINDING_API_KEY=your_api_key
LLM_MODEL=deepseek-r1-distill-llama:latest

#EMBEDDING_TIMEOUT=30
#OpenAI-compatible embedding settings
EMBEDDING_BINDING=ollama
EMBEDDING_BINDING_HOST=host.docker.internal:12434
EMBEDDING_BINDING_API_KEY=your_api_key
EMBEDDING_MODEL=qwen3-embedding-vllm:latest
EMBEDDING_DIM=3072
EMBEDDING_TOKEN_LIMIT=8192
EMBEDDING_SEND_DIM=false
EMBEDDING_USE_BASE64=true

My environment
Windows 10
Kali Linux
Docker Desktop installed
Running the project with docker-compose up

[danielaskdd]

Kindly provide the backend server logs for further analysis.

Ollama's default port is 11434. Pls make sure 12434 is the correct one.

[MrMiningIR]

Hello,

As requested, I have provided the following three files for analysis:

Log File: Contains the backend server logs.
.env File: Includes my environment variable configurations.
Docker Model Runner Port File: Details of my Docker mapping and port settings.
Regarding the port number: I noticed your comment about the default port being 11434. However, in my current configuration, I am using port 12434. Please check if this discrepancy is causing the connection issues or if there are internal mapping errors within the Docker container.

Could you please review these files and let me know how to resolve the connection error?

Thank you for your assistance.

Log.txt

env.txt

[danielaskdd]

Thanks for the backend log — it makes the root cause clear. This is a configuration issue, not a bug in NanoVectorDBStorage. The NanoVectorDBStorage[entities] index flush failed error is only a downstream symptom: the flush has to embed the vectors, and the embedding call itself is returning 404 page not found.

Root cause

You're pointing the Ollama binding at Docker Model Runner (DMR), but DMR is not Ollama. DMR only exposes an OpenAI-compatible API; it does not implement Ollama's native endpoints.

From your config:

EMBEDDING_BINDING=ollama
EMBEDDING_BINDING_HOST=host.docker.internal:12434

• Port 12434 is Docker Model Runner's default port (Ollama's native default is 11434).
• With EMBEDDING_BINDING=ollama, LightRAG uses the Ollama client, which sends POST /api/embed.
• DMR has no /api/embed route, so it returns Go's default 404 page not found (plain-text "route not found", not a JSON model not found). That's exactly the 404 in your log.

Why extraction "worked" but embedding failed

This is misleading — the LLM binding is misconfigured the same way. Your run was a rebuild/resume, and entity extraction was served from llm_response_cache (the log loads llm_response_cache with 4 records), so no live LLM request was made. Embeddings can't be cached, so the embedding call is the first one to actually hit DMR and expose the 404. Once the LLM cache misses, LLM_BINDING=ollama on port 12434 will 404 too.

Fix

Configure DMR as an OpenAI-compatible endpoint, not Ollama:

# Embedding
EMBEDDING_BINDING=openai
EMBEDDING_BINDING_HOST=http://host.docker.internal:12434/engines/v1
EMBEDDING_BINDING_API_KEY=anything          # DMR ignores it, but it can't be empty
EMBEDDING_MODEL=ai/nomic-embed-text          # use DMR's actual model name

# LLM (same fix)
LLM_BINDING=openai
LLM_BINDING_HOST=http://host.docker.internal:12434/engines/v1
LLM_BINDING_API_KEY=anything
LLM_MODEL=ai/llama3.2

Notes:

• The host must end with /engines/v1; the OpenAI client appends /embeddings and /chat/completions itself.
• Use the model names as they appear in DMR (usually with the ai/ namespace). Confirm with curl http://localhost:12434/engines/v1/models.

One more thing (not the 404, but it'll bite you next)

EMBEDDING_DIM=3072 is wrong for nomic-embed-text-v1.5 — that model outputs 768 dimensions. After fixing the binding, set the correct EMBEDDING_DIM. Since embedding settings must not change after the first document is processed, clear your rag_storage and re-ingest.

Alternatively, if you'd rather keep the ollama binding, run a real Ollama server on port 11434 and point at that instead of DMR.

[MrMiningIR]

thanks for your help