Ollama 0.1.32 not working as expected in Windows.

[BCoskun]

What is the issue?

I can't no longer serve the ollama using regular user. When I try to run "olllama server" command and use it from another terminal windows, I am getting Error about the runner.

time=2024-04-19T15:16:31.832-04:00 level=ERROR source=routes.go:120 msg="error loading llama server" error="llama runner process no longer running: 3221225781 "

When I try with "run as administrator" option then it works okay.

OS

Windows

GPU

Nvidia

CPU

AMD

Ollama version

0.1.32

[dhiltgen]

Can you share your server log when it's not running as administrator and fails? If the server log is empty for some reason, can you try to run it in a non-admin powershell terminal manually and share what errors it reports?

[new-divos]

I have the same problem. server.log

[Yash-Garg]

Same issue happening for me on Windows 11, Ollama version is v0.1.32.

❯ ollama run llama3:8b
Error: llama runner process no longer running: 3221225781

[dhiltgen]

Sorry you're hitting this bug. Unfortunately it doesn't show any obvious glitch with the normal log level.

Could someone who's seeing this try running manually with debug logging? Quit the tray app, then in a powershell terminal

$env:OLLAMA_DEBUG="1"
ollama serve  2>&1 | % ToString | Tee-Object server.log

Then in another windows try something like ollama run llama3 hello to get it to fail, and share that server.log

[michael1maass]

well, for some reason the current version tries to spawn to a User folder and run an exe there which, in my case is not allowed by gpo. Used to work in a former Version, which leaves me somehow clueless on how to work around this. _

level=ERROR source=server.go:285 msg="unable to load any llama server" error="error starting the external llama server: fork/exec C:\Users\anyUserName\AppData\Local\Temp\ollama1312655508\runners\cpu_avx2\ollama_llama_server.exe: Dieses Programm wurde durch eine Gruppenrichtlinie geblockt. Wenden Sie sich an den Systemadministrator, um weitere Informationen zu erhalten. " (aka: this Program was blocked by a gpo. contact your Sys-Admin for further Information. _

Since for obvious reasons a user can not be allowed to run any executables that have not been installed into c:\Program Files The errormessage makes sense.

This only is called on Post, not on get requests

(PS.: Since the install Procedure does install into the user Context, which prevents ollama from running as described above, I fidged the Programm folder and the respective Reg Entry to work from c:\Program Files\Ollama, which worked allright until the late 0.1.32 update)

Can anybody confirm my observations?

[dhiltgen]

well, for some reason the current version tries to spawn to a User folder and run an exe there which, in my case is not allowed by gpo. Used to work in a former Version, which leaves me somehow clueless on how to work around this.

In version 0.1.32 we switched from using a dll to running a standalone executable, and that executable is carried as a payload in the binary and extracted at runtime. It sounds like this might be tricky for your GPO. We do have a mechanism to change where it extracts to by setting OLLAMA_TMPDIR to a location that you can write to, and which can run executables.

If that can't work, we'll have to revisit how we carry the payloads on windows and bubble them up to the installer itself instead of carrying them as payloads.

[aliuq]

same issue

[michael1maass]

Thanks for the explanation. I really do appreciate that. Having said that… „…to a location that you can write to, and which can run executables…“ is exactly the combination we do not want to see 🥸… you can either write in it or execute from it. A combination of the two would open floodgates to any ever so simple warez that makes its way through?!

Since I was so excited to have lifted the Ollama UI secret the same morning, a reinstall with the current version swiftly got me back to reality….😆

I suppose there was a good reason for this architectural decision… but please, please roll it back 🙏🙏

Michael Maaß

Am 23.04.2024 um 18:13 schrieb Daniel Hiltgen @.***>:

where it extracts to by setting OLLAMA_TMPDIR to a location that you can write to, and which can run executables.

[new-divos]

well, for some reason the current version tries to spawn to a User folder and run an exe there which, in my case is not allowed by gpo. Used to work in a former Version, which leaves me somehow clueless on how to work around this.

In version 0.1.32 we switched from using a dll to running a standalone executable, and that executable is carried as a payload in the binary and extracted at runtime. It sounds like this might be tricky for your GPO. We do have a mechanism to change where it extracts to by setting OLLAMA_TMPDIR to a location that you can write to, and which can run executables.

If that can't work, we'll have to revisit how we carry the payloads on windows and bubble them up to the installer itself instead of carrying them as payloads.

It does not work for me