TL;DR

Moving Ollama models to another drive requires changing the OLLAMA_MODELS environment variable and relocating your existing model files. By default, Ollama stores models in ~/.ollama/models on Linux systems, but you can point it to any directory with sufficient space.

The fastest approach: stop the Ollama service, set OLLAMA_MODELS to your new location, move the existing models directory, then restart. For systemd-managed installations, edit /etc/systemd/system/ollama.service to add Environment=“OLLAMA_MODELS=/mnt/storage/ollama-models” under the [Service] section. After running systemctl daemon-reload and systemctl restart ollama, verify the new path with ollama list.

sudo systemctl stop ollama
sudo mkdir -p /mnt/storage/ollama-models
sudo mv ~/.ollama/models/* /mnt/storage/ollama-models/
sudo systemctl daemon-reload
sudo systemctl restart ollama

For non-systemd setups or user-level installations, add export OLLAMA_MODELS=/mnt/storage/ollama-models to your shell profile and restart your terminal session. The Ollama service will automatically create subdirectories for blobs and manifests in the new location.

Common pitfall: forgetting to update OLLAMA_MODELS before moving files results in Ollama re-downloading models to the default location. Always set the environment variable first, then move files, then restart.

If you use Open WebUI or other tools that connect to Ollama’s API on port 11434, no additional configuration is needed – they communicate via HTTP and remain unaware of where models are stored on disk. The OLLAMA_MODELS variable only affects where Ollama itself reads and writes model files.

For multi-user systems, ensure the new directory has appropriate permissions. Ollama typically runs as the ollama user, so chown -R ollama:ollama /mnt/storage/ollama-models prevents permission errors when pulling new models.

Why Move Ollama Models to Another Drive

Ollama stores models in your home directory by default, typically under ~/.ollama/models. This works fine for testing a few small models, but becomes problematic once you start building a serious local AI stack. A single 70B parameter model can consume 40GB or more of disk space, and many operators run multiple models for different tasks – code generation with CodeLlama, general chat with Llama 3, and specialized models for summarization or analysis.

Your system drive fills up quickly. Most Linux installations allocate 50-100GB for the root partition, which gets consumed by the OS, application binaries, logs, and Docker images. Adding several large language models to that mix creates storage pressure that affects system stability and performance.

Dedicated storage for AI models makes operational sense. You can mount a separate SSD or NVMe drive specifically for model storage, keeping your system partition clean. This separation also simplifies backup strategies – you can snapshot your system drive without including 200GB of model weights that you can re-download from ollama.com if needed.

Performance considerations matter too. Ollama loads model weights into memory at startup, but reads from disk during the initial load. A fast NVMe drive on a separate PCIe lane reduces model loading time compared to sharing I/O bandwidth with your system drive.

Multi-User and Homelab Scenarios

If you run Ollama as a shared service for multiple users or integrate it with Open WebUI for a team, centralizing models on network-attached storage or a dedicated data volume makes management easier. You can point multiple Ollama instances at the same model directory using the OLLAMA_MODELS environment variable, avoiding duplicate downloads across machines.

Moving models also prepares your setup for growth. Starting with a 1TB drive gives you room to experiment with different model families and quantization levels without constant cleanup.

Understanding Ollama’s Model Storage Structure

Ollama stores models in a specific directory structure that you need to understand before moving anything. By default, models live in ~/.ollama/models on Linux systems. This directory contains two key subdirectories: blobs and manifests.

The blobs directory holds the actual model weights as content-addressed files. Each blob has a SHA256 hash as its filename, like sha256-a3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855. These files can be several gigabytes each for larger models like llama3.1:70b.

The manifests directory contains JSON metadata files organized by registry, namespace, and model name. For example, manifests/registry.ollama.ai/library/llama3.1/latest points to the specific blobs that make up that model version.

Before moving models, verify what you have:

du -sh ~/.ollama/models
ls -lh ~/.ollama/models/blobs | head -n 10

This shows total storage used and lists individual blob sizes. Models share blobs when they use common layers, so moving the entire directory preserves these space-saving links.

Why the OLLAMA_MODELS Variable Matters

Ollama respects the OLLAMA_MODELS environment variable to override the default location. Setting this variable before starting the Ollama service tells it where to look for models. The service must be restarted after changing this variable for it to take effect.

Caution: If you use AI assistants to generate migration scripts, always review the commands manually. Verify that paths exist, that you have sufficient permissions, and that the destination drive has adequate free space. A typo in an rm or mv command can delete models that take hours to re-download on slower connections.

Method 1: Using OLLAMA_MODELS Environment Variable (Recommended)

The cleanest approach is to set the OLLAMA_MODELS environment variable before starting the Ollama service. This tells Ollama exactly where to store and load models without touching default system directories.

Most Linux installations run Ollama as a systemd service. Edit the service file to add the environment variable:

sudo systemctl edit ollama.service

Add these lines in the editor that opens:

[Service]
Environment="OLLAMA_MODELS=/mnt/storage/ollama-models"

Save and exit, then reload systemd and restart Ollama:

sudo systemctl daemon-reload
sudo systemctl restart ollama.service

Verify the new location is active:

systemctl show ollama.service | grep OLLAMA_MODELS

Moving Existing Models

If you already have models in the default location (typically ~/.ollama/models or /usr/share/ollama/.ollama/models), move them to your new directory:

sudo mkdir -p /mnt/storage/ollama-models
sudo mv ~/.ollama/models/* /mnt/storage/ollama-models/

Ollama will immediately recognize models in the new location. Test by listing available models:

ollama list

Setting for Manual Runs

If you run Ollama manually rather than as a service, export the variable in your shell session:

export OLLAMA_MODELS=/mnt/storage/ollama-models
ollama serve

For persistence across sessions, add the export line to your ~/.bashrc or ~/.zshrc file.

This method works reliably across Ollama versions and requires no symlinks or filesystem tricks. The service reads the variable on startup and uses that path for all model operations. When pulling new models with ollama pull llama3.2, they download directly to your specified drive.

If you already have models downloaded and want to avoid re-downloading several gigabytes, symbolic links provide a transparent solution. This approach keeps Ollama’s default paths intact while storing actual model files on your target drive.

First, stop the Ollama service to prevent file access conflicts:

sudo systemctl stop ollama

Move your existing models to the new location and create the symbolic link:

sudo mv ~/.ollama/models /mnt/storage/ollama-models
ln -s /mnt/storage/ollama-models ~/.ollama/models

For system-wide installations, the default path is typically /usr/share/ollama/.ollama/models. Adjust accordingly:

sudo mv /usr/share/ollama/.ollama/models /mnt/storage/ollama-models
sudo ln -s /mnt/storage/ollama-models /usr/share/ollama/.ollama/models

Verify the symbolic link points correctly:

ls -la ~/.ollama/models
# Should show: models -> /mnt/storage/ollama-models

Restart Ollama and confirm models are accessible:

sudo systemctl start ollama
ollama list

Validating Model Integrity

After moving models, test inference to ensure files transferred correctly:

ollama run llama3.2:3b "Explain symbolic links in one sentence"

If you encounter errors about missing files, check that your symbolic link target has correct permissions. The ollama user needs read access to the destination directory.

Caution with AI-Generated Migration Scripts

When using LLMs to generate file migration commands, always verify the output matches your actual directory structure. Models like llama3.2 or mistral can suggest helpful scripts, but they may reference outdated paths or assume different installation methods. Run ollama show <model> to verify each model’s location before executing any automated migration commands. Test symbolic links with a single small model before moving your entire collection.

Method 3: Moving Models on Docker/Podman Deployments

When running Ollama in containers, you control the model storage location through volume mounts rather than environment variables. The container filesystem is ephemeral, so proper volume configuration ensures your models persist across container restarts and remain accessible from your chosen drive.

For Docker deployments, bind mount your target directory to the container’s model path. The standard Ollama container expects models at /root/.ollama/models:

docker run -d \
  --name ollama \
  --gpus all \
  -v /mnt/storage/ollama-models:/root/.ollama/models \
  -p 11434:11434 \
  ollama/ollama

This mounts /mnt/storage/ollama-models from your host system directly into the container. Models pulled via docker exec ollama ollama pull llama3.2 will write to your mounted drive immediately.

Podman Rootless Considerations

Podman handles user namespaces differently. For rootless containers, ensure your mount point has appropriate permissions:

mkdir -p /mnt/storage/ollama-models
podman run -d \
  --name ollama \
  --device nvidia.com/gpu=all \
  -v /mnt/storage/ollama-models:/root/.ollama/models:Z \
  -p 11434:11434 \
  docker.io/ollama/ollama

The :Z flag relabels the volume for SELinux contexts. Without it, the container may fail to write models on RHEL-based systems.

Docker Compose Example

For persistent deployments, define volumes in your compose file:

services:
  ollama:
    image: ollama/ollama
    volumes:
      - /mnt/storage/ollama-models:/root/.ollama/models
    ports:
      - "11434:11434"
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]

Verify the mount with docker exec ollama ls -lh /root/.ollama/models. If you see your existing model files, the mount succeeded. Always test model loading after reconfiguration to catch permission issues before production use.

Installation and Configuration Steps

Before moving any model files, stop the Ollama service to prevent file corruption or lock conflicts. On systemd-based Linux distributions, use:

sudo systemctl stop ollama

Verify the service has stopped completely:

sudo systemctl status ollama

Create the New Model Directory

Choose your target drive and create a directory with appropriate permissions. For this example, we’ll use a mounted drive at /mnt/storage:

sudo mkdir -p /mnt/storage/ollama-models
sudo chown -R $(whoami):$(whoami) /mnt/storage/ollama-models

Move Existing Models

Copy all models from the default location to your new directory. The default path is typically ~/.ollama/models:

rsync -av --progress ~/.ollama/models/ /mnt/storage/ollama-models/

Using rsync with the --progress flag lets you monitor the transfer, which is helpful since model files can be several gigabytes each.

Configure the OLLAMA_MODELS Environment Variable

Set the OLLAMA_MODELS environment variable to point to your new location. For systemd services, create an override file:

sudo mkdir -p /etc/systemd/system/ollama.service.d
sudo tee /etc/systemd/system/ollama.service.d/override.conf > /dev/null <<EOF
[Service]
Environment="OLLAMA_MODELS=/mnt/storage/ollama-models"
EOF

Reload systemd and restart Ollama:

sudo systemctl daemon-reload
sudo systemctl start ollama

Verify the Configuration

Test that Ollama recognizes your moved models:

ollama list

You should see all previously downloaded models. Try running one to confirm:

ollama run llama3.2

If models appear missing, double-check the OLLAMA_MODELS path and directory permissions. Once verified, you can safely remove the old model directory to reclaim space:

rm -rf ~/.ollama/models