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 #228] Please don’t clutter the user home directory #62133

New Issue
Open
opened 2026-05-03 07:37:44 -05:00 by GiteaMirror · 36 comments
GiteaMirror commented 2026-05-03 07:37:44 -05:00
Owner
Copy Link

Originally created by @klmr on GitHub (Jul 27, 2023).
Original GitHub issue: https://github.com/ollama/ollama/issues/228

Currently Ollama is writing into a directory in the user home, ~/.ollama.

However, the user home directory should be under the user’s control, and applications may only write into it if explicitly instructed to do so by the user. Settings etc. belong in OS-specific locations; in particular, under ~/Library on macOS, under %AppData% or %LocalAppData% on Windows and, by convention, in directories following the XDG basedir specification on Linux.

Originally created by @klmr on GitHub (Jul 27, 2023). Original GitHub issue: https://github.com/ollama/ollama/issues/228 Currently Ollama is writing into a directory in the user home, `~/.ollama`. However, the user home directory should be under the *user’s* control, and applications may only write into it if explicitly instructed to do so by the user. Settings etc. belong in OS-specific locations; in particular, under `~/Library` on macOS, under `%AppData%` or `%LocalAppData%` on Windows and, by convention, in directories following the [XDG basedir specification](https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html) on Linux.
GiteaMirror added the feature request label 2026-05-03 07:37:44 -05:00
GiteaMirror commented 2026-05-03 07:37:48 -05:00
Author
Owner
Copy Link

@lukeman commented on GitHub (Jul 28, 2023):

For now I'm symlinking ~/.ollama to another spot in macOS, but agree it would make sense to utilize ~/Library, %AppData% and the like while letting folks choose if they'd like to store things (particularly model blobs/manifests) in a user-defined spot.

A few related tickets, albeit these are more focused on just the model blobs:

<!-- gh-comment-id:1656404572 --> @lukeman commented on GitHub (Jul 28, 2023): For now I'm symlinking `~/.ollama` to another spot in macOS, but agree it would make sense to utilize `~/Library`, `%AppData%` and the like while letting folks choose if they'd like to store things (particularly model blobs/manifests) in a user-defined spot. A few related tickets, albeit these are more focused on just the model blobs: - https://github.com/jmorganca/ollama/issues/155 - https://github.com/jmorganca/ollama/issues/153
GiteaMirror commented 2026-05-03 07:37:52 -05:00
Author
Owner
Copy Link

@klmr commented on GitHub (Oct 27, 2023):

If I understand correctly, #897 does not implement this feature request, since it only changes the path of the model files, but the path ~/.ollama remains in use for other purposes (see https://github.com/search?q=repo%3Ajmorganca%2Follama%20%22.ollama%22&type=code), notably for the server authentication, logs and readline history.

(There’s another, minor, issue that this solution still requires explicitly setting an environment variable instead of using the appropriate location by default: ideally ~/.ollama should only ever be used as a fallback [if it exists and the correct location doesn’t] for backwards compatibility.)

<!-- gh-comment-id:1783076712 --> @klmr commented on GitHub (Oct 27, 2023): If I understand correctly, #897 does *not* implement this feature request, since it only changes the path of the model files, but the path `~/.ollama` remains in use for other purposes (see https://github.com/search?q=repo%3Ajmorganca%2Follama%20%22.ollama%22&type=code), notably for the server authentication, logs and readline history. (There’s another, minor, issue that this solution still requires explicitly setting an environment variable instead of using the appropriate location by default: ideally `~/.ollama` should only ever be used as a fallback [if it exists and the correct location doesn’t] for backwards compatibility.)
GiteaMirror commented 2026-05-03 07:37:55 -05:00
Author
Owner
Copy Link

@miku commented on GitHub (Nov 7, 2023):

I'd like to add that there is a quasi-standard called XDG, which helps to keep $HOME clean and to organize applications files.

E.g. the model files could live under $XDG_DATA_HOME/ollama/models - which would mostly be $HOME/.local/share/ollama/models.

This would reduce surprises, at least for those familiar with XDG.

<!-- gh-comment-id:1798866991 --> @miku commented on GitHub (Nov 7, 2023): I'd like to add that there is a quasi-standard called [XDG](https://wiki.archlinux.org/title/XDG_Base_Directory), which helps to keep `$HOME` clean and to organize applications files. E.g. the model files could live under `$XDG_DATA_HOME/ollama/models` - which would mostly be `$HOME/.local/share/ollama/models`. This would reduce surprises, at least for those familiar with XDG.
GiteaMirror commented 2026-05-03 07:37:56 -05:00
Author
Owner
Copy Link

