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

[GH-ISSUE #3828] Upgrading to v0.1.32 doesn't automatically rename model blobs from sha256:<BLOB_NAME> to sha256-<BLOB_NAME> #48882

New Issue
Closed
opened 2026-04-28 09:57:48 -05:00 by GiteaMirror · 4 comments
GiteaMirror commented 2026-04-28 09:57:48 -05:00
Owner
Copy Link

Originally created by @swoh816 on GitHub (Apr 22, 2024).
Original GitHub issue: https://github.com/ollama/ollama/issues/3828

What is the issue?

I recently upgraded Ollama to v0.1.32, and I couldn't launch Ollama with sudo systemctl start ollama.service and had an error ollama ExecStart=/usr/local/bin/ollama serve (code=exited, status=1/FAILURE). I found out that the reason is that the blob names were not changed from sha256:<BLOB_HASH> to sha256-<BLOB_HASH>, which is necessary for upgrading to version v0.1.32 in Linux as of https://github.com/ollama/ollama/issues/2032.

I checked the log, and found out that there was a permission issue when changing the blob name:

sudo[2809771]:   swoh816 : TTY=pts/146 ; PWD=/home/swoh816 ; USER=root ; COMMAND=/usr/bin/install -o0 -g0 -m755 /tmp/tmp.zdpcq2BjgA/ollama /usr/local/bin/ollama
sudo[2809776]:   swoh816 : TTY=pts/146 ; PWD=/home/swoh816 ; USER=root ; COMMAND=/usr/sbin/usermod -a -G render ollama
sudo[2809783]:   swoh816 : TTY=pts/146 ; PWD=/home/swoh816 ; USER=root ; COMMAND=/usr/sbin/usermod -a -G video ollama
sudo[2809790]:   swoh816 : TTY=pts/146 ; PWD=/home/swoh816 ; USER=root ; COMMAND=/usr/sbin/usermod -a -G ollama swoh816
sudo[2809797]:   swoh816 : TTY=pts/146 ; PWD=/home/swoh816 ; USER=root ; COMMAND=/usr/bin/tee /etc/systemd/system/ollama.service
sudo[2809858]:   swoh816 : TTY=pts/146 ; PWD=/home/swoh816 ; USER=root ; COMMAND=/usr/bin/systemctl enable ollama
sudo[2809885]:   swoh816 : TTY=pts/146 ; PWD=/home/swoh816 ; USER=root ; COMMAND=/usr/bin/systemctl restart ollama
ollama[2809890]: Error: rename /usr/share/ollama/.ollama/models/blobs/sha256:0577f52a4edfd5e48bb59c296bb4f40328161ecc3d0aa4398b3cb6b2b7367cac /usr/share/ollama/.ollama/models/blobs/sha256-0577f52a4edfd5e48bb59c296bb4f40328161ecc3d0aa4398b3cb6b2b7367cac: permission denied
systemd[1]: ollama.service: Main process exited, code=exited, status=1/FAILURE
systemd[1]: ollama.service: Failed with result 'exit-code'.
systemd[1]: ollama.service: Scheduled restart job, restart counter is at 1.

Given that the error log prints right after restarting ollama (i.e., systemctl restart ollama), I suspect the permission error occurs when restarting ollama. Probably ollama serve (which is triggered when you do systemctl restart ollama) is supposed to run a code to rename all sha:<BLOB_NAME> formats to sha-<BLOB_NAME>, but it fails to do so because of the permission issue?
I tried to figure out by looking into 62be2050dd/scripts/install.sh (L83) but couldn't find much clue :p Hopefully this issue helps debugging!

OS

Linux

GPU

Nvidia

CPU

AMD

Ollama version

0.1.32

Originally created by @swoh816 on GitHub (Apr 22, 2024). Original GitHub issue: https://github.com/ollama/ollama/issues/3828 ### What is the issue? I recently upgraded Ollama to v0.1.32, and I couldn't launch Ollama with `sudo systemctl start ollama.service` and had an error `ollama ExecStart=/usr/local/bin/ollama serve (code=exited, status=1/FAILURE)`. I found out that the reason is that **the blob names were not changed from `sha256:<BLOB_HASH>` to `sha256-<BLOB_HASH>`**, which is necessary for upgrading to version v0.1.32 in Linux as of https://github.com/ollama/ollama/issues/2032. I checked the log, and found out that there was a permission issue when changing the blob name: ``` sudo[2809771]: swoh816 : TTY=pts/146 ; PWD=/home/swoh816 ; USER=root ; COMMAND=/usr/bin/install -o0 -g0 -m755 /tmp/tmp.zdpcq2BjgA/ollama /usr/local/bin/ollama sudo[2809776]: swoh816 : TTY=pts/146 ; PWD=/home/swoh816 ; USER=root ; COMMAND=/usr/sbin/usermod -a -G render ollama sudo[2809783]: swoh816 : TTY=pts/146 ; PWD=/home/swoh816 ; USER=root ; COMMAND=/usr/sbin/usermod -a -G video ollama sudo[2809790]: swoh816 : TTY=pts/146 ; PWD=/home/swoh816 ; USER=root ; COMMAND=/usr/sbin/usermod -a -G ollama swoh816 sudo[2809797]: swoh816 : TTY=pts/146 ; PWD=/home/swoh816 ; USER=root ; COMMAND=/usr/bin/tee /etc/systemd/system/ollama.service sudo[2809858]: swoh816 : TTY=pts/146 ; PWD=/home/swoh816 ; USER=root ; COMMAND=/usr/bin/systemctl enable ollama sudo[2809885]: swoh816 : TTY=pts/146 ; PWD=/home/swoh816 ; USER=root ; COMMAND=/usr/bin/systemctl restart ollama ollama[2809890]: Error: rename /usr/share/ollama/.ollama/models/blobs/sha256:0577f52a4edfd5e48bb59c296bb4f40328161ecc3d0aa4398b3cb6b2b7367cac /usr/share/ollama/.ollama/models/blobs/sha256-0577f52a4edfd5e48bb59c296bb4f40328161ecc3d0aa4398b3cb6b2b7367cac: permission denied systemd[1]: ollama.service: Main process exited, code=exited, status=1/FAILURE systemd[1]: ollama.service: Failed with result 'exit-code'. systemd[1]: ollama.service: Scheduled restart job, restart counter is at 1. ``` Given that the error log prints right after restarting ollama (i.e., `systemctl restart ollama`), I suspect the permission error occurs when restarting `ollama`. Probably `ollama serve` (which is triggered when you do `systemctl restart ollama`) is supposed to run a code to rename all `sha:<BLOB_NAME>` formats to `sha-<BLOB_NAME>`, but it fails to do so because of the permission issue? I tried to figure out by looking into https://github.com/ollama/ollama/blob/62be2050dd83197864d771fe6891fc47486ee6a1/scripts/install.sh#L83 but couldn't find much clue :p Hopefully this issue helps debugging! ### OS Linux ### GPU Nvidia ### CPU AMD ### Ollama version 0.1.32
GiteaMirror added the bug label 2026-04-28 09:57:48 -05:00
GiteaMirror commented 2026-04-28 09:57:50 -05:00
Author
Owner
Copy Link

@pdevine commented on GitHub (Apr 22, 2024):

hi @swoh816 , I think your ollama user just doesn't have access to write to /usr/share/ollama/.ollama/models/blobs/. Can you try ls -l /usr/share/ollama/.ollama/models/? It should look something like:

drwxr-xr-x 2 ollama ollama 12288 Apr 17 17:55 blobs
drwxr-xr-x 3 ollama ollama  4096 Mar 11 18:14 manifests
<!-- gh-comment-id:2070637391 --> @pdevine commented on GitHub (Apr 22, 2024): hi @swoh816 , I think your ollama user just doesn't have access to write to `/usr/share/ollama/.ollama/models/blobs/`. Can you try `ls -l /usr/share/ollama/.ollama/models/`? It should look something like: ``` drwxr-xr-x 2 ollama ollama 12288 Apr 17 17:55 blobs drwxr-xr-x 3 ollama ollama 4096 Mar 11 18:14 manifests ```
GiteaMirror commented 2026-04-28 09:57:51 -05:00
Author
Owner
Copy Link

@swoh816 commented on GitHub (Apr 22, 2024):

You're probably right, I might have changed the owner/group of the directories from ollama to root. (I don't have this problem anymore because I changed the model blob names when I experienced this problem, and I created this issue after some time.) Maybe it would help to force change the owner and group of the directories during the installation process like install.sh?

