github-starred/ollama
2
0
Fork 0
mirror of https://github.com/ollama/ollama.git synced 2026-05-06 16:11:34 -05:00
Code Issues 14.5k Packages Projects Releases 120 Wiki Activity

[GH-ISSUE #4732] Unable to Change Ollama Models Directory on Linux (Rocky 9) #49495

New Issue
Closed
opened 2026-04-28 12:03:50 -05:00 by GiteaMirror · 25 comments
GiteaMirror commented 2026-04-28 12:03:50 -05:00
Owner
Copy Link

Originally created by @pykeras on GitHub (May 30, 2024).
Original GitHub issue: https://github.com/ollama/ollama/issues/4732

What is the issue?

I am following every instruction on the documentation and any other suggestions from previous issues. However, I am unable to change the Ollama models directory to another directory on RockyLinux 9. I have more than 100GB of models that I don't want to download again.

Steps to Reproduce:

  1. Execute sudo systemctl edit ollama.service
  2. Add the following: 
    [Service]
Environment="OLLAMA_MODELS=/home/myuser/.ollama/models"
  3. Save and run sudo systemctl daemon-reload
  4. Execute sudo systemctl restart ollama.service

Expected Behavior:
The Ollama service should start properly with the models directory set to /home/myuser/.ollama/models.

Actual Behavior:
The service doesn't start properly. Here are the logs from running sudo journalctl -u ollama.service | tail:

May 31 01:44:36 myuserPC ollama[354959]: Error: mkdir /home/myuser/.ollama: permission denied
May 31 01:44:36 myuserPC systemd[1]: ollama.service: Main process exited, code=exited, status=1/FAILURE
May 31 01:44:36 myuserPC systemd[1]: ollama.service: Failed with result 'exit-code'.
May 31 01:44:39 myuserPC systemd[1]: ollama.service: Scheduled restart job, restart counter is at 3.
May 31 01:44:39 myuserPC systemd[1]: Stopped Ollama Service.
May 31 01:44:39 myuserPC systemd[1]: Started Ollama Service.
May 31 01:44:39 myuserPC ollama[355046]: 2024/05/31 01:44:39 routes.go:1028: INFO server config env="map[OLLAMA_DEBUG:false OLLAMA_FLASH_ATTENTION:false OLLAMA_HOST: OLLAMA_KEEP_ALIVE: OLLAMA_LLM_LIBRARY: OLLAMA_MAX_LOADED_MODELS:1 OLLAMA_MAX_QUEUE:512 OLLAMA_MAX_VRAM:0 OLLAMA_MODELS: OLLAMA_NOHISTORY:false OLLAMA_NOPRUNE:false OLLAMA_NUM_PARALLEL:1 OLLAMA_ORIGINS:[http://localhost https://localhost http://localhost:* https://localhost:* http://127.0.0.1 https://127.0.0.1 http://127.0.0.1:* https://127.0.0.1:* http://0.0.0.0 https://0.0.0.0 http://0.0.0.0:* https://0.0.0.0:*] OLLAMA_RUNNERS_DIR: OLLAMA_TMPDIR:]"
May 31 01:44:39 myuserPC ollama[355046]: Error: mkdir /home/myuser/.ollama: permission denied
May 31 01:44:39 myuserPC systemd[1]: ollama.service: Main process exited, code=exited, status=1/FAILURE
May 31 01:44:39 myuserPC systemd[1]: ollama.service: Failed with result 'exit-code'.

As you can see, Ollama tries to create the .ollama directory in the user's home directory, regardless of whether the directory exists or not.

Additional Information:

  • I have tried different permissions and ownerships, including an exact file-by-file copy of permissions and ownership from /usr/share/ollama.
  • Running /usr/local/bin/ollama serve does not show any error, unlike sudo systemctl restart ollama.

Other Methods Attempted:

  1. Symlink Attempt: I tried using ln -s to map models from the default directory to a new location at /home/myuser/.ollama/models/ with correct permissions and ownership. This resulted in a "mkdir failed" error, as the models directory already exists.
  2. Editing Service Environment: Editing the Service Environment using sudo systemctl edit ollama.service is problematic. If an error occurs, the added lines cannot be removed easily, requiring the removal of the override file using sudo rm -rf /etc/systemd/system/ollama.service.d/override.conf.

I would appreciate any help or guidance on how to resolve this issue.

OS

Linux

GPU

Nvidia

CPU

Intel

Ollama version

0.1.39

Originally created by @pykeras on GitHub (May 30, 2024). Original GitHub issue: https://github.com/ollama/ollama/issues/4732 ### What is the issue? I am following every instruction on the documentation and any other suggestions from previous issues. However, I am unable to change the Ollama models directory to another directory on RockyLinux 9. I have more than 100GB of models that I don't want to download again. **Steps to Reproduce**: 1. Execute `sudo systemctl edit ollama.service` 2. Add the following: ```bash [Service] Environment="OLLAMA_MODELS=/home/myuser/.ollama/models" ``` 3. Save and run `sudo systemctl daemon-reload` 4. Execute `sudo systemctl restart ollama.service` **Expected Behavior**: The Ollama service should start properly with the models directory set to `/home/myuser/.ollama/models`. **Actual Behavior**: The service doesn't start properly. Here are the logs from running `sudo journalctl -u ollama.service | tail`: ``` May 31 01:44:36 myuserPC ollama[354959]: Error: mkdir /home/myuser/.ollama: permission denied May 31 01:44:36 myuserPC systemd[1]: ollama.service: Main process exited, code=exited, status=1/FAILURE May 31 01:44:36 myuserPC systemd[1]: ollama.service: Failed with result 'exit-code'. May 31 01:44:39 myuserPC systemd[1]: ollama.service: Scheduled restart job, restart counter is at 3. May 31 01:44:39 myuserPC systemd[1]: Stopped Ollama Service. May 31 01:44:39 myuserPC systemd[1]: Started Ollama Service. May 31 01:44:39 myuserPC ollama[355046]: 2024/05/31 01:44:39 routes.go:1028: INFO server config env="map[OLLAMA_DEBUG:false OLLAMA_FLASH_ATTENTION:false OLLAMA_HOST: OLLAMA_KEEP_ALIVE: OLLAMA_LLM_LIBRARY: OLLAMA_MAX_LOADED_MODELS:1 OLLAMA_MAX_QUEUE:512 OLLAMA_MAX_VRAM:0 OLLAMA_MODELS: OLLAMA_NOHISTORY:false OLLAMA_NOPRUNE:false OLLAMA_NUM_PARALLEL:1 OLLAMA_ORIGINS:[http://localhost https://localhost http://localhost:* https://localhost:* http://127.0.0.1 https://127.0.0.1 http://127.0.0.1:* https://127.0.0.1:* http://0.0.0.0 https://0.0.0.0 http://0.0.0.0:* https://0.0.0.0:*] OLLAMA_RUNNERS_DIR: OLLAMA_TMPDIR:]" May 31 01:44:39 myuserPC ollama[355046]: Error: mkdir /home/myuser/.ollama: permission denied May 31 01:44:39 myuserPC systemd[1]: ollama.service: Main process exited, code=exited, status=1/FAILURE May 31 01:44:39 myuserPC systemd[1]: ollama.service: Failed with result 'exit-code'. ``` As you can see, Ollama tries to create the `.ollama` directory in the user's home directory, regardless of whether the directory exists or not. **Additional Information**: - I have tried different permissions and ownerships, including an exact file-by-file copy of permissions and ownership from `/usr/share/ollama`. - Running `/usr/local/bin/ollama serve` does not show any error, unlike `sudo systemctl restart ollama`. **Other Methods Attempted**: 1. **Symlink Attempt**: I tried using `ln -s` to map models from the default directory to a new location at `/home/myuser/.ollama/models/` with correct permissions and ownership. This resulted in a "mkdir failed" error, as the models directory already exists. 2. **Editing Service Environment**: Editing the Service Environment using `sudo systemctl edit ollama.service` is problematic. If an error occurs, the added lines cannot be removed easily, requiring the removal of the override file using `sudo rm -rf /etc/systemd/system/ollama.service.d/override.conf`. I would appreciate any help or guidance on how to resolve this issue. ### OS Linux ### GPU Nvidia ### CPU Intel ### Ollama version 0.1.39
GiteaMirror added the bug label 2026-04-28 12:03:50 -05:00
GiteaMirror commented 2026-04-28 12:04:18 -05:00
Author
Owner
Copy Link

@followsound commented on GitHub (Jun 1, 2024):

I too am getting a "mkdir failed: error directory already exists” when trying to load models from an S3 mounted directory (using the official s3-mount project from AWS) in systemctl.

The same folder works fine if I run ollama serve in the CLI (either as root or a normal user without sudo) with the same directory option exported using the environment variable OLLAMA_MODELS.

This is on Amazon Linux 2023

<!-- gh-comment-id:2143592421 --> @followsound commented on GitHub (Jun 1, 2024): I too am getting a "mkdir failed: error directory already exists” when trying to load models from an S3 mounted directory (using the official s3-mount project from AWS) in systemctl. The same folder works fine if I run `ollama serve` in the CLI (either as root or a normal user without sudo) with the same directory option exported using the environment variable `OLLAMA_MODELS`. This is on Amazon Linux 2023
GiteaMirror commented 2026-04-28 12:04:21 -05:00
Author
Owner
Copy Link

@Jerry-Terrasse commented on GitHub (Jun 12, 2024):

Similar problem with me. I'm attempting to change models directory to an NTFS disk with symbolic link like this:

$ tree /var/lib/ollama -a
/var/lib/ollama
├── .nv  [error opening dir]
└── .ollama
    ├── id_ed25519
    ├── id_ed25519.pub
    └── models -> /home/terrasse/DATA/ollama_models

where /home/terrasse/DATA is the mount point of the NTFS disk.

I think I've already gave enough permissions, because GIN_MODE=release HOME=/var/lib/ollama sudo -u ollama -g ollama -E ollama serve works perfectly. However, the systemd service fails with following errors:

$ sudo journalctl -u ollama -e | tail
Jun 12 16:39:26 Mech-Mjr-Tera systemd[1]: ollama.service: Scheduled restart job, restart counter is at 896.
Jun 12 16:39:26 Mech-Mjr-Tera systemd[1]: Started Ollama Service.
Jun 12 16:39:26 Mech-Mjr-Tera ollama[77106]: 2024/06/12 16:39:26 routes.go:1007: INFO server config env="map[OLLAMA_DEBUG:false OLLAMA_FLASH_ATTENTION:false OLLAMA_HOST: OLLAMA_KEEP_ALIVE: OLLAMA_LLM_LIBRARY: OLLAMA_MAX_LOADED_MODELS:1 OLLAMA_MAX_QUEUE:512 OLLAMA_MAX_VRAM:0 OLLAMA_MODELS: OLLAMA_NOHISTORY:false OLLAMA_NOPRUNE:false OLLAMA_NUM_PARALLEL:1 OLLAMA_ORIGINS:[http://localhost https://localhost http://localhost:* https://localhost:* http://127.0.0.1 https://127.0.0.1 http://127.0.0.1:* https://127.0.0.1:* http://0.0.0.0 https://0.0.0.0 http://0.0.0.0:* https://0.0.0.0:*] OLLAMA_RUNNERS_DIR: OLLAMA_TMPDIR:]"
Jun 12 16:39:26 Mech-Mjr-Tera ollama[77106]: Error: mkdir /home/terrasse: permission denied
Jun 12 16:39:26 Mech-Mjr-Tera systemd[1]: ollama.service: Main process exited, code=exited, status=1/FAILURE
Jun 12 16:39:26 Mech-Mjr-Tera systemd[1]: ollama.service: Failed with result 'exit-code'.

That's really weired.

<!-- gh-comment-id:2162443014 --> @Jerry-Terrasse commented on GitHub (Jun 12, 2024): Similar problem with me. I'm attempting to change models directory to an NTFS disk with symbolic link like this: ```shell $ tree /var/lib/ollama -a /var/lib/ollama ├── .nv [error opening dir] └── .ollama ├── id_ed25519 ├── id_ed25519.pub └── models -> /home/terrasse/DATA/ollama_models ``` where /home/terrasse/DATA is the mount point of the NTFS disk. I think I've already gave enough permissions, because `GIN_MODE=release HOME=/var/lib/ollama sudo -u ollama -g ollama -E ollama serve` works perfectly. However, the systemd service fails with following errors: ```shell $ sudo journalctl -u ollama -e | tail Jun 12 16:39:26 Mech-Mjr-Tera systemd[1]: ollama.service: Scheduled restart job, restart counter is at 896. Jun 12 16:39:26 Mech-Mjr-Tera systemd[1]: Started Ollama Service. Jun 12 16:39:26 Mech-Mjr-Tera ollama[77106]: 2024/06/12 16:39:26 routes.go:1007: INFO server config env="map[OLLAMA_DEBUG:false OLLAMA_FLASH_ATTENTION:false OLLAMA_HOST: OLLAMA_KEEP_ALIVE: OLLAMA_LLM_LIBRARY: OLLAMA_MAX_LOADED_MODELS:1 OLLAMA_MAX_QUEUE:512 OLLAMA_MAX_VRAM:0 OLLAMA_MODELS: OLLAMA_NOHISTORY:false OLLAMA_NOPRUNE:false OLLAMA_NUM_PARALLEL:1 OLLAMA_ORIGINS:[http://localhost https://localhost http://localhost:* https://localhost:* http://127.0.0.1 https://127.0.0.1 http://127.0.0.1:* https://127.0.0.1:* http://0.0.0.0 https://0.0.0.0 http://0.0.0.0:* https://0.0.0.0:*] OLLAMA_RUNNERS_DIR: OLLAMA_TMPDIR:]" Jun 12 16:39:26 Mech-Mjr-Tera ollama[77106]: Error: mkdir /home/terrasse: permission denied Jun 12 16:39:26 Mech-Mjr-Tera systemd[1]: ollama.service: Main process exited, code=exited, status=1/FAILURE Jun 12 16:39:26 Mech-Mjr-Tera systemd[1]: ollama.service: Failed with result 'exit-code'. ``` That's really weired.
GiteaMirror commented 2026-04-28 12:04:22 -05:00
Author
Owner
Copy Link

@wiiznokes commented on GitHub (Jun 16, 2024):

Same issue here

<!-- gh-comment-id:2170979915 --> @wiiznokes commented on GitHub (Jun 16, 2024): Same issue here
GiteaMirror commented 2026-04-28 12:04:23 -05:00
Author
Owner
Copy Link

@magicalne commented on GitHub (Jun 16, 2024):

Instead of using OLLAMA_MODELS, I simply created a symbolic link using ln -s. Moreover, replacing the user/group 'ollama' in the file ollama.service with my regular username (UID 1000) has proven effective for me.

<!-- gh-comment-id:2171022701 --> @magicalne commented on GitHub (Jun 16, 2024): Instead of using `OLLAMA_MODELS`, I simply created a symbolic link using `ln -s`. Moreover, replacing the user/group 'ollama' in the file `ollama.service` with my regular username (UID 1000) has proven effective for me.
GiteaMirror commented 2026-04-28 12:04:24 -05:00
Author
Owner
Copy Link

@pykeras commented on GitHub (Jun 16, 2024):

Instead of using OLLAMA_MODELS, I simply created a symbolic link using ln -s. Moreover, replacing the user/group 'ollama' in the file ollama.service with my regular username (UID 1000) has proven effective for me.

A symbolic link doesn’t work by itself, but changing the user/group permissions may help. This raises another question: why does this service need parent directory permissions? Also, why are they running mkdir when the directory already exists?
I think somebody forgot to check if the directory exists before creating it again.

<!-- gh-comment-id:2171274775 --> @pykeras commented on GitHub (Jun 16, 2024): > Instead of using `OLLAMA_MODELS`, I simply created a symbolic link using `ln -s`. Moreover, replacing the user/group 'ollama' in the file `ollama.service` with my regular username (UID 1000) has proven effective for me. A symbolic link doesn’t work by itself, but changing the user/group permissions may help. This raises another question: why does this service need parent directory permissions? Also, why are they running mkdir when the directory already exists? I think somebody forgot to check if the directory exists before creating it again.
GiteaMirror commented 2026-04-28 12:04:24 -05:00
Author
Owner
Copy Link

@Jerry-Terrasse commented on GitHub (Jun 16, 2024):

Instead of using OLLAMA_MODELS, I simply created a symbolic link using ln -s. Moreover, replacing the user/group 'ollama' in the file ollama.service with my regular username (UID 1000) has proven effective for me.

A symbolic link doesn’t work by itself, but changing the user/group permissions may help. This raises another question: why does this service need parent directory permissions? Also, why are they running mkdir when the directory already exists? I think somebody forgot to check if the directory exists before creating it again.

Cannot agree more :)

