[GH-ISSUE #10803] problems in install_ollama.sh : deriving from other problem: ~/.bashrc export OLLAMA_MODELS="/path/to/storage" should be respected #53608

Closed
opened 2026-04-29 04:11:39 -05:00 by GiteaMirror · 3 comments
Owner

Originally created by @xvdp on GitHub (May 21, 2025).
Original GitHub issue: https://github.com/ollama/ollama/issues/10803

What is the issue?

I see a couple problems with theinstall_ollama.sh,which I noticed trying to redirect the model storage.

  1. Problem. I first noticed that adding export OLLAMA_MODELS="/path/to/models" to ~/.bashrc , like for other projects in this area, e.g. $HUGGINGFACE_HOME, $TORCH_HOME , etc. did not change the default storage.
    Looking at your code, it appears it should work as config.go looks for models in go.Getenv("OLLAMA_MODELS") (via Models() and Var() )

However ollama ignores my ~/.bashrc, instead storing models to /usr/share/ollama/.models.

  1. Patch ? . if config.go looks for getEnv(), there has to be a place to set those envs.
  • I rsync'd the model folder and models keeping ollama as owner to a /path/to/models
    • suggestion of the README, sudo systemctl edit ollama and adding Environment="OLLAMA_MODELS=/path/to/models" changes nothing, even after reboot.
  • directly adding a second line Environment line to /etc/systemd/system/ollama.service. works, but only after rebooting, reloading daemon and restarting service is not sufficient.
sudo nano /etc/systemd/system/ollama.service
# after the line
   Environment="PATH= ..." leave this line untouched
# add line
   Environment="OLLAMA_MODELS=/path/to/models"

1.a. Partial solution. Document it and specify if folders need to be carefully moved maintaining ownership or they get created automatically.

1.b. Better solution, add option in install_ollama.sh to set storage in service
Service should however listen to ~/.bashrc. Can the daemon not run under the current user instead of a new one?

  1. Problem install_ollama.sh. The installer contradicts the README.md - While the latter says that installing as a service is recommended, The installer, simply checks available() { command -v $1 >/dev/null; } on systemtcl,; not user choice. **Solution: add service as user option to the installer and add a notice in the option query, about the storage locations"

  2. Possible problem on re-install. Seems to me that you set the install folder to be
    line 72 OLLAMA_INSTALL_DIR=$(dirname ${BINDIR}) and later use that as install location, 97 $SUDO tar -xzf - -C "$OLLAMA_INSTALL_DIR" but you delete 76 $SUDO rm -rf "$OLLAMA_INSTALL_DIR/lib/ollama".

My install does not have the /lib/ on;ly "$OLLAMA_INSTALL_DIR/ollama"

Ideally this installer would not create a new user. If it must, it would be great that on install that all changes done to the machine are logged and kept to build an uninstaller that removes everything cleanly and completely; folders, users, groups, compiled code.

Relevant log output


OS

Linux

GPU

Nvidia

CPU

AMD

Ollama version

0.6.5

Originally created by @xvdp on GitHub (May 21, 2025). Original GitHub issue: https://github.com/ollama/ollama/issues/10803 ### What is the issue? I see a couple problems with the`install_ollama.sh`,which I noticed trying to redirect the model storage. 1. Problem. I first noticed that adding `export OLLAMA_MODELS="/path/to/models"` to `~/.bashrc` , like for other projects in this area, e.g. $HUGGINGFACE_HOME, $TORCH_HOME , etc. did not change the default storage. Looking at your code, it appears it should work as `config.go` looks for models in `go.Getenv("OLLAMA_MODELS")` (via `Models()` and `Var()` ) However ollama ignores my `~/.bashrc`, instead storing models to `/usr/share/ollama/.models`. 1. **Patch ? . if `config.go` looks for `getEnv()`, there has to be a place to set those envs.** * I rsync'd the model folder and models keeping `ollama` as owner to a `/path/to/models` * suggestion of the README, `sudo systemctl edit ollama` and adding `Environment="OLLAMA_MODELS=/path/to/models"` changes nothing, even after reboot. * directly adding a second line Environment line to `/etc/systemd/system/ollama.service`. works, but only after rebooting, reloading daemon and restarting service is not sufficient. ```bash sudo nano /etc/systemd/system/ollama.service # after the line Environment="PATH= ..." leave this line untouched # add line Environment="OLLAMA_MODELS=/path/to/models" ``` 1.a. **Partial solution. Document it** and specify if folders need to be carefully moved maintaining ownership or they get created automatically. 1.b. **Better solution, add option in install_ollama.sh to set storage in service** Service should however listen to `~/.bashrc`. Can the daemon not run under the current user instead of a new one? 2. Problem `install_ollama.sh`. The installer contradicts the README.md - While the latter says that installing as a service is recommended, The installer, simply checks available() { command -v $1 >/dev/null; } on systemtcl,; not user choice. **Solution: add service as user option to the installer and add a notice in the option query, about the storage locations" 3. Possible problem on re-install. Seems to me that you set the install folder to be line 72 `OLLAMA_INSTALL_DIR=$(dirname ${BINDIR})` and later use that as install location, 97 `$SUDO tar -xzf - -C "$OLLAMA_INSTALL_DIR"` but you delete 76 `$SUDO rm -rf "$OLLAMA_INSTALL_DIR/lib/ollama"`. My install does not have the **`/lib/`** on;ly `"$OLLAMA_INSTALL_DIR/ollama"` Ideally this installer would not create a new user. If it must, it would be great that on install that all changes done to the machine are logged and kept to build an uninstaller that removes everything cleanly and completely; folders, users, groups, compiled code. ### Relevant log output ```shell ``` ### OS Linux ### GPU Nvidia ### CPU AMD ### Ollama version 0.6.5
GiteaMirror added the bug label 2026-04-29 04:11:40 -05:00
Author
Owner

@rick-github commented on GitHub (May 21, 2025):

When running as you, ollama will use OLLAMA_MODELS as set in in your .bashrc. That is, if you run ollama serve on the command line, ollama will use /path/to/models if OLLAMA_MODELS is set, otherwise the default of $HOME/.ollama/models, ie ~/.ollama/models.

When running as a service, ollama will use OLLAMA_MODELS as configured in the service file. That is, if you run sudo systemctl start ollama, ollama will use the value of OLLAMA_MODELS in /etc/systemd/system/ollama.service.d/override.conf, otherwise the default of $HOME/.ollama/models, ie /usr/share/ollama/.ollama/models.

In the service file, you have to properly format the Environment line. Enclosing the values in quotes causes systemd to treat it as a single value. That is:

Environment="PATH=/some/path OLLAMA_MODELS=/modelpath"

results in the variable PATH having the value /some/path OLLAMA_MODELS=/modelpath. So you need to do either of the following

Environment=PATH=/some/path OLLAMA_MODELS=/modelpath

or

Environment="PATH=/some/path"
Environment="OLLAMA_MODELS=/modelpath"
<!-- gh-comment-id:2898620874 --> @rick-github commented on GitHub (May 21, 2025): When running as you, ollama will use `OLLAMA_MODELS` as set in in your .bashrc. That is, if you run `ollama serve` on the command line, ollama will use `/path/to/models` if `OLLAMA_MODELS` is set, otherwise the default of `$HOME/.ollama/models`, ie `~/.ollama/models`. When running as a service, ollama will use `OLLAMA_MODELS` as configured in the service file. That is, if you run `sudo systemctl start ollama`, ollama will use the value of `OLLAMA_MODELS` in `/etc/systemd/system/ollama.service.d/override.conf`, otherwise the default of $HOME/.ollama/models, ie `/usr/share/ollama/.ollama/models`. In the service file, you have to properly format the `Environment` line. Enclosing the values in quotes causes systemd to treat it as a single value. That is: ``` Environment="PATH=/some/path OLLAMA_MODELS=/modelpath" ``` results in the variable `PATH` having the value `/some/path OLLAMA_MODELS=/modelpath`. So you need to do either of the following ``` Environment=PATH=/some/path OLLAMA_MODELS=/modelpath ``` or ``` Environment="PATH=/some/path" Environment="OLLAMA_MODELS=/modelpath" ```
Author
Owner

@xvdp commented on GitHub (May 22, 2025):

@rick-github thanks.
ok the behaviour itself may not be a bug, but until you understand services and their syntax, model storage management can be a pain. so the installer and instructions could be friendlier.

On the reinstall however, unless im wrong, there is a bug on the linux installer on account of the /lib/ in $SUDO rm -rf "$OLLAMA_INSTALL_DIR/lib/ollama".

<!-- gh-comment-id:2900679483 --> @xvdp commented on GitHub (May 22, 2025): @rick-github thanks. ok the behaviour itself may not be a bug, but until you understand services and their syntax, model storage management can be a pain. so the installer and instructions could be friendlier. On the reinstall however, unless im wrong, there is a bug on the linux installer on account of the /lib/ in $SUDO rm -rf "$OLLAMA_INSTALL_DIR/lib/ollama".
Author
Owner

@rick-github commented on GitHub (May 22, 2025):

The tar file contains these files:

bin/ollama
lib/ollama/cuda_v11/
lib/ollama/cuda_v11/libcublas.so.11.5.1.109
lib/ollama/cuda_v11/libcudart.so.11.0
lib/ollama/cuda_v11/libcublas.so.11
lib/ollama/cuda_v11/libggml-cuda.so
lib/ollama/cuda_v11/libcublasLt.so.11.5.1.109
lib/ollama/cuda_v11/libcudart.so.11.3.109
lib/ollama/cuda_v11/libcublasLt.so.11
lib/ollama/cuda_v12/
lib/ollama/cuda_v12/libcublasLt.so.12.8.4.1
lib/ollama/cuda_v12/libcublasLt.so.12
lib/ollama/cuda_v12/libggml-cuda.so
lib/ollama/cuda_v12/libcublas.so.12.8.4.1
lib/ollama/cuda_v12/libcudart.so.12.8.90
lib/ollama/cuda_v12/libcublas.so.12
lib/ollama/cuda_v12/libcudart.so.12
lib/ollama/libggml-base.so
lib/ollama/libggml-cpu-alderlake.so
lib/ollama/libggml-cpu-haswell.so
lib/ollama/libggml-cpu-icelake.so
lib/ollama/libggml-cpu-sandybridge.so
lib/ollama/libggml-cpu-skylakex.so
lib/ollama/libggml-cpu-sse42.so
lib/ollama/libggml-cpu-x64.so

The -C option to the tar command sets the base directory for extracting these files, so $SUDO rm -rf "$OLLAMA_INSTALL_DIR/lib/ollama" to remove the ollama library files is correct. If your install has $OLLAMA_INSTALL_DIR/ollama then it predates v0.3.7, which is when the layout changed. It could be that it's an old installation and that your current v0.6.5 installation has the files in a different place.

<!-- gh-comment-id:2900941891 --> @rick-github commented on GitHub (May 22, 2025): The tar file contains these files: ``` bin/ollama lib/ollama/cuda_v11/ lib/ollama/cuda_v11/libcublas.so.11.5.1.109 lib/ollama/cuda_v11/libcudart.so.11.0 lib/ollama/cuda_v11/libcublas.so.11 lib/ollama/cuda_v11/libggml-cuda.so lib/ollama/cuda_v11/libcublasLt.so.11.5.1.109 lib/ollama/cuda_v11/libcudart.so.11.3.109 lib/ollama/cuda_v11/libcublasLt.so.11 lib/ollama/cuda_v12/ lib/ollama/cuda_v12/libcublasLt.so.12.8.4.1 lib/ollama/cuda_v12/libcublasLt.so.12 lib/ollama/cuda_v12/libggml-cuda.so lib/ollama/cuda_v12/libcublas.so.12.8.4.1 lib/ollama/cuda_v12/libcudart.so.12.8.90 lib/ollama/cuda_v12/libcublas.so.12 lib/ollama/cuda_v12/libcudart.so.12 lib/ollama/libggml-base.so lib/ollama/libggml-cpu-alderlake.so lib/ollama/libggml-cpu-haswell.so lib/ollama/libggml-cpu-icelake.so lib/ollama/libggml-cpu-sandybridge.so lib/ollama/libggml-cpu-skylakex.so lib/ollama/libggml-cpu-sse42.so lib/ollama/libggml-cpu-x64.so ``` The `-C` option to the `tar` command sets the base directory for extracting these files, so `$SUDO rm -rf "$OLLAMA_INSTALL_DIR/lib/ollama"` to remove the ollama library files is correct. If your install has $OLLAMA_INSTALL_DIR/ollama then it predates v0.3.7, which is when the layout changed. It could be that it's an old installation and that your current v0.6.5 installation has the files in a different place.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/ollama#53608