@luckydonald commented on GitHub (Jan 15, 2024):

I mean a user being able to set OLLAMA_HOME would be sufficient.
And align perfectly with OLLAMA_MODELS of #897.

I personally like the location in the user dir; a lot of other linuxy tools do that as well.
And for the models, I share them with multiple users of the computers (they are huge) so I symlinked the models folder to a shared location anyway.

<!-- gh-comment-id:1892221405 --> @luckydonald commented on GitHub (Jan 15, 2024): I mean a user being able to set `OLLAMA_HOME` would be sufficient. And align perfectly with `OLLAMA_MODELS` of #897. I personally like the location in the user dir; a lot of other linuxy tools do that as well. And for the models, I share them with multiple users of the computers (they are huge) so I symlinked the models folder to a shared location anyway.
GiteaMirror commented 2026-05-03 07:37:57 -05:00
Author
Owner
Copy Link

@mozlima commented on GitHub (Jan 15, 2024):

Maybe:

os.UserConfigDir

os.UserCacheDir

<!-- gh-comment-id:1892249350 --> @mozlima commented on GitHub (Jan 15, 2024): Maybe: [os.UserConfigDir](https://pkg.go.dev/os#UserConfigDir) [os.UserCacheDir](https://pkg.go.dev/os#UserCacheDir)
GiteaMirror commented 2026-05-03 07:37:57 -05:00
Author
Owner
Copy Link

@noahgitsham commented on GitHub (May 12, 2024):

Made #4382 to address this, but don't know much about macOS to debug the failing test. Any help would be greatly appreciated.

<!-- gh-comment-id:2106375122 --> @noahgitsham commented on GitHub (May 12, 2024): Made #4382 to address this, but don't know much about macOS to debug the failing test. Any help would be greatly appreciated.
GiteaMirror commented 2026-05-03 07:37:58 -05:00
Author
Owner
Copy Link

@abitrolly commented on GitHub (Jun 7, 2024):

This is the second most voted issue.

Will a config file placed in ~/.config/ollama/ dir solve the problem?

https://github.com/ollama/ollama/pull/4821 moves model path configuration into unified location. The next step would be to add config file to read values for these variables.

<!-- gh-comment-id:2155263628 --> @abitrolly commented on GitHub (Jun 7, 2024): This is the [second most voted](https://github.com/ollama/ollama/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc) issue. Will a config file placed in `~/.config/ollama/` dir solve the problem? https://github.com/ollama/ollama/pull/4821 moves model path configuration into unified location. The next step would be to add config file to read values for these variables.
GiteaMirror commented 2026-05-03 07:37:58 -05:00
Author
Owner
Copy Link

@leg7 commented on GitHub (Nov 5, 2024):

Any updates on this?

<!-- gh-comment-id:2458103343 --> @leg7 commented on GitHub (Nov 5, 2024): Any updates on this?
GiteaMirror commented 2026-05-03 07:37:59 -05:00
Author
Owner
Copy Link

@philocalyst commented on GitHub (Jan 13, 2025):

Don't know if this deserves its own separate issue, but when utilizing the OLLAMA_HOME env variable, all data is moved and accessed as expected, but keys are ignored if in the OLLAMA_HOME assigned-directory, and ollama produces a directory containing duplicates to read from.
ishare-1736742156-ghostty
ishare-1736742108-ghostty

<!-- gh-comment-id:2586149915 --> @philocalyst commented on GitHub (Jan 13, 2025): Don't know if this deserves its own separate issue, but when utilizing the OLLAMA_HOME env variable, all data is moved and accessed as expected, but keys are ignored if in the OLLAMA_HOME assigned-directory, and ollama produces a directory containing duplicates to read from. ![ishare-1736742156-ghostty](https://github.com/user-attachments/assets/00f158dd-9f12-41c5-b8ca-51569ad09791) ![ishare-1736742108-ghostty](https://github.com/user-attachments/assets/18160d24-2fa4-4c6d-885f-d3c46e9f3c8f)
GiteaMirror commented 2026-05-03 07:38:00 -05:00
Author
Owner
Copy Link

@ignamartinoli commented on GitHub (Jan 27, 2025):

I'm having the same problem

<!-- gh-comment-id:2616806729 --> @ignamartinoli commented on GitHub (Jan 27, 2025): I'm having the same problem
GiteaMirror commented 2026-05-03 07:38:01 -05:00
Author
Owner
Copy Link

@misterhackerman commented on GitHub (Jan 31, 2025):

A reminder of the latest XDG Base Directory Specifications

The XDG Base Directory Specification defines where user-specific and system-wide files should be stored and looked for. Key points:

User-specific directories:

$XDG_DATA_HOME → User data ($HOME/.local/share by default)
$XDG_CONFIG_HOME → Configuration files ($HOME/.config by default)
$XDG_STATE_HOME → State data ($HOME/.local/state by default)
$XDG_CACHE_HOME → Non-essential cached data ($HOME/.cache by default)
$XDG_RUNTIME_DIR → Temporary runtime files (must be user-owned, cleared on logout)

System-wide directories:

$XDG_DATA_DIRS → System-wide data (/usr/local/share/:/usr/share/ by default)
$XDG_CONFIG_DIRS → System-wide config (/etc/xdg by default)
Executables: $HOME/.local/bin should be in $PATH.

File lookup: User-specific files take precedence over system-wide files.

Handling: Applications should handle missing directories and permissions gracefully.

This standard ensures consistency and separation of config, data, and runtime files.

Link for the freedesktop webpage

<!-- gh-comment-id:2627710230 --> @misterhackerman commented on GitHub (Jan 31, 2025): # A reminder of the latest XDG Base Directory Specifications ## The XDG Base Directory Specification defines where user-specific and system-wide files should be stored and looked for. Key points: ### User-specific directories: `$XDG_DATA_HOME` → User data (`$HOME/.local/share` by default) `$XDG_CONFIG_HOME` → Configuration files (`$HOME/.config` by default) `$XDG_STATE_HOME` → State data (`$HOME/.local/state` by default) `$XDG_CACHE_HOME` → Non-essential cached data (`$HOME/.cache` by default) `$XDG_RUNTIME_DIR` → Temporary runtime files (must be user-owned, cleared on logout) ### System-wide directories: `$XDG_DATA_DIRS` → System-wide data (`/usr/local/share/:/usr/share/` by default) `$XDG_CONFIG_DIRS` → System-wide config (`/etc/xdg` by default) Executables: `$HOME/.local/bin` should be in `$PATH`. ### File lookup: User-specific files take precedence over system-wide files. ### Handling: Applications should handle missing directories and permissions gracefully. ### This standard ensures consistency and separation of config, data, and runtime files. [Link for the freedesktop webpage](https://specifications.freedesktop.org/basedir-spec/latest/)
GiteaMirror commented 2026-05-03 07:38:01 -05:00
Author
Owner
Copy Link

@klaribot commented on GitHub (Feb 3, 2025):

To add to this, if you have interactive CLI history (i.e. .ollama/history), you should be able to place this and similar "state" in the XDG-conformant directory $XDG_STATE_HOME.

Personally, I would look into being able to set an env var like OLLAMA_HISTORY=$XDG_STATE_HOME/ollama/history or =$XDG_STATE_HOME/ollama_history, but you can obviously pick whatever history location name you want, as long as it can be moved there in normal/interactive operation.

<!-- gh-comment-id:2632035270 --> @klaribot commented on GitHub (Feb 3, 2025): To add to this, if you have interactive CLI history (i.e. `.ollama/history`), you should be able to place this and similar "state" in the XDG-conformant directory `$XDG_STATE_HOME`. Personally, I would look into being able to set an env var like `OLLAMA_HISTORY=$XDG_STATE_HOME/ollama/history` or `=$XDG_STATE_HOME/ollama_history`, but you can obviously pick whatever history location name you want, as long as it can be moved there in normal/interactive operation.
GiteaMirror commented 2026-05-03 07:38:02 -05:00
Author
Owner
Copy Link

@woutervh commented on GitHub (Feb 4, 2025):

Will a config file placed in ~/.config/ollama/ dir solve the problem?

No.
XDG-dirs should always be a default.

OLLAMA_HOME allows the user to decides where to place files.
implement OLLAMA_HOME and default to XDG if not set.

<!-- gh-comment-id:2633585500 --> @woutervh commented on GitHub (Feb 4, 2025): >> Will a config file placed in ~/.config/ollama/ dir solve the problem? No. XDG-dirs should always be a **default**. OLLAMA_HOME allows the user to decides where to place files. implement OLLAMA_HOME and default to XDG if not set.
GiteaMirror commented 2026-05-03 07:38:02 -05:00
Author
Owner
Copy Link

@dandv commented on GitHub (Feb 4, 2025):

E.g. the model files could live under $XDG_DATA_HOME/ollama/models - which would mostly be $HOME/.local/share/ollama/models.

I'm late to the game, but agree with @miku and was surprised to not find the models anywhere in my Linux home dir.

  • ~/.ollama/models/ has only empty blobs and manifests directories
  • /usr/share/ollama/.ollama/models/blobs was not accessible by my user, and had to use sudo. Combined with the sha256-... filenames, rather than model names, this makes it cumbersome to share models with other tools.

LM Studio keeps the models with user-friendly names in ~/.lmstudio/models.

<!-- gh-comment-id:2633677089 --> @dandv commented on GitHub (Feb 4, 2025): > E.g. the model files could live under `$XDG_DATA_HOME/ollama/models` - which would mostly be `$HOME/.local/share/ollama/models`. I'm late to the game, but agree with @miku and was surprised to not find the models anywhere in my Linux home dir. * ~/.ollama/models/ has only empty `blobs` and `manifests` directories * `/usr/share/ollama/.ollama/models/blobs` was not accessible by my user, and had to use `sudo`. Combined with the `sha256-...` filenames, rather than model names, this makes it cumbersome to share models with other tools. LM Studio keeps the models with user-friendly names in `~/.lmstudio/models`.
GiteaMirror commented 2026-05-03 07:38:03 -05:00
Author
Owner
Copy Link

@rick-github commented on GitHub (Feb 4, 2025):

ollama serve vs sudo systemctl start ollama.

<!-- gh-comment-id:2633726205 --> @rick-github commented on GitHub (Feb 4, 2025): `ollama serve` vs `sudo systemctl start ollama`.
GiteaMirror commented 2026-05-03 07:38:04 -05:00
Author
Owner
Copy Link

@leg7 commented on GitHub (Feb 4, 2025):

Please don't make yet another var to pollute the env like OLLAMA_HOME. Doing this is makes me very sad.

<!-- gh-comment-id:2635201127 --> @leg7 commented on GitHub (Feb 4, 2025): Please don't make yet another var to pollute the env like `OLLAMA_HOME`. Doing this is makes me very sad.
GiteaMirror commented 2026-05-03 07:38:05 -05:00
Author
Owner
Copy Link

@woutervh commented on GitHub (Feb 5, 2025):

Please don't make yet another var to pollute the env like OLLAMA_HOME. Doing this is makes me very sad.

Environment variables are not "polluting" anything.
If sane defaults are used like $XDG-directories, then most users don't need them.

However, defaults still remain only just defaults,
and users should be allowed to override them.

For various reasons, I don't want anything written in my $HOME-directory.

<!-- gh-comment-id:2636376268 --> @woutervh commented on GitHub (Feb 5, 2025): > Please don't make yet another var to pollute the env like `OLLAMA_HOME`. Doing this is makes me very sad. Environment variables are not "polluting" anything. If sane defaults are used like $XDG-directories, then most users don't need them. However, defaults still remain only just _defaults,_ and users should be allowed to override them. For various reasons, I don't want anything written in my $HOME-directory.
GiteaMirror commented 2026-05-03 07:38:05 -05:00
Author
Owner
Copy Link

@ignamartinoli commented on GitHub (Feb 9, 2025):

@leg7 Facts.

Based af gigachad

<!-- gh-comment-id:2646178549 --> @ignamartinoli commented on GitHub (Feb 9, 2025): @leg7 Facts. Based af gigachad
GiteaMirror commented 2026-05-03 07:38:06 -05:00
Author
Owner
Copy Link

@abitrolly commented on GitHub (Feb 10, 2025):

It seems to me there are two conflicting use cases.

  1. ollama CLI that user runs. Try $XDG_CONFIG_HOME/ollama/config for a user-specific settings (I don't know if it should be YAML or INI or TOML yet)

  2. ollama server, which runs without desktop, and $XDG_CONFIG_HOME is empty

<!-- gh-comment-id:2647769054 --> @abitrolly commented on GitHub (Feb 10, 2025): It seems to me there are two conflicting use cases. 1. **`ollama` CLI** that user runs. Try `$XDG_CONFIG_HOME/ollama/config` for a user-specific settings (I don't know if it should be YAML or INI or TOML yet) 2. **`ollama` server**, which runs without desktop, and `$XDG_CONFIG_HOME` is empty
GiteaMirror commented 2026-05-03 07:38:06 -05:00
Author
Owner
Copy Link

@klaribot commented on GitHub (Feb 19, 2025):

@abitrolly not necessarily, the implementation can apply for both usecases, since the XDG spec really is only useful for user-focused systems, but doesn't force itself to exist in a server context. If any of the XDG vars don't exist, it's acceptable to fall back to the $HOME location.

In my opinion, simply checking for the appropriate vars and resolving their paths to use them for writing config and state locations, and gracefully defaulting to the existing implementation if they're not defined should cover both cases.

<!-- gh-comment-id:2667860166 --> @klaribot commented on GitHub (Feb 19, 2025): @abitrolly not necessarily, the implementation can apply for both usecases, since the XDG spec really is only useful for user-focused systems, but doesn't force itself to exist in a server context. If any of the XDG vars don't exist, it's acceptable to fall back to the $HOME location. In my opinion, simply checking for the appropriate vars and resolving their paths to use them for writing config and state locations, and gracefully defaulting to the existing implementation if they're not defined should cover both cases.
GiteaMirror commented 2026-05-03 07:38:07 -05:00
Author
Owner
Copy Link

@abitrolly commented on GitHub (Feb 19, 2025):

@klaribot so if I run ollama from my account, models get downloaded in into my personal XDG. And then I start ollama server with systemd, it starts to download them into nowhere, because system accounts don't have HOME. And if I create the account with HOME, it is still another place with another config, models and config bugs.

<!-- gh-comment-id:2668115379 --> @abitrolly commented on GitHub (Feb 19, 2025): @klaribot so if I run `ollama` from my account, models get downloaded in into my personal XDG. And then I start `ollama` server with `systemd`, it starts to download them into nowhere, because system accounts don't have HOME. And if I create the account with HOME, it is still another place with another config, models and config bugs.
GiteaMirror commented 2026-05-03 07:38:07 -05:00
Author
Owner
Copy Link

@ruro commented on GitHub (Feb 19, 2025):

@abitrolly if you are running the ollama server as a per-user service, then HOME/XDG_*_HOME would default to the home directory of your user. If you are running it as a system-wide service, then it makes perfect sense that it wouldn't automatically share the config/models location with your user.

<!-- gh-comment-id:2668872331 --> @ruro commented on GitHub (Feb 19, 2025): @abitrolly if you are running the `ollama` server as a per-user service, then `HOME`/`XDG_*_HOME` would default to the home directory of your user. If you are running it as a system-wide service, then it makes perfect sense that it wouldn't automatically share the config/models location with your user.
GiteaMirror commented 2026-05-03 07:38:08 -05:00
Author
Owner
Copy Link

@abitrolly commented on GitHub (Feb 19, 2025):

@ruro okay. $HOME/.config is a fallback if $XDG_CONFIG_HOME is not defined.

From https://specifications.freedesktop.org/basedir-spec/latest/#variables

$XDG_CONFIG_HOME defines the base directory relative to which user-specific configuration files should be stored. If $XDG_CONFIG_HOME is either not set or empty, a default equal to $HOME/.config should be used.

So is it okay if ollama first looks for its config file in $XDG_CONFIG_HOME, and reads from it the locations for other directories?

Or it is better if ollama has everything in $XDG_DATA_HOME by default without any configs?

<!-- gh-comment-id:2668903017 --> @abitrolly commented on GitHub (Feb 19, 2025): @ruro okay. `$HOME/.config` is a fallback if `$XDG_CONFIG_HOME` is not defined. From https://specifications.freedesktop.org/basedir-spec/latest/#variables > $XDG_CONFIG_HOME defines the base directory relative to which user-specific configuration files should be stored. If $XDG_CONFIG_HOME is either not set or empty, a default equal to $HOME/.config should be used. So is it okay if `ollama` first looks for its config file in `$XDG_CONFIG_HOME`, and reads from it the locations for other directories? Or it is better if `ollama` has everything in `$XDG_DATA_HOME` by default without any configs?
GiteaMirror commented 2026-05-03 07:38:08 -05:00
Author
Owner
Copy Link

@ruro commented on GitHub (Feb 19, 2025):

Personally, I only care about what happens after a clean installation of ollama, without any custom configuration.

By default, ollama should use XDG_CONFIG_HOME, XDG_CACHE_HOME and XDG_DATA_HOME/XDG_STATE_HOME for configuration, cache and persistent data. If there is some way to customize some of these paths by modifying the configuration, then that's just fine (as long as the default out-of-the-box behavior remains XDG-compliant).

<!-- gh-comment-id:2668927619 --> @ruro commented on GitHub (Feb 19, 2025): Personally, I only care about what happens after a clean installation of `ollama`, without any custom configuration. By default, `ollama` should use `XDG_CONFIG_HOME`, `XDG_CACHE_HOME` and `XDG_DATA_HOME`/`XDG_STATE_HOME` for configuration, cache and persistent data. If there is some way to customize some of these paths by modifying the configuration, then that's just fine (as long as the default out-of-the-box behavior remains XDG-compliant).
GiteaMirror commented 2026-05-03 07:38:09 -05:00
Author
Owner
Copy Link

@ignamartinoli commented on GitHub (Feb 20, 2025):

Sorry for interrupting the flow.
We now have OLLAMA_MODELS to move all those to an XDG compatible path like ~/.local/share/ollama.

What about the history, id_ed25519 and id_ed25519.pub files?
Are there any plans to make those comply too?

<!-- gh-comment-id:2670326990 --> @ignamartinoli commented on GitHub (Feb 20, 2025): Sorry for interrupting the flow. We now have `OLLAMA_MODELS` to move all those to an XDG compatible path like `~/.local/share/ollama`. What about the `history`, `id_ed25519` and `id_ed25519.pub` files? Are there any plans to make those comply too?
GiteaMirror commented 2026-05-03 07:38:10 -05:00
Author
Owner
Copy Link

@0xdevalias commented on GitHub (Feb 21, 2025):

And then I start ollama server with systemd, it starts to download them into nowhere, because system accounts don't have HOME.

  • https://specifications.freedesktop.org/basedir-spec/latest/#basics
      • There is a set of preference ordered base directories relative to which data files should be searched. This set of directories is defined by the environment variable $XDG_DATA_DIRS.
      • There is a set of preference ordered base directories relative to which configuration files should be searched. This set of directories is defined by the environment variable $XDG_CONFIG_DIRS.

    • $XDG_DATA_DIRS defines the preference-ordered set of base directories to search for data files in addition to the $XDG_DATA_HOME base directory. The directories in $XDG_DATA_DIRS should be separated with a colon ':'.

      If $XDG_DATA_DIRS is either not set or empty, a value equal to /usr/local/share/:/usr/share/ should be used.

      $XDG_CONFIG_DIRS defines the preference-ordered set of base directories to search for configuration files in addition to the $XDG_CONFIG_HOME base directory. The directories in $XDG_CONFIG_DIRS should be separated with a colon ':'.

      If $XDG_CONFIG_DIRS is either not set or empty, a value equal to /etc/xdg should be used.

      The order of base directories denotes their importance; the first directory listed is the most important. When the same information is defined in multiple places the information defined relative to the more important base directory takes precedent. The base directory defined by $XDG_DATA_HOME is considered more important than any of the base directories defined by $XDG_DATA_DIRS. The base directory defined by $XDG_CONFIG_HOME is considered more important than any of the base directories defined by $XDG_CONFIG_DIRS.

<!-- gh-comment-id:2673204424 --> @0xdevalias commented on GitHub (Feb 21, 2025): > And then I start `ollama` server with `systemd`, it starts to download them into nowhere, because system accounts don't have HOME. - https://specifications.freedesktop.org/basedir-spec/latest/#basics - > - There is a set of preference ordered base directories relative to which data files should be searched. This set of directories is defined by the environment variable `$XDG_DATA_DIRS`. > - There is a set of preference ordered base directories relative to which configuration files should be searched. This set of directories is defined by the environment variable `$XDG_CONFIG_DIRS`. - > `$XDG_DATA_DIRS` defines the preference-ordered set of base directories to search for data files in addition to the `$XDG_DATA_HOME` base directory. The directories in `$XDG_DATA_DIRS` should be separated with a colon ':'. > > If `$XDG_DATA_DIRS` is either not set or empty, a value equal to `/usr/local/share/:/usr/share/` should be used. > > `$XDG_CONFIG_DIRS` defines the preference-ordered set of base directories to search for configuration files in addition to the `$XDG_CONFIG_HOME` base directory. The directories in `$XDG_CONFIG_DIRS` should be separated with a colon ':'. > > If `$XDG_CONFIG_DIRS` is either not set or empty, a value equal to `/etc/xdg` should be used. > > The order of base directories denotes their importance; the first directory listed is the most important. When the same information is defined in multiple places the information defined relative to the more important base directory takes precedent. The base directory defined by `$XDG_DATA_HOME` is considered more important than any of the base directories defined by `$XDG_DATA_DIRS`. The base directory defined by `$XDG_CONFIG_HOME` is considered more important than any of the base directories defined by `$XDG_CONFIG_DIRS`.
GiteaMirror commented 2026-05-03 07:38:10 -05:00
Author
Owner
Copy Link

@abitrolly commented on GitHub (Feb 21, 2025):

Okay, the spec is more or less clear. Which local model can I use to write the code? I have 10 y/o Lenovo x250 laptop that can handle about 50 open tabs until it runs out of its 8Gb of memory.

<!-- gh-comment-id:2673281086 --> @abitrolly commented on GitHub (Feb 21, 2025): Okay, the spec is more or less clear. Which local model can I use to write the code? I have 10 y/o Lenovo x250 laptop that can handle about 50 open tabs until it runs out of its 8Gb of memory.
GiteaMirror commented 2026-05-03 07:38:11 -05:00
Author
Owner
Copy Link

@qhaas commented on GitHub (Feb 21, 2025):

The ability to set the location of the .ollama folder via environment variable would be useful for HPC workload managed (e.g. SLURM) jobs and containerization software that is often configured to be agnostic to a user's home directory inside the container image (e.g. apptainer / singularity). Of the two approaches described above (XDG vs OLLAMA_HOME), the XDG approach in linux is common and arguably more intuitive.

<!-- gh-comment-id:2674848043 --> @qhaas commented on GitHub (Feb 21, 2025): The ability to set the location of the `.ollama` folder via environment variable would be useful for HPC workload managed (e.g. SLURM) jobs and containerization software that is often configured to be agnostic to a user's home directory inside the container image (e.g. apptainer / singularity). Of the two approaches described above (XDG vs OLLAMA_HOME), the XDG approach in linux is common and arguably more intuitive.
GiteaMirror commented 2026-05-03 07:38:11 -05:00
Author
Owner
Copy Link

@abitrolly commented on GitHub (Mar 3, 2025):

I've added support for $XDG_DATA_HOME for models in https://github.com/ollama/ollama/pull/9477 but haven't tested it yet. Does anyone want to try it?

<!-- gh-comment-id:2694388248 --> @abitrolly commented on GitHub (Mar 3, 2025): I've added support for $XDG_DATA_HOME for models in https://github.com/ollama/ollama/pull/9477 but haven't tested it yet. Does anyone want to try it?
GiteaMirror commented 2026-05-03 07:38:12 -05:00
Author
Owner
Copy Link

@hildigerr commented on GitHub (Mar 3, 2025):

That's only for the models, what about the rest of the stuff?

<!-- gh-comment-id:2695203967 --> @hildigerr commented on GitHub (Mar 3, 2025): That's only for the models, what about the rest of the stuff?
GiteaMirror commented 2026-05-03 07:38:12 -05:00
Author
Owner
Copy Link

@abitrolly commented on GitHub (Mar 3, 2025):

@hildigerr the rest of the stuff will follow if this change works and is accepted.

<!-- gh-comment-id:2695513737 --> @abitrolly commented on GitHub (Mar 3, 2025): @hildigerr the rest of the stuff will follow if this change works and is accepted.
GiteaMirror commented 2026-05-03 07:38:14 -05:00
Author
Owner
Copy Link

@abitrolly commented on GitHub (Mar 4, 2025):

@hildigerr see, @mxyng says they don't care -https://github.com/ollama/ollama/pull/9477#issuecomment-2695754715 - so no need to waste more time on that.

<!-- gh-comment-id:2696173745 --> @abitrolly commented on GitHub (Mar 4, 2025): @hildigerr see, @mxyng says they don't care -https://github.com/ollama/ollama/pull/9477#issuecomment-2695754715 - so no need to waste more time on that.
GiteaMirror commented 2026-05-03 07:38:15 -05:00
Author
Owner
Copy Link

@hildigerr commented on GitHub (Mar 4, 2025):

@abitrolly Thank you for the update on the patch and its rejection. I'd like to clarify my perspective on this issue:

  1. Models directory: I understand why @mxyng rejected "supporting additional search paths for models", as this can already be addressed via the $OLLAMA_MODELS environment variable. This aspect of XDG compliance is not the primary concern.

  2. Other application components: The main issue is with the other application components that currently don't comply with XDG specifications. These are the areas that still need attention.

  3. Continued efforts: While your patch for models was rejected, I believe it's important to continue working towards full XDG compliance for the entire application. This includes configuration files, cache, and other data directories.

  4. Potential contribution: If I decide to keep using Ollama after comparing it with other options, I'm willing to develop and submit a comprehensive patch for full XDG compliance. This would be added to my queue of similar endeavors I'm working on for other projects.

  5. Migration considerations: One challenge in implementing XDG compliance is handling data migration for current users. If migration cannot be avoided, my approach typically involves a hierarchical notification system (developer → package maintainer → system administrator → user), along with a separate script if needed, to manage one-time migrations efficiently and to avoid bloating the project with dead code. If there is a communication breakdown, the application still works as though the user is new--who will then discover the need for migration, but won't loose any data.

I believe full XDG compliance is valuable for Linux applications, as it aligns with the principle of least astonishment by providing users with predictable and consistent behavior across different applications. This consistency improves the overall user experience and system management efficiency. I hope the project maintainers will be open to further discussions and contributions towards this goal.

<!-- gh-comment-id:2696353813 --> @hildigerr commented on GitHub (Mar 4, 2025): @abitrolly Thank you for the update on the patch and its rejection. I'd like to clarify my perspective on this issue: 1. Models directory: I understand why @mxyng rejected "supporting additional search paths **for models**", as this can already be addressed via the $OLLAMA_MODELS environment variable. This aspect of XDG compliance is not the primary concern. 2. Other application components: The main issue is with the other application components that currently don't comply with XDG specifications. These are the areas that still need attention. 3. Continued efforts: While your patch for models was rejected, I believe it's important to continue working towards full XDG compliance for the entire application. This includes configuration files, cache, and other data directories. 4. Potential contribution: If I decide to keep using Ollama after comparing it with other options, I'm willing to develop and submit a comprehensive patch for full XDG compliance. This would be added to my queue of similar endeavors I'm working on for other projects. 5. Migration considerations: One challenge in implementing XDG compliance is handling data migration for current users. If migration cannot be avoided, my approach typically involves a hierarchical notification system (developer → package maintainer → system administrator → user), along with a separate script if needed, to manage **one-time** migrations efficiently and to avoid bloating the project with dead code. If there is a communication breakdown, the application still works as though the user is new--who will then discover the need for migration, but won't loose any data. I believe full XDG compliance is valuable for Linux applications, as it aligns with the principle of least astonishment by providing users with predictable and consistent behavior across different applications. This consistency improves the overall user experience and system management efficiency. I hope the project maintainers will be open to further discussions and contributions towards this goal.
GiteaMirror commented 2026-05-03 07:38:15 -05:00
Author
Owner
Copy Link

@abitrolly commented on GitHub (Mar 4, 2025):

The main issue is with the other application components that currently don't comply with XDG specifications.

Does anybody have the checklist of these components?

<!-- gh-comment-id:2696601908 --> @abitrolly commented on GitHub (Mar 4, 2025): > The main issue is with the other application components that currently don't comply with XDG specifications. Does anybody have the checklist of these components?
GiteaMirror commented 2026-05-03 07:38:15 -05:00
Author
Owner
Copy Link

@ignamartinoli commented on GitHub (Mar 4, 2025):

@abitrolly right now I detected:

  • history
  • id_ed25519
  • id_ed25519.pub
<!-- gh-comment-id:2698178176 --> @ignamartinoli commented on GitHub (Mar 4, 2025): @abitrolly right now I detected: - [ ] history - [ ] id_ed25519 - [ ] id_ed25519.pub
GiteaMirror commented 2026-05-03 07:38:16 -05:00
Author
Owner
Copy Link

@ratnik2 commented on GitHub (Feb 25, 2026):

Any update on this?

<!-- gh-comment-id:3956778628 --> @ratnik2 commented on GitHub (Feb 25, 2026): Any update on this?
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 feature 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#62133
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?