<!-- gh-comment-id:2171367166 --> @Jerry-Terrasse commented on GitHub (Jun 16, 2024): > > Instead of using `OLLAMA_MODELS`, I simply created a symbolic link using `ln -s`. Moreover, replacing the user/group 'ollama' in the file `ollama.service` with my regular username (UID 1000) has proven effective for me. > > A symbolic link doesn’t work by itself, but changing the user/group permissions may help. This raises another question: why does this service need parent directory permissions? Also, why are they running mkdir when the directory already exists? I think somebody forgot to check if the directory exists before creating it again. Cannot agree more :)
GiteaMirror commented 2026-04-28 12:04:24 -05:00
Author
Owner
Copy Link

@wiiznokes commented on GitHub (Jun 16, 2024):

I can confirm that creating a sym link (with ln -s /home/fedasus/HDD/ollama_models /home/fedasus/.ollama/models) didn't worked, but replacing user/group with my username solved it.

<!-- gh-comment-id:2171695239 --> @wiiznokes commented on GitHub (Jun 16, 2024): I can confirm that creating a sym link (with `ln -s /home/fedasus/HDD/ollama_models /home/fedasus/.ollama/models`) didn't worked, but replacing user/group with my username solved it.
GiteaMirror commented 2026-04-28 12:04:25 -05:00
Author
Owner
Copy Link