<!-- gh-comment-id:2070923846 --> @swoh816 commented on GitHub (Apr 22, 2024): You're probably right, I might have changed the owner/group of the directories from ollama to root. (I don't have this problem anymore because I changed the model blob names when I experienced this problem, and I created this issue after some time.) Maybe it would help to force change the owner and group of the directories during the installation process like `install.sh`?
GiteaMirror commented 2026-04-28 09:57:51 -05:00
Author
Owner
Copy Link

@pdevine commented on GitHub (Apr 22, 2024):

@swoh816 I'd be a little worried about doing that in the install script since I wouldn't want to inadvertently overwrite someone's models.

I'm going to go ahead and close the issue for now. We can always reopen it in the future if it gets to be a problem.

<!-- gh-comment-id:2070929921 --> @pdevine commented on GitHub (Apr 22, 2024): @swoh816 I'd be a little worried about doing that in the install script since I wouldn't want to inadvertently overwrite someone's models. I'm going to go ahead and close the issue for now. We can always reopen it in the future if it gets to be a problem.
GiteaMirror commented 2026-04-28 09:57:53 -05:00
Author
Owner
Copy Link

@swoh816 commented on GitHub (Apr 22, 2024):

@pdevine Correct me if I'm wrong, but wouldn't it be okay to force change the owner/group of ollama-related directories to ollama since the models in the directories are only for ollama anyway? Also, Ollama returns an error if it finds any model whose owner/group is not ollama (which is why this issue was created), so I can't think of a use case where a user puts a model into Ollama directory deliberately when the user is not going to use the model with Ollama.

<!-- gh-comment-id:2071089078 --> @swoh816 commented on GitHub (Apr 22, 2024): @pdevine Correct me if I'm wrong, but wouldn't it be okay to force change the owner/group of ollama-related directories to `ollama` since the models in the directories are only for `ollama` anyway? Also, Ollama returns an error if it finds any model whose owner/group is not `ollama` (which is why this issue was created), so I can't think of a use case where a user puts a model into Ollama directory deliberately when the user is not going to use the model with Ollama.
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#48882
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?