Storage Mapping

Enterprise surveillance requires massive disk aggregation. OpenNVR is explicitly containerized to allow System Administrators to decouple the application layer from the physical storage disks.

Architecting the Data-Store

By default, OpenNVR utilizes ephemeral or standard Docker volumes. For production deployments, you must explicitly bind the container volumes to your dedicated hardware arrays (NAS, SAN, or local RAID-configured NVMe pools).

Binding Docker Volumes

You must manipulate the explicit volume mounts for both the mediamtx proxy (which handles temporary chunking) and the opennvr-core engine (which handles permanent database orchestration).

Safely halt your orchestration stack:
```
docker compose down
```

Locate and modify your core docker-compose.yml. Update the volumes array to map your exact physical path:

services:
  opennvr-core:
    volumes:
      - /mnt/enterprise_nas_array/nvr_recordings:/app/recordings
      
  mediamtx:
    volumes:
      - /mnt/enterprise_nas_array/nvr_recordings:/app/recordings

(Windows Example: D:/Surveillance/Recordings:/app/recordings)

Critical: Ensure the UNIX permissions on the physical host target directories give read/write access to the Docker daemon.
Reignite the ecosystem:
```
docker compose up -d
```

Verifying Target Writes

To ensure the NVR engine hasn’t fallen back to ephemeral storage due to an invalid mount, execute a probe directly into the running container namespace:

docker compose exec opennvr_core ls -lah /app/recordings

If your configuration is perfectly mapped, you will immediately see the subdirectories populate with correctly structured MP4 fragments.

[!CAUTION] If you bind a new empty volume to an existing production OpenNVR instance, the system will instantly lose access to the previously retained video files. Always migrate data using rsync before mounting the empty volume natively.