@pykeras commented on GitHub (Jun 16, 2024):

I'm not a GoLang developer, but I think that in server/modelpath.go, one must use os.Stat(dir); os.IsNotExist(err). If the result is true, then try to make the directory.

I found this file based on searching for OLLAMA_MODELS and os.MkdirAll when I discovered the purpose
of this function is responsible for creating directories in GoLang.

<!-- gh-comment-id:2171750346 --> @pykeras commented on GitHub (Jun 16, 2024): I'm not a GoLang developer, but I think that in [server/modelpath.go](https://github.com/ollama/ollama/blob/89c79bec8cf7a7b04f761fcc5306d2edf47a4164/server/modelpath.go#L136), one must use `os.Stat(dir); os.IsNotExist(err)`. If the result is true, then try to make the directory. I found this file based on searching for `OLLAMA_MODELS` and `os.MkdirAll` when I discovered the purpose of this function is responsible for creating directories in GoLang.
GiteaMirror commented 2026-04-28 12:04:25 -05:00
Author
Owner
Copy Link

@Jerry-Terrasse commented on GitHub (Jun 19, 2024):

Hey, guys. Probably I've figured it out.

In https://github.com/ollama/ollama/issues/4732#issuecomment-2162443014, I mentioned a weird phenomenon:

I think I've already gave enough permissions, because GIN_MODE=release HOME=/var/lib/ollama sudo -u ollama -g ollama -E ollama serve works perfectly. However, the systemd service fails with following errors:

