[Bug]: 500 Internal Server Error in v0.30.4 due to non-ASCII Windows username path

[turtlechang]

What is the issue?

Bug Description
After updating to Ollama version 0.30.4 on Windows, running a model results in a 500 Internal Server Error. The llama-server process terminates because it fails to load the model.

The root cause appears to be an encoding or parsing issue with Windows user profiles that contain non-ASCII characters (e.g., Traditional Chinese) and spaces. My user directory is C:\Users\張 庭 綱, but the error logs show the path is mangled into garbled text (e.g., C:\Users\ix...), leading to a failure in locating the model blobs.

Environment Details

OS: Windows

Ollama Version: 0.30.4

Model: gemma4:e2b

Steps to Reproduce

Log into a Windows user account containing Chinese characters and spaces (e.g., 張 庭 綱).

Install or update Ollama to v0.30.4.

Open Command Prompt and run the command: ollama run gemma4:e2b --verbose

The server crashes and fails to read the path.

Relevant log output

C:\Users\張 庭 綱>ollama run gemma4:e2b --verbose
Error: 500 Internal Server Error: llama-server process has terminated: exit status 1: error: Failed to load CLIP model from C:\Users\ix\.ollama\models\blobs\sha256-4e30e2665218745ef463f722c0bf86be0cab6ee676320f1cfadf91e989107448
error loading model: llama_model_loader: failed to load model from C:\Users\ix\.ollama\models\blobs\sha256-4e30e2665218745ef463f722c0bf86be0cab6ee676320f1cfadf91e989107448

OS

Windows

GPU

Nvidia

CPU

Intel

Ollama version

0.30.4

[turtlechang]

[rick-github]

Full server log will aid in debugging.

[turtlechang]

[danieljose]

This looks like a Windows argv encoding issue in the bundled llama-server, rather than the Go-side Ollama launcher.

Ollama appears to pass the model/projector paths as separate argv entries to llama-server (--model, --mmproj, etc.), so Go should be using the Windows wide-character process APIs correctly when spawning the subprocess. However, the pinned llama.cpp llama-server currently enters through a regular main(int argc, char **argv). On Windows, that can cause non-ASCII command-line arguments to be converted through the active ANSI code page before llama.cpp sees them.

That would explain why a path like:

C:\Users\張 庭 綱\.ollama\models\blobs\...

shows up inside the llama-server error as a corrupted/truncated path like:

C:\Users\ix\.ollama\models\blobs\...

The more correct fix is probably in llama.cpp: on Windows, llama-server should read wide argv via wmain(...) or GetCommandLineW + CommandLineToArgvW, then convert each argument to UTF-8 with WideCharToMultiByte(CP_UTF8, ...) before passing them into the existing argument parser.

Ollama could also carry this as a temporary compatibility patch in its llama.cpp build integration until it lands upstream.

A workaround for affected users is to set OLLAMA_MODELS to an ASCII-only path, for example:

setx OLLAMA_MODELS C:\ollama-models

Then restart Ollama and pull the model again.

[YonTracks]

did this issue get solved?

I am curious, when testing this issue, is ollama running? (taskbar icon showing and the app ui working) before using the cmd/terminal, how did you first start ollama? why don't I see the OLLAMA_LIBRARY_PATH in the log pic? server.log is better than the image / screenshot, logs can be found using that taskbar icon or explorer %LOCALAPPDATA%\Ollama

please try using the windows start menu to first start ollama (if the taskbar icon is already running, quit via the icon and then start ollama via the windows start menu), then try the cmd prompt?

good luck.

[rick-github]

Seems to be Windows specific, works fine in Linux.

llama_model_loader: loaded meta data with 55 key-value pairs and 601 tensors from /tmp/張 庭 綱/blobs/sha256-4e30e2665218745ef463f722c0bf86be0cab6ee676320f1cfadf91e989107448 (version GGUF V3 (latest))

[turtlechang]

@YonTracks Still trying to solve😭😭😭

[turtlechang]

@danieljose I tried your method, but Ollama still downloads to "C:\Users\張庭綱.ollama\models"😭😭😭

[YonTracks]

sorry about that, this one is hard, beyond me but! as @danieljose mentioned that should work as a workaround.

A temporary workaround for affected users is to move Ollama’s model directory to an ASCII-only path, e.g. set OLLAMA_MODELS=C:\<models here>, fully restart Ollama, then re-pull or copy the models there. (model location can be set in the app ui)

until ollama fixes the issue.

I think this is a Windows Unicode path handling issue in the native llama-server / mtmd CLIP loader path, not a model-specific or account/auth issue.

The Go side appears able to preserve the path, but after the path is passed into llama-server as --model / --mmproj, Windows narrow argv / narrow file opens can corrupt non-ASCII profile paths such as:

C:\Users\張 庭 綱.ollama\models...

That matches the report where the path later appears mangled as C:\Users\ix... and the CLIP/mmproj load fails.

A local patch that fixes this did three things:

1. On Windows, reconstruct llama-server argv from GetCommandLineW() / CommandLineToArgvW() and convert to UTF-8.
2. Open the CLIP/mmproj file using a Windows wide filesystem path instead of std::ifstream(char*).
3. Use ggml_fopen for Ollama compat tensor reads, since ggml already handles UTF-8 paths on Windows.

Commit here: (YonTracks@f07de70)

[BioKobena]

I have the same issue on my mac computer

[Eric-Poirier]

Replacing accentuated letters (french here) and underscore in models path worked for me (Win11).