By MV2 of Munim, Inc., with AI agents. Checked on 5 November 2026 against Ollama's source at release v0.40.14 (3 November 2026). For your own machines only.
Short answer: ollama -v prints two different versions. The ollama command you typed is a client. It asks the Ollama server at OLLAMA_HOST (by default 127.0.0.1:11434) for its version. ollama version is … is the server's answer. Warning: client version is … is the version of the command you just ran. The command prints that second line only when the two versions differ. The server is the program that listens on the network and runs your models. Security advisories are about the server, so the ollama version is line is the one that counts.
| You see | What happened | Go to |
|---|---|---|
ollama version is 0.40.14 | A server answered, and it is the same version as the command. All good. | - |
Warning: could not connect to a running Ollama instance Warning: client version is 0.40.14 | No server answered at OLLAMA_HOST. Nothing is wrong with the install. The second line only appears because there was no server version to compare with. | 1 |
ollama version is 0.39.2 Warning: client version is 0.40.14 | A server answered, but it is a different Ollama from the command you typed: an older server still running after an upgrade, a second install, a container or another machine. | 2 |
Warning: client version is 0.0.0(with or without other lines) | This ollama binary was built without a version number. That usually means a build from source. | 3 |
The version numbers above are examples. You can ask the server yourself, without the client: curl http://127.0.0.1:11434/api/version returns, for example, {"version":"0.40.14"}.
Nothing answered at OLLAMA_HOST. curl http://127.0.0.1:11434 prints Ollama is running when a server is up.
systemctl status ollama, then sudo systemctl start ollama. Read journalctl -u ollama -n 50 --no-pager if it doesn't stay up. More causes, including WSL without systemd and Docker, are on could not connect to ollama server.OLLAMA_HOST: check it with echo $OLLAMA_HOST (PowerShell: $env:OLLAMA_HOST). The command asks the server at exactly that address. A stale value pointing at a machine that is off gives this warning too.Two different Ollamas are involved. Find out which one is the server, because that is the one advisories apply to. If you upgraded and the ollama version is line still shows the old number, the old server is still the one running. Whatever the upgrade fixed is not fixed yet on this machine. Check that number against Ollama's published advisories or the CVE checker.
sudo systemctl restart ollama, then ollama -v again. systemctl cat ollama shows which binary the service starts (the ExecStart= line). If which -a ollama lists a different path first, you have two copies; keep the one the service uses.List every ollama on your PATH. The first one listed is the one you ran:
which -a ollama # Linux, macOS, WSL where.exe ollama # Windows
A package-manager copy next to the official app or install script is a common cause. Remove the copy you don't use, so that the command and the server come from the same install and upgrade together.
The server's version is the image's. Check it inside the container with docker exec -it ollama ollama -v. To upgrade it, pull the new image and recreate the container. A plain docker restart keeps the old image. When you recreate it, publish the port to localhost only, -p 127.0.0.1:11434:11434 (why).
If OLLAMA_HOST points at another computer, the ollama version is line is that computer's Ollama. Upgrading your own client changes nothing there. Upgrade the server where it runs.
In Ollama's source the version is the placeholder 0.0.0 (version/version.go). Official releases fill in the real number when they are built. A binary that reports 0.0.0 was built without it, usually from source. That's harmless in itself, but you can't tell from the number which advisories apply. Use an official release or record which commit you built from. If a server reports 0.0.0, the CVE checker can't tell which fixes it has either.
Don't "fix" the connection warning with OLLAMA_HOST=0.0.0.0 on the server. It doesn't make the command find a missing server. It opens Ollama's API, which has no login, to every network the machine is on. For access from other devices, see Use Ollama remotely.
In Ollama v0.40.14, -v/--version is a flag on the root command, which then calls versionHandler in cmd/cmd.go. versionHandler builds a client with api.ClientFromEnvironment(), which uses OLLAMA_HOST (api/client.go; the default, 127.0.0.1:11434, is in envconfig/config.go). It then asks the server for GET /api/version, which the server answers with its own build version (server/routes.go). If that request fails, it prints Warning: could not connect to a running Ollama instance. If a version came back, it prints ollama version is and that version. Finally, if the server's version (empty when nothing answered) differs from the client's own, it prints Warning: client version is and the client's version.
The free local-ai-checkup script flags AI ports that other machines can reach, and checks your Ollama version, OLLAMA_ORIGINS and Docker port bindings. It's read-only and sends nothing off the machine.
MV2 of Munim, Inc. does a $49 local AI health check for one machine, or a $199 small-office check for up to 5 machines or one shared Ollama or Open WebUI server. You get a written report of what's exposed, risky or slow and what to fix first, with exact commands for your OS. See a sample report. Pay $49 or pay $199 on Stripe, then email mv2@munimtech.com the output of python3 local_ai_checkup.py --json, your OS, and what you use it for. MV2 never asks for passwords, keys or remote access.