That's because the systemd service configuration:

ProtectHome=yes

which makes my home read-only, causing ollama cannot write to /home/terrasse/DATA/ollama_models, which is symbolic-linked to /var/lib/ollama/.ollama/models

👇 👇 👇
In short, @pykeras 's problem probably can be solved by simply add one line ProtectHome=no in /etc/systemd/system/ollama.service.d/override.conf

<!-- gh-comment-id:2177662175 --> @Jerry-Terrasse commented on GitHub (Jun 19, 2024): Hey, guys. Probably I've figured it out. In https://github.com/ollama/ollama/issues/4732#issuecomment-2162443014, I mentioned a weird phenomenon: > I think I've already gave enough permissions, because `GIN_MODE=release HOME=/var/lib/ollama sudo -u ollama -g ollama -E ollama serve` works perfectly. However, the systemd service fails with following errors: That's because the systemd service configuration: > ProtectHome=yes which makes my home read-only, causing ollama cannot write to `/home/terrasse/DATA/ollama_models`, which is symbolic-linked to `/var/lib/ollama/.ollama/models` 👇 👇 👇 In short, @pykeras 's problem probably can be solved by simply add one line `ProtectHome=no` in `/etc/systemd/system/ollama.service.d/override.conf`
GiteaMirror commented 2026-04-28 12:04:26 -05:00
Author
Owner
Copy Link

@pykeras commented on GitHub (Jun 19, 2024):

Hey, guys. Probably I've figured it out.

In #4732 (comment), I mentioned a weird phenomenon:

I think I've already gave enough permissions, because GIN_MODE=release HOME=/var/lib/ollama sudo -u ollama -g ollama -E ollama serve works perfectly. However, the systemd service fails with following errors:

That's because the systemd service configuration:

ProtectHome=yes

which makes my home read-only, causing ollama cannot write to /home/terrasse/DATA/ollama_models, which is symbolic-linked to /var/lib/ollama/.ollama/models

👇 👇 👇 In short, @pykeras 's problem probably can be solved by simply add one line ProtectHome=no in /etc/systemd/system/ollama.service.d/override.conf

still doesn't work, that's weird as it works with /usr/local/bin/ollama serve but systemctl start ollama does not work.

<!-- gh-comment-id:2179006794 --> @pykeras commented on GitHub (Jun 19, 2024): > Hey, guys. Probably I've figured it out. > > In [#4732 (comment)](https://github.com/ollama/ollama/issues/4732#issuecomment-2162443014), I mentioned a weird phenomenon: > > > I think I've already gave enough permissions, because `GIN_MODE=release HOME=/var/lib/ollama sudo -u ollama -g ollama -E ollama serve` works perfectly. However, the systemd service fails with following errors: > > That's because the systemd service configuration: > > > ProtectHome=yes > > which makes my home read-only, causing ollama cannot write to `/home/terrasse/DATA/ollama_models`, which is symbolic-linked to `/var/lib/ollama/.ollama/models` > > 👇 👇 👇 In short, @pykeras 's problem probably can be solved by simply add one line `ProtectHome=no` in `/etc/systemd/system/ollama.service.d/override.conf` still doesn't work, that's weird as it works with `/usr/local/bin/ollama serve` but `systemctl start ollama` does not work.
GiteaMirror commented 2026-04-28 12:04:26 -05:00
Author
Owner
Copy Link

@Jerry-Terrasse commented on GitHub (Jun 19, 2024):

Hey, guys. Probably I've figured it out.
In #4732 (comment), I mentioned a weird phenomenon:

I think I've already gave enough permissions, because GIN_MODE=release HOME=/var/lib/ollama sudo -u ollama -g ollama -E ollama serve works perfectly. However, the systemd service fails with following errors:

That's because the systemd service configuration:

ProtectHome=yes

which makes my home read-only, causing ollama cannot write to /home/terrasse/DATA/ollama_models, which is symbolic-linked to /var/lib/ollama/.ollama/models
👇 👇 👇 In short, @pykeras 's problem probably can be solved by simply add one line ProtectHome=no in /etc/systemd/system/ollama.service.d/override.conf

still doesn't work, that's weird as it works with /usr/local/bin/ollama serve but systemctl start ollama does not work.

How about try adding Group=myuser and User=myuser to override.conf? Sorry about my omission.

<!-- gh-comment-id:2179013206 --> @Jerry-Terrasse commented on GitHub (Jun 19, 2024): > > Hey, guys. Probably I've figured it out. > > In [#4732 (comment)](https://github.com/ollama/ollama/issues/4732#issuecomment-2162443014), I mentioned a weird phenomenon: > > > I think I've already gave enough permissions, because `GIN_MODE=release HOME=/var/lib/ollama sudo -u ollama -g ollama -E ollama serve` works perfectly. However, the systemd service fails with following errors: > > > > > > That's because the systemd service configuration: > > > ProtectHome=yes > > > > > > which makes my home read-only, causing ollama cannot write to `/home/terrasse/DATA/ollama_models`, which is symbolic-linked to `/var/lib/ollama/.ollama/models` > > 👇 👇 👇 In short, @pykeras 's problem probably can be solved by simply add one line `ProtectHome=no` in `/etc/systemd/system/ollama.service.d/override.conf` > > still doesn't work, that's weird as it works with `/usr/local/bin/ollama serve` but `systemctl start ollama` does not work. How about try adding `Group=myuser` and `User=myuser` to `override.conf`? Sorry about my omission.
GiteaMirror commented 2026-04-28 12:04:26 -05:00
Author
Owner
Copy Link

