Date: April 30, 2026 | Tags: homelab, NAS, NFS, QNAP, Ollama, OpenWebUI, Proxmox, Docker

Summary

Successfully completed the migration of both Ollama model data and OpenWebUI application data from local VM storage to a QNAP NAS (TS-453D) via NFS. This involved diagnosing and fixing a broken NAS mount configuration, correcting NFS export issues on the QNAP, and performing live data migrations with minimal downtime.

Background

The Ollama AI stack (Ollama + Open WebUI) runs on VM 205 (IP: 10.10.20.39) inside a Proxmox VE cluster (host IP: 10.10.20.252). The stack was originally configured to store both model weights and OpenWebUI application data on a NAS via NFS mounts, but at some point the NAS mounts broke, causing the stack to fail. A previous workaround switched the Docker volumes to local paths to restore service, but the goal was always to move the data back to the NAS for centralized storage and backup.

Phase 1: NAS Mount Investigation & Diagnosis

The Problem

The NFS mounts on VM 205 were broken. The original /etc/fstab had:

10.10.20.6:/volume1/ollama-models  /mnt/nas/ollama-models  nfs defaults,_netdev,nofail,x-systemd.automount 0 0
10.10.20.6:/volume1/openwebui-data /mnt/nas/openwebui-data nfs defaults,_netdev,nofail,x-systemd.automount 0 0

Root Cause Analysis

Two distinct issues were found:

1. Wrong NAS IP in fstab: The fstab pointed to 10.10.20.6, but the actual NAS IP is 10.10.20.4. Pinging 10.10.20.6 returned 100% packet loss. Pinging 10.10.20.4 succeeded with <1ms latency.
2. Wrong path format: The fstab used Synology-style paths (/volume1/...) but the NAS is a QNAP TS-453D running QTS 5.2.3. QNAP uses different NFS export paths.

NAS Discovery

Open Ports on NAS

NFS Export Issue

Even though the NFS service was running (confirmed via rpcinfo showing NFS v2/3/4 on TCP/UDP port 2049), showmount -e 10.10.20.4 returned an empty export list. SSH into the QNAP revealed the /etc/exports file contained an invalid NFS option read-wr instead of rw, causing exportfs to silently fail with no active exports.

Phase 2: NFS Export Fix

1. SSH into QNAP NAS: ssh jczaldivar@10.10.20.4
2. Backup original exports: sudo cp /etc/exports /etc/exports.bak
3. Write corrected exports file with proper rw options (replacing invalid read-wr)
4. Reload NFS exports: sudo exportfs -ra
5. Verify exports active: sudo exportfs -v confirmed both shares exported with rw
6. Verify from Proxmox: showmount -e 10.10.20.4 now listed both /ollama-models and /openwebui-data

Corrected /etc/exports on QNAP:

/share/CACHEDEV1_DATA/ollama-models *(rw,async,no_subtree_check,no_root_squash,insecure) 10.10.20.0/24(rw,async,no_subtree_check,no_root_squash,insecure)
/share/CACHEDEV1_DATA/openwebui-data *(rw,async,no_subtree_check,no_root_squash,insecure) 10.10.20.0/24(rw,async,no_subtree_check,no_root_squash,insecure)

Phase 3: Ollama Models Migration

The NAS already contained a full set of Ollama models from a previous configuration (9.8 GB):

The NFS share was mounted on VM 205 at /mnt/nas/ollama-models, docker-compose.yml was updated to use the NAS path, and the container was recreated, immediately picking up all 4 models from the NAS.

Phase 4: OpenWebUI Data Migration

1. Mounted NFS share: mount -t nfs 10.10.20.4:/openwebui-data /mnt/nas/openwebui-data
2. Stopped open-webui container for data consistency
3. Rsync’d local data to NAS: rsync -av --delete – transferred 934 MB at ~110 MB/sec
4. Updated docker-compose.yml volume to NAS path
5. Updated /etc/fstab with correct NAS IP (10.10.20.4) and paths
6. Restarted all containers – both recreated with NAS mounts and running healthy

Verification Results

Current Network Topology

Infrastructure Overview

All devices are on the 10.10.20.0/24 subnet.

Network Connectivity Map

NAS Storage Layout

Data Flow

Request path: User Browser -> HTTP:3000 -> Open WebUI (VM 205 container) -> HTTP:11434 (docker network) -> Ollama (VM 205 container) -> GPU Inference (NVIDIA passthrough)

Storage path: Ollama reads/writes model data from /root/.ollama inside the container, which maps to /mnt/nas/ollama-models on VM 205, which is an NFS mount to 10.10.20.4:/ollama-models on the QNAP NAS (internal path: /share/CACHEDEV1_DATA/ollama-models).

WebUI data path: Open WebUI reads/writes app data from /app/backend/data inside the container, which maps to /mnt/nas/openwebui-data on VM 205, which is an NFS mount to 10.10.20.4:/openwebui-data on the QNAP NAS (internal path: /share/CACHEDEV1_DATA/openwebui-data).

Key Configuration Files

VM 205 – /etc/fstab (corrected):

10.10.20.4:/ollama-models  /mnt/nas/ollama-models  nfs defaults,_netdev,nofail,x-systemd.automount 0 0
10.10.20.4:/openwebui-data /mnt/nas/openwebui-data nfs defaults,_netdev,nofail,x-systemd.automount 0 0

VM 205 – docker-compose.yml:

services:
  ollama:
    image: ollama/ollama:latest
    container_name: ollama
    ports: ["11434:11434"]
    volumes: ["/mnt/nas/ollama-models:/root/.ollama"]
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]
  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    container_name: open-webui
    ports: ["3000:8080"]
    environment: ["OLLAMA_BASE_URI=http://ollama:11434"]
    volumes: ["/mnt/nas/openwebui-data:/app/backend/data"]
    depends_on: [ollama]

Lessons Learned

1. Always verify the NAS IP: The fstab had a stale IP (10.10.20.6) that no longer existed. The actual NAS was at 10.10.20.4.
2. QNAP != Synology paths: Synology uses /volume1/share-name, QNAP uses /share/CACHEDEV1_DATA/share-name internally and exports as /share-name.
3. Check /etc/exports directly: The QNAP web UI showed NFS enabled, but the underlying exports file had an invalid option (read-wr instead of rw), causing silent export failures.
4. showmount -e is your friend: Quick way to verify NFS exports are actually published.
5. Keep local backups: The docker-compose.yml.bak file preserved the original NAS-based config for easy restoration.

Status: Complete

Both Ollama models (9.8 GB, 4 models) and OpenWebUI data (890 MB) are now running from the QNAP NAS via NFS. The stack is fully operational with all 4 models accessible and OpenWebUI responding healthy on port 3000. Migration completed April 30, 2026.