github-starred/ollama
2
0
Fork 0
mirror of https://github.com/ollama/ollama.git synced 2026-07-15 12:48:05 -05:00
Code Issues 16.9k Packages Projects Releases 122 Wiki Activity

[GH-ISSUE #13970] ollama.tar.zstd extracts files to current directory without top-level folder #9138

New Issue
Open
opened 2026-04-12 21:59:28 -05:00 by GiteaMirror · 6 comments
GiteaMirror commented 2026-04-12 21:59:28 -05:00
Owner
Copy Link

Originally created by @bnjmnjrk on GitHub (Jan 29, 2026).
Original GitHub issue: https://github.com/ollama/ollama/issues/13970

Describe the Inconvenience

When unpacking ollama-linux-amd64.tar.zst using tar -xf ollama-linux-amd64.tar.zst, all files extract directly into the current working directory, crowding it instead of preserving a clean top-level directory structure like ollama/.

Steps to Reproduce

wget https://ollama.com/download/ollama-linux-amd64.tar.zst
tar -xf ollama-linux-amd64.tar.zst
# observe files dumped into current dir

Expected: Files should unpack into ./ollama/ (or similar root folder).

Actual: Flat extraction clutters CWD.

Proposed Solution

Modify the tarball creation to include a top-level directory.
This matches standard practices when using tar.

Originally created by @bnjmnjrk on GitHub (Jan 29, 2026). Original GitHub issue: https://github.com/ollama/ollama/issues/13970 ### Describe the Inconvenience When unpacking `ollama-linux-amd64.tar.zst` using `tar -xf ollama-linux-amd64.tar.zst`, all files extract directly into the current working directory, crowding it instead of preserving a clean top-level directory structure like `ollama/`. ### Steps to Reproduce ``` wget https://ollama.com/download/ollama-linux-amd64.tar.zst tar -xf ollama-linux-amd64.tar.zst # observe files dumped into current dir ``` Expected: Files should unpack into `./ollama/` (or similar root folder). Actual: Flat extraction clutters CWD. ### Proposed Solution Modify the tarball creation to include a top-level directory. This matches standard practices when using tar.
GiteaMirror added the install label 2026-04-12 21:59:28 -05:00
GiteaMirror commented 2026-04-12 21:59:30 -05:00
Author
Owner
Copy Link

@rick-github commented on GitHub (Jan 29, 2026):

The manual install instructions show how to use -C to set the location to extract the archive.

<!-- gh-comment-id:3817700573 --> @rick-github commented on GitHub (Jan 29, 2026): The [manual install instructions](https://github.com/ollama/ollama/blob/main/docs/linux.mdx#manual-install) show how to use `-C` to set the location to extract the archive.
GiteaMirror commented 2026-04-12 21:59:31 -05:00
Author
Owner
Copy Link

@bnjmnjrk commented on GitHub (Jan 29, 2026):

The manual instructions are actually part of the problem here.

They recommend downloading a random tarball from the internet and extracting it directly into /usr with sudo. That’s not a harmless location — /usr is managed by the distro’s package manager and is supposed to contain files that come from official packages. Dropping unmanaged files in there is how systems become messy, conflict-prone, and hard to maintain.

On top of that, the command requires sudo, which makes it even worse from a security and system integrity perspective. If a user already has root access, the logical and safer approach is to install software through the distribution’s package manager, not bypass it with a manually downloaded archive.

The documentation even shows how to download and extract the archive in a rootless way — which makes it clear this could have been designed as a user-local install. In that case, the extraction target should be something like:

~/.local/ (per-user install), or

/usr/local/ (for software installed manually by the admin, outside the package manager’s control)

Both of those follow standard Linux filesystem conventions. /usr does not.

So while tar -C controls where files go, it doesn’t fix the underlying issue:
the archive layout is unfriendly and the official instructions encourage installing third-party binaries into a distro-owned system path with root privileges, which is poor practice.

<!-- gh-comment-id:3817995360 --> @bnjmnjrk commented on GitHub (Jan 29, 2026): The manual instructions are actually part of the problem here. They recommend downloading a random tarball from the internet and extracting it directly into /usr with sudo. That’s not a harmless location — /usr is managed by the distro’s package manager and is supposed to contain files that come from official packages. Dropping unmanaged files in there is how systems become messy, conflict-prone, and hard to maintain. On top of that, the command requires sudo, which makes it even worse from a security and system integrity perspective. If a user already has root access, the logical and safer approach is to install software through the distribution’s package manager, not bypass it with a manually downloaded archive. The documentation even shows how to download and extract the archive in a rootless way — which makes it clear this could have been designed as a user-local install. In that case, the extraction target should be something like: ~/.local/ (per-user install), or /usr/local/ (for software installed manually by the admin, outside the package manager’s control) Both of those follow standard Linux filesystem conventions. /usr does not. So while tar -C controls where files go, it doesn’t fix the underlying issue: the archive layout is unfriendly and the official instructions encourage installing third-party binaries into a distro-owned system path with root privileges, which is poor practice.
GiteaMirror commented 2026-04-12 21:59:32 -05:00
Author
Owner
Copy Link

@bnjmnjrk commented on GitHub (Jan 29, 2026):

This is not a duplicate of #8297. The current issue is specifically about the tarball extracting files directly into the current directory without a top-level folder, which is a distinct problem.

Closing this without properly reading the actual issue is frustrating, because it’s clearly a separate packaging bug that affects usability. Please reopen and address it.

<!-- gh-comment-id:3819271726 --> @bnjmnjrk commented on GitHub (Jan 29, 2026): This is not a duplicate of #8297. The current issue is specifically about the tarball extracting files directly into the current directory without a top-level folder, which is a distinct problem. Closing this without properly reading the actual issue is frustrating, because it’s clearly a separate packaging bug that affects usability. Please reopen and address it.
GiteaMirror commented 2026-04-12 21:59:33 -05:00
Author
Owner
Copy Link

@rick-github commented on GitHub (Jan 29, 2026):

I pointed out how to choose where to extract the archive. Relative paths are recommended for tar files as this prevents accidental overwriting of files.

The remaining underlying issue is Linux filesystem conventions which is examined in #8297.

<!-- gh-comment-id:3819335427 --> @rick-github commented on GitHub (Jan 29, 2026): I pointed out how to choose where to extract the archive. Relative paths are recommended for tar files as this prevents accidental overwriting of files. The remaining underlying issue is Linux filesystem conventions which is examined in #8297.
GiteaMirror commented 2026-04-12 21:59:34 -05:00
Author
Owner
Copy Link

@bnjmnjrk commented on GitHub (Jan 29, 2026):

I think there’s a misunderstanding here. The issue is not about choosing the directory with tar -C before untarring.

The problem is with the packaging itself. Untarring the provided ollama-linux-amd64.tar.zst directly in the current working directory results in a messy output.

Using tar -C ollama as a workaround doesn’t work, because -C does not create directories — it only changes into an existing directory. This is fundamentally different from how zip archives can create directories on extraction.

The core issue: the tarball should include a top-level folder (e.g., ollama/) so that extraction is clean. This is a packaging problem, not a user error or a matter of where to run tar.

<!-- gh-comment-id:3819631024 --> @bnjmnjrk commented on GitHub (Jan 29, 2026): I think there’s a misunderstanding here. The issue is not about choosing the directory with tar -C before untarring. The problem is with the packaging itself. Untarring the provided ollama-linux-amd64.tar.zst directly in the current working directory results in a messy output. Using tar -C ollama as a workaround doesn’t work, because -C does not create directories — it only changes into an existing directory. This is fundamentally different from how zip archives can create directories on extraction. The core issue: the tarball should include a top-level folder (e.g., ollama/) so that extraction is clean. This is a packaging problem, not a user error or a matter of where to run tar.
GiteaMirror commented 2026-04-12 21:59:34 -05:00
Author
Owner
Copy Link

@rick-github commented on GitHub (Jan 29, 2026):

I apologize, I mistook "top-level folder" for the filesystem root.

<!-- gh-comment-id:3820247882 --> @rick-github commented on GitHub (Jan 29, 2026): I apologize, I mistook "top-level folder" for the filesystem root.
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 install
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#9138
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?