@pykeras commented on GitHub (Jun 19, 2024):

Hey, guys. Probably I've figured it out.
In #4732 (comment), I mentioned a weird phenomenon:

I think I've already gave enough permissions, because GIN_MODE=release HOME=/var/lib/ollama sudo -u ollama -g ollama -E ollama serve works perfectly. However, the systemd service fails with following errors:

That's because the systemd service configuration:

ProtectHome=yes

which makes my home read-only, causing ollama cannot write to /home/terrasse/DATA/ollama_models, which is symbolic-linked to /var/lib/ollama/.ollama/models
👇 👇 👇 In short, @pykeras 's problem probably can be solved by simply add one line ProtectHome=no in /etc/systemd/system/ollama.service.d/override.conf

still doesn't work, that's weird as it works with /usr/local/bin/ollama serve but systemctl start ollama does not work.

How about try adding Group=myuser and User=myuser to override.conf? Sorry about my omission.

That may work, but as I said before this can't be a good practice, especially in Linux (security, logs)

<!-- gh-comment-id:2179307991 --> @pykeras commented on GitHub (Jun 19, 2024): > > > Hey, guys. Probably I've figured it out. > > > In [#4732 (comment)](https://github.com/ollama/ollama/issues/4732#issuecomment-2162443014), I mentioned a weird phenomenon: > > > > I think I've already gave enough permissions, because `GIN_MODE=release HOME=/var/lib/ollama sudo -u ollama -g ollama -E ollama serve` works perfectly. However, the systemd service fails with following errors: > > > > > > > > > That's because the systemd service configuration: > > > > ProtectHome=yes > > > > > > > > > which makes my home read-only, causing ollama cannot write to `/home/terrasse/DATA/ollama_models`, which is symbolic-linked to `/var/lib/ollama/.ollama/models` > > > 👇 👇 👇 In short, @pykeras 's problem probably can be solved by simply add one line `ProtectHome=no` in `/etc/systemd/system/ollama.service.d/override.conf` > > > > > > still doesn't work, that's weird as it works with `/usr/local/bin/ollama serve` but `systemctl start ollama` does not work. > > How about try adding `Group=myuser` and `User=myuser` to `override.conf`? Sorry about my omission. That may work, but as I said before this can't be a good practice, especially in Linux (security, logs)
GiteaMirror commented 2026-04-28 12:04:27 -05:00
Author
Owner
Copy Link

@magicalne commented on GitHub (Jun 20, 2024):

Well, if you still want to use the ollama user, then you can install Ollama by yourself. You can get the idea from install.sh.

$SUDO useradd -r -s /bin/false -U -m -d /usr/share/ollama ollama

The command specifies a home directory when creating the Ollama user. And that's why we're gathered here 😭. I think you can specify a new home directory for Ollama with usermod. Alternatively, you can delete Ollama and create a new one.

