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

[PR #15941] fix(install.sh): always ensure ollama home directory ownership #77663

New Issue
Open
opened 2026-05-05 10:20:23 -05:00 by GiteaMirror · 0 comments
GiteaMirror commented 2026-05-05 10:20:23 -05:00
Owner
Copy Link

📋 Pull Request Information

Original PR: https://github.com/ollama/ollama/pull/15941
Author: @Anai-Guo
Created: 5/3/2026
Status: 🔄 Open

Base: main ← Head: fix/install-ollama-home-permissions

📝 Commits (1)

  • 87cdff8 fix(install.sh): always chown ollama home dir to fix permission denied on Ubuntu 24.04 (#15940)

📊 Changes

1 file changed (+6 additions, -0 deletions)

View changed files

📝 scripts/install.sh (+6 -0)

📄 Description

Closes #15940

What

When the install script runs useradd -r -s /bin/false -U -m -d /usr/share/ollama ollama, the -m flag only creates /usr/share/ollama (and gives it the right ownership) if it does not already exist. On Ubuntu 24.04 / Debian trixie systems where /usr/share/ollama may be pre-created with root ownership (or when the script is re-run with the user already existing — the entire useradd call is skipped by the surrounding if ! id ollama guard), the directory is left owned by root:root with 0755. The systemd service then fails at startup:

Error: could not create directory mkdir /usr/share/ollama: permission denied

Fix

After the user-creation block, run

$SUDO install -d -o ollama -g ollama -m 0755 /usr/share/ollama

unconditionally. install -d is idempotent — it creates the directory if missing and applies the requested ownership/mode either way — so this is safe on every code path (fresh install, re-run with existing user, dir pre-created by something else).

Why this approach over the alternatives

  • mkdir -p + chown -R would also work but chown -R could touch large existing model trees the user has placed under /usr/share/ollama, which is undesirable. install -d only acts on the directory itself.
  • Adding Environment="HOME=/usr/share/ollama" to the service unit is unnecessary: systemd already derives HOME from /etc/passwd for User=ollama, so the env var is correct — the only failure is the ownership of the directory itself.
  • Verification via systemctl is-active belongs in a separate change; this PR keeps the scope to the root cause reported in the issue.

Test plan

  • Fresh Ubuntu 24.04 box, /usr/share/ollama does not exist → behavior unchanged from before (useradd creates it; install -d is a no-op for ownership).
  • Box where /usr/share/ollama already exists owned by root:root (the bug repro) → after this patch, ownership flips to ollama:ollama and the service starts cleanly.
  • Re-running the installer (id ollama succeeds, useradd is skipped) → install -d still re-asserts ownership, so a manual chown performed earlier as a workaround keeps working.

🤖 Generated with Claude Code

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/ollama/ollama/pull/15941 **Author:** [@Anai-Guo](https://github.com/Anai-Guo) **Created:** 5/3/2026 **Status:** 🔄 Open **Base:** `main` ← **Head:** `fix/install-ollama-home-permissions` --- ### 📝 Commits (1) - [`87cdff8`](https://github.com/ollama/ollama/commit/87cdff864fedbb21c6824809429cd7085d7264c6) fix(install.sh): always chown ollama home dir to fix permission denied on Ubuntu 24.04 (#15940) ### 📊 Changes **1 file changed** (+6 additions, -0 deletions) <details> <summary>View changed files</summary> 📝 `scripts/install.sh` (+6 -0) </details> ### 📄 Description Closes #15940 ## What When the install script runs `useradd -r -s /bin/false -U -m -d /usr/share/ollama ollama`, the `-m` flag only creates `/usr/share/ollama` (and gives it the right ownership) **if it does not already exist**. On Ubuntu 24.04 / Debian trixie systems where `/usr/share/ollama` may be pre-created with root ownership (or when the script is re-run with the user already existing — the entire `useradd` call is skipped by the surrounding `if ! id ollama` guard), the directory is left owned by `root:root` with `0755`. The systemd service then fails at startup: ``` Error: could not create directory mkdir /usr/share/ollama: permission denied ``` ## Fix After the user-creation block, run ```sh $SUDO install -d -o ollama -g ollama -m 0755 /usr/share/ollama ``` unconditionally. `install -d` is idempotent — it creates the directory if missing and applies the requested ownership/mode either way — so this is safe on every code path (fresh install, re-run with existing user, dir pre-created by something else). ## Why this approach over the alternatives - **`mkdir -p` + `chown -R`** would also work but `chown -R` could touch large existing model trees the user has placed under `/usr/share/ollama`, which is undesirable. `install -d` only acts on the directory itself. - **Adding `Environment="HOME=/usr/share/ollama"` to the service unit** is unnecessary: systemd already derives `HOME` from `/etc/passwd` for `User=ollama`, so the env var is correct — the only failure is the ownership of the directory itself. - **Verification via `systemctl is-active`** belongs in a separate change; this PR keeps the scope to the root cause reported in the issue. ## Test plan - Fresh Ubuntu 24.04 box, `/usr/share/ollama` does not exist → behavior unchanged from before (useradd creates it; `install -d` is a no-op for ownership). - Box where `/usr/share/ollama` already exists owned by `root:root` (the bug repro) → after this patch, ownership flips to `ollama:ollama` and the service starts cleanly. - Re-running the installer (`id ollama` succeeds, useradd is skipped) → `install -d` still re-asserts ownership, so a manual `chown` performed earlier as a workaround keeps working. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
GiteaMirror added the pull-request label 2026-05-05 10:20:23 -05:00
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 pull-request
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#77663
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?