<!-- gh-comment-id:2179632545 --> @magicalne commented on GitHub (Jun 20, 2024): Well, if you still want to use the ollama user, then you can install Ollama by yourself. You can get the idea from [install.sh](https://github.com/ollama/ollama/blob/main/scripts/install.sh#L85-L103). > $SUDO useradd -r -s /bin/false -U -m -d /usr/share/ollama ollama The command specifies a home directory when creating the Ollama user. And that's why we're gathered here 😭. I think you can specify a new home directory for Ollama with usermod. Alternatively, you can delete Ollama and create a new one.
GiteaMirror commented 2026-04-28 12:04:27 -05:00
Author
Owner
Copy Link

@Jerry-Terrasse commented on GitHub (Jun 22, 2024):

Hello @pykeras , I found something new. What the service actually need is the x permission of the parent directories, as a matter of course.
I mean, ln -s + ProtectHome=no + chmod o+x /home/terrasse worked for me. The service uses ollama user in this way. In my understanding, this configuration is safe enough.

I'd post my whole final config here:

$ ls -al /var/lib/ollama/.ollama/models
lrwxrwxrwx 1 root root 49 Jun 19 12:06 /var/lib/ollama/.ollama/models -> /home/terrasse/DATA/Manjaro/ollama/.ollama/models
$ ls -al /home
total 20
drwxr-xr-x   3 root     root      4096 Mar  1  2023 .
drwxr-xr-x  19 root     root      4096 Jun  4 20:36 ..
drwx-----x 171 terrasse terrasse 12288 Jun 22 15:06 terrasse

/usr/lib/systemd/system/ollama.service:

[Unit]
Description=Ollama Service
Wants=network-online.target
After=network.target network-online.target

[Service]
ExecStart=/usr/bin/ollama serve
WorkingDirectory=/var/lib/ollama
Environment="GIN_MODE=release" "HOME=/var/lib/ollama"
User=ollama
Group=ollama
Restart=on-failure
RestartSec=3
Type=simple
PrivateTmp=yes
ProtectSystem=full
ProtectHome=yes

[Install]
WantedBy=multi-user.target

/etc/systemd/system/ollama.service.d/override.conf:

[Service]
Environment="GIN_MODE=release" "HOME=/var/lib/ollama" "OLLAMA_HOST=127.0.0.1:11434"
ProtectHome=no
<!-- gh-comment-id:2183879675 --> @Jerry-Terrasse commented on GitHub (Jun 22, 2024): Hello @pykeras , I found something new. What the service actually need is the `x` permission of the parent directories, as a matter of course. I mean, `ln -s` + `ProtectHome=no` + `chmod o+x /home/terrasse` worked for me. The service uses `ollama` user in this way. In my understanding, this configuration is safe enough. --- I'd post my whole final config here: ``` $ ls -al /var/lib/ollama/.ollama/models lrwxrwxrwx 1 root root 49 Jun 19 12:06 /var/lib/ollama/.ollama/models -> /home/terrasse/DATA/Manjaro/ollama/.ollama/models $ ls -al /home total 20 drwxr-xr-x 3 root root 4096 Mar 1 2023 . drwxr-xr-x 19 root root 4096 Jun 4 20:36 .. drwx-----x 171 terrasse terrasse 12288 Jun 22 15:06 terrasse ``` `/usr/lib/systemd/system/ollama.service`: ``` [Unit] Description=Ollama Service Wants=network-online.target After=network.target network-online.target [Service] ExecStart=/usr/bin/ollama serve WorkingDirectory=/var/lib/ollama Environment="GIN_MODE=release" "HOME=/var/lib/ollama" User=ollama Group=ollama Restart=on-failure RestartSec=3 Type=simple PrivateTmp=yes ProtectSystem=full ProtectHome=yes [Install] WantedBy=multi-user.target ``` `/etc/systemd/system/ollama.service.d/override.conf`: ``` [Service] Environment="GIN_MODE=release" "HOME=/var/lib/ollama" "OLLAMA_HOST=127.0.0.1:11434" ProtectHome=no ```
GiteaMirror commented 2026-04-28 12:04:27 -05:00
Author
Owner
Copy Link

@pykeras commented on GitHub (Jun 29, 2024):

Hello @pykeras , I found something new. What the service actually need is the x permission of the parent directories, as a matter of course. I mean, ln -s + ProtectHome=no + chmod o+x /home/terrasse worked for me. The service uses ollama user in this way. In my understanding, this configuration is safe enough.

Hi, and thank you for the solution! While I understand the recommendation to add o+x permissions to the user’s home directory, I have taken some alternative steps to address the issue as I don't believe using 'o+x' on user home directory is safe. Below, I’ve outlined a step-by-step guide:

  1. create a new directory for Ollama:
  • Open your terminal and create a new directory named .ollamaHome in your home directory:
mkdir ~/.ollamaHome
  1. Adjust Ownership:
  • Change the ownership of the newly created directory to the user ollama:
cd ~ && sudo chown -R ollama:ollama .ollamaHome
  1. Set Permissions:
  • To allow execute permissions for others, modify the permissions of the .ollamaHome directory:
sudo chmod 755 .ollamaHome
  1. Optional: Move Existing Models:
  • If you currently have models on your system, consider moving them to the new directory:
sudo mv /usr/share/ollama/.ollama ~/.ollamaHome
  1. Update Ollama Service Configuration:
  • Edit the ollama.service file:
sudo nano /etc/systemd/system/ollama.service
  • Add the following lines under the [Service] section:
...
[Service]
...
ProtectHome=no
Environment="Home=/home/yourusername/.ollamaHome/.ollama/"
Environment="OLLAMA_MODELS=/home/yourusername/.ollamaHome/.ollama/models"
...
  1. Reload Daemon and Restart Ollama Service:
sudo systemctl daemon-reload
sudo systemctl restart ollama.service

Now, if you run ollama list, you should see the list of previous models (if you completed step 4).
Feel free to adjust these steps according to your specific setup. Let me know if you need any further assistance!

<!-- gh-comment-id:2198036140 --> @pykeras commented on GitHub (Jun 29, 2024): > Hello @pykeras , I found something new. What the service actually need is the `x` permission of the parent directories, as a matter of course. I mean, `ln -s` + `ProtectHome=no` + `chmod o+x /home/terrasse` worked for me. The service uses `ollama` user in this way. In my understanding, this configuration is safe enough. > Hi, and thank you for the solution! While I understand the recommendation to add `o+x` permissions to the user’s home directory, I have taken some alternative steps to address the issue as I don't believe using 'o+x' on user home directory is safe. Below, I’ve outlined a step-by-step guide: 1) __create a new directory for Ollama:__ * _Open your terminal and create a new directory named .ollamaHome in your home directory:_ ```bash mkdir ~/.ollamaHome ``` 2) __Adjust Ownership:__ * _Change the ownership of the newly created directory to the user `ollama`:_ ```bash cd ~ && sudo chown -R ollama:ollama .ollamaHome ``` 3) __Set Permissions:__ * _To allow execute permissions for others, modify the permissions of the .ollamaHome directory:_ ```bash sudo chmod 755 .ollamaHome ``` 4) **Optional: Move Existing Models:** * _If you currently have models on your system, consider moving them to the new directory:_ ```bash sudo mv /usr/share/ollama/.ollama ~/.ollamaHome ``` 5) __Update Ollama Service Configuration:__ * _Edit the `ollama.service` file:_ ```bash sudo nano /etc/systemd/system/ollama.service ``` * _Add the following lines under the [Service] section:_ ```bash ... [Service] ... ProtectHome=no Environment="Home=/home/yourusername/.ollamaHome/.ollama/" Environment="OLLAMA_MODELS=/home/yourusername/.ollamaHome/.ollama/models" ... ``` 6) __Reload Daemon and Restart Ollama Service:__ ```bash sudo systemctl daemon-reload sudo systemctl restart ollama.service ``` Now, if you run ollama list, you should see the list of previous models (if you completed step $4$). Feel free to adjust these steps according to your specific setup. Let me know if you need any further assistance!
GiteaMirror commented 2026-04-28 12:04:28 -05:00
Author
Owner
Copy Link

@Jerry-Terrasse commented on GitHub (Jun 29, 2024):

That's great. 👍👍👍

<!-- gh-comment-id:2198037798 --> @Jerry-Terrasse commented on GitHub (Jun 29, 2024): That's great. 👍👍👍
GiteaMirror commented 2026-04-28 12:04:30 -05:00
Author
Owner
Copy Link

@EmilPosmyk commented on GitHub (Jun 29, 2024):

hello all,

I moved all data in the same way but on different disk, with same folder structure. I followed pykeras instructions. Added also line:
Environment="OLLAMA_MODELS=/media/xyz/ollama_models/.ollamaHome/.ollama/models"
But when I add this line:
Environment="Home=/media/xyz/ollama_models/.ollamaHome/.ollama
the ollama server doesn't start at all. When I call: 'systemctl status ollama' it shows FAILURE...exited

but when I use 'ollama serve' it works with this line even and it shows all models moved to the external disk, but this I'd like to have still as a startup service. Does anyone know why it works like that ?

<!-- gh-comment-id:2198328878 --> @EmilPosmyk commented on GitHub (Jun 29, 2024): hello all, I moved all data in the same way but on different disk, with same folder structure. I followed pykeras instructions. Added also line: Environment="OLLAMA_MODELS=/media/xyz/ollama_models/.ollamaHome/.ollama/models" But when I add this line: Environment="Home=/media/xyz/ollama_models/.ollamaHome/.ollama the ollama server doesn't start at all. When I call: 'systemctl status ollama' it shows FAILURE...exited but when I use 'ollama serve' it works with this line even and it shows all models moved to the external disk, but this I'd like to have still as a startup service. Does anyone know why it works like that ?
GiteaMirror commented 2026-04-28 12:04:31 -05:00
Author
Owner
Copy Link

@Jerry-Terrasse commented on GitHub (Jun 30, 2024):

When you run ollama serve, you launch the process with your own user instead of ollama, which is used in the systemd service and maybe lacks some permissions. Try the command below to reproduce the execution of the service:

GIN_MODE=release HOME=/media/xyz/ollama_models/.ollamaHome  sudo -u ollama -g ollama -E ollama serve

To solve this problem, probably you should make sure the ollama user has enough permissions to that folder.

<!-- gh-comment-id:2198397811 --> @Jerry-Terrasse commented on GitHub (Jun 30, 2024): When you run `ollama serve`, you launch the process with your own user instead of `ollama`, which is used in the systemd service and maybe lacks some permissions. Try the command below to reproduce the execution of the service: ```shell GIN_MODE=release HOME=/media/xyz/ollama_models/.ollamaHome sudo -u ollama -g ollama -E ollama serve ``` To solve this problem, probably you should make sure the `ollama` user has enough permissions to that folder.
GiteaMirror commented 2026-04-28 12:04:32 -05:00
Author
Owner
Copy Link

@EmilPosmyk commented on GitHub (Jun 30, 2024):

This is what I suspected ... permissions to the mounted external disk. In my case mounting disk label is: 'ollama_models'.
After executing this command which you provided I got:
'Error: mkdir /media/xyz/ollama_models: permission denied'
... why it tries to create that folder ?

I tried:
sudo chown -R ollama:ollama ollama_models
sudo chmod -R 755 ollama_models

But still the same.
I'll take a look into this later. If any ideas still let me know. Thanks

<!-- gh-comment-id:2198444717 --> @EmilPosmyk commented on GitHub (Jun 30, 2024): This is what I suspected ... permissions to the mounted external disk. In my case mounting disk label is: 'ollama_models'. After executing this command which you provided I got: 'Error: mkdir /media/xyz/ollama_models: permission denied' ... why it tries to create that folder ? I tried: sudo chown -R ollama:ollama ollama_models sudo chmod -R 755 ollama_models But still the same. I'll take a look into this later. If any ideas still let me know. Thanks
GiteaMirror commented 2026-04-28 12:04:32 -05:00
Author
Owner
Copy Link

@Jerry-Terrasse commented on GitHub (Jun 30, 2024):

This is what I suspected ... permissions to the mounted external disk. In my case mounting disk label is: 'ollama_models'.
After executing this command which you provided I got:
'Error: mkdir /media/xyz/ollama_models: permission denied'
... why it tries to create that folder ?

I tried:
sudo chown -R ollama:ollama ollama_models
sudo chmod -R 755 ollama_models

But still the same.
I'll take a look into this later. If any ideas still let me know. Thanks

Check if user ollama has 'x' permission on the parent directories, it's needed to open folders even if already owned.

<!-- gh-comment-id:2198446180 --> @Jerry-Terrasse commented on GitHub (Jun 30, 2024): > This is what I suspected ... permissions to the mounted external disk. In my case mounting disk label is: 'ollama_models'. > After executing this command which you provided I got: > 'Error: mkdir /media/xyz/ollama_models: permission denied' > ... why it tries to create that folder ? > > I tried: > sudo chown -R ollama:ollama ollama_models > sudo chmod -R 755 ollama_models > > But still the same. > I'll take a look into this later. If any ideas still let me know. Thanks Check if user ollama has 'x' permission on the parent directories, it's needed to open folders even if already owned.
GiteaMirror commented 2026-04-28 12:04:32 -05:00
Author
Owner
Copy Link

@EmilPosmyk commented on GitHub (Jun 30, 2024):

yes :-) after executing: 'sudo chmod -R +x xyz' it works inside /media dir, I guess I shouldn.t use this time -R parameter

many thanks !

<!-- gh-comment-id:2198458317 --> @EmilPosmyk commented on GitHub (Jun 30, 2024): yes :-) after executing: 'sudo chmod -R +x xyz' it works inside /media dir, I guess I shouldn.t use this time -R parameter many thanks !
GiteaMirror commented 2026-04-28 12:04:33 -05:00
Author
Owner
Copy Link

@kasp0r commented on GitHub (Sep 5, 2024):

Can confirm that pykeras's method works. I can confirm the following for Ubuntu 24.04.

Step 1
Create your relevant directory:

mkdir -p /media/storage/ollama

Step 2
Ensure the permissions to that directory are valid via chmod.

Step 3
Edit your ollama.service

sudo nano /etc/systemd/system/ollama.service

Add the following line in the [Service] section. I added an extra Environment parameter at the end of the entries

Environment="OLLAMA_MODELS=/media/storage/ollama"

Step 4
Restart the daemon and ollama.

systemctl daemon-reload
systemctl restart ollama

You should now be ready to go.

<!-- gh-comment-id:2332250627 --> @kasp0r commented on GitHub (Sep 5, 2024): Can confirm that pykeras's method works. I can confirm the following for Ubuntu 24.04. **Step 1** Create your relevant directory: ``` mkdir -p /media/storage/ollama ``` **Step 2** Ensure the permissions to that directory are valid via `chmod`. **Step 3** Edit your ollama.service ``` sudo nano /etc/systemd/system/ollama.service ``` Add the following line in the [Service] section. I added an extra `Environment` parameter at the end of the entries ``` Environment="OLLAMA_MODELS=/media/storage/ollama" ``` **Step 4** Restart the daemon and ollama. ``` systemctl daemon-reload systemctl restart ollama ``` You should now be ready to go.
GiteaMirror commented 2026-04-28 12:04:34 -05:00
Author
Owner
Copy Link

@ctwardy commented on GitHub (Sep 25, 2024):

Further Context: symlinks

In addition to user permissions issues launching as "ollama" vs me, it
seems the models dir cannot be a symlink. Ollama will create the "models" dir even if there is already a "models" symlink there, resulting in a file-shadowing condition.

See for example the Bind Mount Solution here where GPT notes:

Symlinks have limitations that might not satisfy some applications' checks for directories or files.

They provide a partial solution using bind mounts. I solved my issue by reversing a symlink. My big drive is mounted on /data, and I have LLM models in /data/appuser/models/ with folders for TheBloke or Llama etc.

Fails: I thought I'd symlink /data/ollama/models ➛ /data/appusers/models/ollama. But ollama ignored the symlink and created a folder /data/ollama/models right on top of it. That was shadowed by the pre-existing symlink, causing the issues. (Removing the symlink revealed the hidden folder.)

Works: make /data/ollama/models a folder, and reverse the symlink if I want my other folder to acknowledge ollama models.

My /data/ollama folder permissions -- owned by ollama. (Here writeable by users for testing, but that doesn't seem to be necessary for serving from systemctl):

    drwxrwxr-x.  4 ollama users  66 Sep 25 14:10 ./ 
    drwxr-xr-x. 10 root   root  125 Sep 25 13:49 ../ 
    drwxrwxr-x.  4 ollama users  36 Sep 25 14:12 models/ 
    drwxrwxr-x.  4 ollama users  54 Sep 25 17:24 tmp/

Then my ollama.service has:

    Environment="OLLAMA_MODELS=/data/ollama/models"
    Environment="OLLAMA_TMPDIR=/data/ollama/tmp"

That worked.

Actually fixing:

If the code checked for files-or-folders-or-symlinks, that might solves this part of the issue. Or at least result in clearer errors.

<!-- gh-comment-id:2375148349 --> @ctwardy commented on GitHub (Sep 25, 2024): # Further Context: symlinks In addition to user permissions issues launching as "ollama" vs me, it **seems the models dir cannot be a symlink**. Ollama will create the "models" dir even if there is already a "models" symlink there, resulting in a **file-shadowing condition.** See for example [the Bind Mount Solution here](https://bbs.archlinux.org/viewtopic.php?id=292487) where GPT notes: > Symlinks have limitations that might not satisfy some applications' checks for directories or files. They provide a partial solution using **bind mounts**. I solved my issue by reversing a symlink. My big drive is mounted on `/data`, and I have LLM models in `/data/appuser/models/` with folders for `TheBloke` or `Llama` etc. **Fails:** I thought I'd symlink `/data/ollama/models` **➛** `/data/appusers/models/ollama`. But ollama ignored the symlink and created a _folder_ `/data/ollama/models` right on top of it. That was shadowed by the pre-existing symlink, causing the issues. (Removing the symlink revealed the hidden folder.) **Works:** make `/data/ollama/models` a folder, and reverse the symlink if I want my other folder to acknowledge ollama models. My `/data/ollama` folder permissions -- owned by ollama. (Here writeable by users for testing, but that doesn't seem to be necessary for serving from systemctl): ```bash drwxrwxr-x. 4 ollama users 66 Sep 25 14:10 ./ drwxr-xr-x. 10 root root 125 Sep 25 13:49 ../ drwxrwxr-x. 4 ollama users 36 Sep 25 14:12 models/ drwxrwxr-x. 4 ollama users 54 Sep 25 17:24 tmp/ ``` Then my `ollama.service` has: ```bash Environment="OLLAMA_MODELS=/data/ollama/models" Environment="OLLAMA_TMPDIR=/data/ollama/tmp" ``` That worked. ## Actually fixing: If the code checked for files-or-folders-or-symlinks, that might solves this part of the issue. Or at least result in clearer errors.
GiteaMirror commented 2026-04-28 12:04:34 -05:00
Author
Owner
Copy Link

@iwannabewater commented on GitHub (Jan 6, 2025):

I configured the ollama.service unit file in /etc/systemd/system/ by setting the User and Group directives to my username. Additionally, I included the Environment directive with OLLAMA_MODELS=/path/to/dir. After reloading the daemon with sudo systemctl daemon-reload and sudo systemctl restart ollama, it functioned as expected. It's crucial to note that /path/to/dir was created under my user's ownership to avoid permission problems.

<!-- gh-comment-id:2572656526 --> @iwannabewater commented on GitHub (Jan 6, 2025): I configured the ollama.service unit file in /etc/systemd/system/ by setting the User and Group directives to my username. Additionally, I included the Environment directive with OLLAMA_MODELS=/path/to/dir. After reloading the daemon with `sudo systemctl daemon-reload` and `sudo systemctl restart ollama`, it functioned as expected. It's crucial to note that /path/to/dir was created under my user's ownership to avoid permission problems.
GiteaMirror commented 2026-04-28 12:04:34 -05:00
Author
Owner
Copy Link

@neeraj-j commented on GitHub (Mar 7, 2025):

To summarize this long thread:
Please check if your home dir has read permissions for 'others' ie. chmod 755 home_dir. If 'ollama' group/user does not have read permissions into your home dir, it wont be able to read if the dir already exists hence trying to create an existing dir.

If you don't want to give this permission,
Then other option as mentioned above is to change group /user of ollama to your home group/user

<!-- gh-comment-id:2705866208 --> @neeraj-j commented on GitHub (Mar 7, 2025): To summarize this long thread: Please check if your home dir has read permissions for 'others' ie. chmod 755 home_dir. If 'ollama' group/user does not have read permissions into your home dir, it wont be able to read if the dir already exists hence trying to create an existing dir. If you don't want to give this permission, Then other option as mentioned above is to change group /user of ollama to your home group/user
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
amd
api
app
bug
build
cli
cloud
compatibility
context-length
create
docker
documentation
embeddings
feature request
feedback wanted
good first issue
gpt-oss
gpu
harmony
help wanted
image
install
intel
js
launch
linux
macos
memory
mlx
model
needs more info
networking
nvidia
ollama.com
performance
pull-request
Mirrored from GitHub Pull Request
 python
question
registry
rendering
thinking
tools
top
vulkan
windows
wsl
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/ollama#49495
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?