Frigate on a Mini PC with NAS Recording and Home Assistant

Quick Summary (TL;DR):
For a reliable Frigate and Home Assistant installation, run Frigate on a wired Intel mini PCAliExpress price, keep its configuration and SQLite database on the mini PCAliExpress price’s local SSD, and use the NASAliExpress price only for the large /media/frigate recording library. An NFS or SMB recording share is supported, but it introduces a dependency: if the NASAliExpress price or network fails, recording can stop even while object detection and Home Assistant remain online. Do not allow Docker to start against an unmounted local directory masquerading as the NASAliExpress price share. Verify the mount before every start, monitor its health, and test what happens when the NAS is switched off. Intel VAAPI/QSV video decoding and OpenVINO detection can reduce host CPU load, but performance depends on camera streams, the model and driver support. Frigate’s own planning guidance generally prefers local recording storage for the best reliability; choose NAS recording because its capacity and administration benefits justify that trade-off, not because it is inherently more resilient.

What this architecture does — and what it does not

This guide is about separating Frigate compute from its recording storage and linking the result to Home Assistant. It is not another camera-count buying guide or a generic NAS review. We assume you already have or plan to buy IP cameras with RTSP feeds, a mini PC capable of running Docker, and a NAS that can expose a dedicated NFS or SMB share. The commands are reference configurations, not a claim that we have tested your particular NAS firmware, camera model or mini-PC BIOS.

PoE IP cameras ── managed PoE switch ── LAN ── Intel mini PC
                                          │   ├── Frigate container
                                          │   ├── local SSD: /config + SQLite
                                          │   └── /tmp/cache in RAM
                                          │
                                          ├── NAS: NFS/SMB recording share
                                          │       └── /media/frigate
                                          │
                                          └── Home Assistant + MQTT broker
                                                  └── events, cameras, automations

Frigate receives camera video and decides which recording segments to retain. The NAS provides capacity, snapshots and storage administration, but does not run object detection in this layout. Home Assistant consumes Frigate entities and events through the official integration; it does not need to mount the Frigate recording share itself.

Component	Runs where	Primary responsibility	Failure consequence
IP cameras	Camera VLAN / PoE switch	Supply record and detect streams	Affected camera goes offline
Frigate + decoder + detector	Mini PC	Ingest, motion, inference, retention	Detection and recording stop
SQLite + Frigate configuration	Mini-PC local SSD	Recording index, settings, state	Loss can orphan recordings
Media archive	NAS shared folder	Large retained video and snapshots	Recordings may stop; no automatic fallback
MQTT broker	Home Assistant host or another always-on server	Event transport	Many HA entities/events become unavailable
Home Assistant	Separate host or VM	Notifications and automations	Frigate can continue recording independently

When a mini PC plus NAS is better than a NAS-only NVR

The separation is attractive when the NAS already holds substantial storage, its CPU lacks suitable video decoding, or you want to upgrade the NVR host without migrating the array. It also lets Home Assistant stay on its own machine. However, Frigate depends on both boxes for recording: a NAS firmware reboot, switch failure or lost NFS session can interrupt the archive. For critical continuous evidence, a mini PC with a local surveillance drive, or a dedicated NVR with local disks, is a more fault-tolerant starting point.

Deployment	Strength	Weakness	Choose when
Mini PC + NAS live recording	Flexible CPU and disk upgrades; NAS capacity	Two-device and network dependency	You can monitor the NAS and tolerate a recording interruption
Mini PC + local recording HDD/SSD	Records during NAS maintenance	Limited internal bays; local capacity cost	Continuous footage matters most
Frigate on a capable NAS	One physical box and local media paths	GPU access and storage load share the NAS	Exact NAS supports required decoding and containers
Mini PC local recording + scheduled off-host exports	Local capture plus independent copies	Extra storage and workflow to maintain	You want recovery copies without live NFS dependency

For the broader compute-versus-storage trade-off, see our Mini PC Plus NAS vs NAS-Only Home Server guide. The architecture here has a different emphasis: recording integrity, media-path behaviour and outage recovery.

Choose hardware from the video pipeline, not just camera count

Frigate uses video decoding, motion processing, neural inference and disk writing. These are different workloads. Intel integrated graphics can decode supported video and run an OpenVINO detector; that does not mean every Intel mini PC supports every codec or model. The exact host kernel, iGPU, drivers, available RAM, camera bitrate and scene activity all matter. Frigate’s current hardware guidance covers N100/N150 and newer Intel systems, with documented limitations and model-specific examples.

Build variable	Sensible initial decision	Verify rather than assume
Mini-PC CPU	Recent Intel x86 with supported graphics and AVX2	Exact processor, Frigate support, BIOS, Linux kernel
RAM	8GB for modest setups; 16GB for useful headroom	Camera count, enrichments, tmpfs and host workloads
Local SSD	Keep OS, Compose, /config and database here	SMART health, spare space, backups and write endurance
Video decoding	Use Intel VAAPI where supported	Render node, driver, H.264/H.265 profile, GPU utilisation
Object detection	Start with a supported OpenVINO model	Actual detector device, model path and busy-scene queue
Network	Wired Gigabit LAN is usually enough for typical homes	Camera traffic + NAS writes + live streams + other LAN load
NAS disks	Size by bitrate and retention, not camera megapixels alone	Usable capacity, filesystem, continuous writes, backup policy

For four, eight or sixteen cameras, see Best Frigate Hardware for 4, 8 or 16 IP Cameras. That guide focuses on hardware selection. Here we assume a host has been chosen and explain how to connect it to a recording NAS without introducing silent failure.

Record the main stream; detect on a lighter stream

Most useful IP cameras offer a high-quality main stream and a lower-resolution substream. Assign the main stream to record and the substream to detect. Frigate records source video segments without re-encoding them, so the record stream’s bitrate drives NAS capacity. Detection frames are decoded; using a suitable lower-resolution feed saves GPU and CPU work. The current Add Camera Wizard can discover and configure many cameras automatically, so use it before hand-editing RTSP URLs.

Camera feed	Example only	Frigate role	What it changes
Main stream	2560×1440 H.264, camera-defined bitrate	record	Retained footage detail and disk consumption
Substream	640×360 at 5fps, if camera supports it	detect	Decode workload and object-detection detail
go2rtc restream	RTSP from Frigate host port 8554	live viewing / optional input	Can avoid extra direct connections to cameras
Audio feed	Camera-dependent	audio, if enabled	Additional FFmpeg processing and compatibility needs

Do not force a 640×360 stream when it cannot resolve the objects you care about. A distant driveway may need a higher-resolution detect feed; a close front door may not. Similarly, browser support for H.265 recording playback varies. Start with camera-native H.264 if broad browser and Home Assistant compatibility matters.

Calculate NAS capacity before configuring retention

For constant average bitrate, decimal GB/day per camera ≈ Mbps × 10.8. Multiply by the number of cameras and retained days. This is a unit conversion, not a measured camera benchmark. Actual variable-bit-rate cameras can generate more or less data depending on movement, lighting, compression, audio and night-time noise.

GB/day/camera = (average Mbps × 1,000,000 ÷ 8 × 86,400) ÷ 1,000,000,000
              = average Mbps × 10.8

Example: 6 cameras × 4 Mbps × 10.8 × 14 days
       = 3,628.8 GB ≈ 3.63 TB of video

Add room for snapshots, exports, filesystem overhead and growth.

Illustrative cameras × 4Mbps each	Total average video Mbps	7 days continuous	14 days continuous	30 days continuous
4	16Mbps	1.21TB	2.42TB	5.18TB
6	24Mbps	1.81TB	3.63TB	7.78TB
8	32Mbps	2.42TB	4.84TB	10.37TB
12	48Mbps	3.63TB	7.26TB	15.55TB

The table assumes 4Mbps per camera continuously. It does not predict what an event-only policy will use. Event retention depends on how often each view contains motion or objects; a quiet garden and a busy road are not interchangeable. Check real camera bitrate and retained-segment growth after a week, then set a sensible storage quota and warning threshold. Keep the surveillance share separate from family files so Frigate’s emergency space reclamation cannot be distorted by unrelated usage.

Understand Frigate storage paths before mounting a NAS

The distinction between /config, /tmp/cache and /media/frigate is critical. Frigate writes new recording segments to a temporary cache before moving eligible segments into the media library. Its SQLite database normally lives at /config/frigate.db and indexes the recordings. The Frigate documentation warns that SQLite on NFS/SMB can cause locking and corruption problems. Keep the whole /config directory on a local SSD and back it up independently; do not put it inside the NAS media mount.

Container path	Storage type	Reason	Do not do this
/config	Local persistent SSD	Config, database and state	Do not run SQLite directly from SMB/NFS
/tmp/cache	RAM-backed tmpfs	Short-lived recording segments	Do not confuse it with long-term archive
/dev/shm	Container shared memory	Decoded frame buffers	Do not blindly mount /dev/shm from host
/media/frigate	Dedicated NAS mount or local disk	Recordings, snapshots, clips and exports	Do not point at unverified empty host directory

Frigate measures the capacity of the filesystem visible at /media/frigate. If your network share is absent and the container binds an ordinary local folder, it can start filling the mini PC’s OS SSD while appearing to record normally. Docker’s long-form bind syntax can prevent creating a missing host path, but it cannot by itself prove that an existing directory is still an NFS mount. That requires an explicit mount check and reliable start ordering.

NFS or SMB for Frigate recording?

Property	NFS on a Linux mini PC	SMB/CIFS on a Linux mini PC
Typical fit	Straightforward Unix/Linux NAS export	Convenient when NAS already exposes SMB shares
Authentication	Export permissions; UID/GID and NFS version matter	NAS user, credentials file and mount options
Linux client	nfs-common on Debian/Ubuntu	cifs-utils on Debian/Ubuntu
Security	Restrict allowed client IP and camera/server VLANs	Dedicated least-privilege NAS account
Database suitability	Not recommended for Frigate SQLite	Not recommended for Frigate SQLite
Failure mode	Network latency, stale mounts, NAS reboot	Network latency, reconnect and permission issues

Neither protocol magically turns a NAS into local storage. Frigate’s planning documentation explicitly supports network recording but recommends local media for the most reliable setup. For a Linux-only host and NAS, NFS is often easier to maintain; choose SMB when that is the better-supported, audited share on your particular NAS. Do not expose either protocol to the internet. The following walkthrough uses NFS; the container’s mount path is identical for SMB once the host mount is working.

Create a dedicated NAS share and mount it on Linux

1. Create a dedicated NAS shared folder such as frigate-media with sufficient quota and retention capacity. Keep it separate from general family data.
2. Enable NFS on the NAS. Permit only the mini PC’s static/reserved IP address, not an entire untrusted subnet; grant the minimum necessary read/write access.
3. Record the actual export path shown by your NAS. On Synology this is commonly /volume1/SHARE_NAME, but the volume and path are not universal.
4. On the mini PC, install the Linux NFS client package and create an empty local mount point. Confirm NAS hostname/IP reachability.
5. Mount the share manually, verify its source and filesystem type, then perform a controlled write/read test before using Docker.

sudo apt update && sudo apt install -y nfs-common
sudo mkdir -p /mnt/frigate-media

# Replace the NAS address and exported path with the REAL values.
sudo mount -t nfs -o vers=4 192.168.20.10:/volume1/frigate-media /mnt/frigate-media

findmnt -T /mnt/frigate-media -o TARGET,SOURCE,FSTYPE,OPTIONS
df -h /mnt/frigate-media

# Only if the share permissions allow this test:
printf "Frigate mount check\n" | sudo tee /mnt/frigate-media/.frigate-write-test
sudo cat /mnt/frigate-media/.frigate-write-test
sudo rm /mnt/frigate-media/.frigate-write-test

If NFSv4 is not available, use the version and export path that your NAS actually supports; do not force vers=4 without checking. Synology’s current NFS instructions show where to enable the service, create client-specific permissions and obtain the export path. On QNAP, UGREEN, TrueNAS or another NAS, use that vendor’s corresponding file-service settings. Avoid mapping every user to an administrator just to make a permission error disappear.

Make the NAS mount persistent — without hiding a failure

For a conventional Linux host, add a tested NFS entry to /etc/fstab or use a systemd mount unit. The line below is an illustration for a trusted LAN; choose mount options with your NAS vendor’s guidance. The _netdev flag identifies a network filesystem. nofail allows the host to boot when the NAS is absent, but it does not mean Frigate should start recording to a local directory. Pair it with an explicit guard.

# Example /etc/fstab entry; replace IP and export path:
192.168.20.10:/volume1/frigate-media /mnt/frigate-media nfs rw,_netdev,nofail 0 0

# After saving fstab:
sudo systemctl daemon-reload
sudo mount /mnt/frigate-media
findmnt -rn -M /mnt/frigate-media -t nfs,nfs4 >/dev/null \n  || { echo "NAS share NOT mounted; do not start Frigate"; exit 1; }

The mount check above verifies that the exact mount point is backed by NFS/NFSv4 rather than merely existing as a directory. Make this a prerequisite of your Compose startup script or systemd service. A check only at startup is not continuous protection: a share can fail later. Add ongoing availability alerts, and decide whether the container should stop, restart or remain available for live viewing while recording is interrupted. Test that decision deliberately.

Docker Compose: local database, NAS media, Intel GPU

This is a minimal reference Compose file for a Linux mini PC running Docker Compose. It follows the official Frigate installation structure and deliberately avoids publishing unauthenticated port 5000. The NAS is mounted by the host first; Docker then bind-mounts that path. Replace /srv/frigate/config with a real local-SSD directory. Verify the GPU device path with ls /dev/dri and omit the device mapping if your host does not support it.

services:
  frigate:
    container_name: frigate
    image: ghcr.io/blakeblackshear/frigate:stable
    restart: unless-stopped
    stop_grace_period: 30s
    shm_size: "256mb"  # Recalculate for YOUR detect streams
    devices:
      - /dev/dri/renderD128:/dev/dri/renderD128  # Verify host path
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - type: bind
        source: /srv/frigate/config
        target: /config
        bind:
          create_host_path: false
      - type: bind
        source: /mnt/frigate-media
        target: /media/frigate
        bind:
          create_host_path: false
      - type: tmpfs
        target: /tmp/cache
        tmpfs:
          size: 1000000000
    ports:
      - "8971:8971"       # Authenticated Frigate UI/API (no TLS)
      - "8554:8554"       # RTSP restream, restrict LAN access
      - "8555:8555/tcp"   # WebRTC
      - "8555:8555/udp"
    environment:
      TZ: Europe/London

The shm_size value is an example, not a universal requirement. Frigate supplies a shared-memory calculator based on detect-stream dimensions and camera count. The 1GB tmpfs is also an example: it consumes memory and can fill independently of the NAS. Budget RAM for the operating system, detector, shared memory and cache together. Current Frigate builds may use a camera wizard and UI settings; a minimal Compose file does not need to hard-code every camera.

A correct create_host_path: false setting rejects a missing source path, but an existing empty /mnt/frigate-media directory is still valid to Docker. Always run the NFS mount guard before docker compose up -d, and wire it into unattended service startup. Docker restart: unless-stopped does not itself recheck the NFS source after a reboot.

Start Frigate only after verifying the share

# Create local config folder on the MINI PC SSD, not the NAS.
sudo mkdir -p /srv/frigate/config

# Verify the mount, not just the directory:
findmnt -rn -M /mnt/frigate-media -t nfs,nfs4 >/dev/null \n  || { echo "STOP: NAS recording mount is missing"; exit 1; }

# From the directory containing compose.yaml:
docker compose config --quiet
docker compose up -d
docker exec frigate df -h /media/frigate
docker logs --tail 100 frigate

Check that docker exec frigate df -h /media/frigate reports the NAS filesystem and expected capacity. If it reports the mini PC’s SSD, stop Frigate and fix the mount; do not assume the recordings are safely on the NAS. A basic startup script should return a non-zero exit code when the mount check fails, and any systemd service launching that script should require the mount to be present. For unattended restarts, consider a dedicated systemd unit with RequiresMountsFor=/mnt/frigate-media and a pre-start findmnt guard; validate it on your distribution rather than copying a generic unit blindly.

Configure the camera, hardware decoder and detector

The safest first-run sequence is to open the Frigate UI on port 8971, complete the initial account setup, add one camera using the Add Camera Wizard, and confirm both live view and recording before adding the rest. The following is a deliberately small config.yml illustration for a camera with separate RTSP main and substreams. Replace the URLs, MQTT address, credentials and camera paths with those supplied by your actual hardware.

mqtt:
  enabled: true
  host: 192.168.20.30  # Your MQTT broker
  user: frigate_user
  password: CHANGE_ME_IN_A_PRIVATE_CONFIG

ffmpeg:
  hwaccel_args: preset-vaapi

detectors:
  ov:
    type: openvino
    device: GPU  # Requires a supported, accessible Intel GPU

record:
  enabled: true
  continuous:
    days: 1
  motion:
    days: 7
  alerts:
    retain:
      days: 14
      mode: all
  detections:
    retain:
      days: 14
      mode: all

cameras:
  front_door:
    ffmpeg:
      inputs:
        - path: rtsp://USER:PASSWORD@192.168.30.11:554/MAIN_STREAM
          roles: [record]
        - path: rtsp://USER:PASSWORD@192.168.30.11:554/SUB_STREAM
          roles: [detect]
    detect:
      enabled: true
      fps: 5

Important: The camera URLs above are placeholders, not real endpoints. Do not paste actual RTSP passwords into public configuration repositories or screenshots. Use Frigate-supported environment-variable references or protected secrets where practical. On a current Frigate release, detector and model setup can also be managed in the UI; verify the chosen OpenVINO model and its compatibility rather than assuming every GPU can run every model. The YAML uses current continuous, motion, alerts and detections retention keys, not older record.retain.days examples from outdated guides.

For an Intel iGPU, preset-vaapi is a useful starting decoder preset for supported H.264/H.265 streams. Intel QSV presets are alternatives when the exact codec and driver support them. Video decoding and object detection are separate: passing /dev/dri/renderD128 makes the GPU available, but the OpenVINO detector still needs an appropriate model and configuration. If the device node differs, map the actual render device; do not guess that renderD128 always points to the right GPU.

Home Assistant integration: MQTT first, then Frigate

Install and configure the MQTT integration in Home Assistant and point Frigate at the same MQTT broker. The official Frigate integration is installed through HACS, then added in Home Assistant under Settings → Devices & Services. Its URL should reach the mini PC’s Frigate API. On a trusted internal network, the integration can use port 5000 if deliberately exposed to the Home Assistant host; alternatively, the authenticated 8971 endpoint can be used as supported by the current integration. Avoid opening port 5000 broadly because it is unauthenticated.

1. Verify the MQTT broker is reachable from both Home Assistant and Frigate; use a dedicated broker account and strong password.
2. Enable MQTT in Frigate and check its logs for connection errors.
3. Install the Frigate integration in HACS, restart Home Assistant and add the integration using the reachable Frigate URL.
4. Confirm camera, motion/object sensors, recording switches and recent detections appear as expected.
5. For live viewing, confirm the Home Assistant host or browser can reach the Frigate RTSP restream on port 8554; add the optional camera card only if it suits your dashboard.

Home Assistant does not become the recording engine: Frigate keeps processing streams even if Home Assistant is down, provided the mini PC, cameras and storage remain available. Conversely, if MQTT is unavailable, Home Assistant automations depending on Frigate entities may stop updating even while Frigate’s own UI and recording continue. Test these failure modes separately.

Network layout: camera VLAN, NAS and Home Assistant

Traffic flow	Typical requirement	Security decision
Camera → Frigate	RTSP from camera to mini PC	Permit only required camera IP/port
Mini PC → NAS	NFS or SMB writes to dedicated share	Allow only NVR host; no internet exposure
Mini PC → MQTT	Broker TCP connection	Dedicated credentials; firewall by host
Home Assistant → Frigate	API and optional RTSP restream	Prefer authenticated endpoint; restrict 5000/8554
User browser → Frigate	Authenticated UI on 8971	LAN/VPN or TLS reverse proxy; no public raw exposure
PoE switch → cameras	Power and wired Ethernet	Size per-camera peak watts and total budget

A dedicated camera VLAN is useful, but it does not automatically isolate a NAS or MQTT broker. Implement explicit inter-VLAN firewall rules for the flows above. Use fixed DHCP reservations for the NAS, mini PC and cameras so your mount and stream configuration do not change unexpectedly. A managed PoE switch is valuable for port status, VLANs and a verifiable power budget; a faster 2.5GbE uplink is optional for most small NVR installations.

If six cameras each send a 4Mbps main stream to Frigate, the incoming main-stream payload is approximately 24Mbps. Recording that footage to the NAS adds approximately 24Mbps of outgoing payload on the mini PC’s network connection, plus substreams, protocol overhead and any viewers. This is not a 48Mbps NAS write rate: the NAS receives roughly the retained main-stream payload. A healthy 1GbE LAN has substantial bandwidth headroom for this illustrative case, although latency, packet loss, switch overload and NAS disk performance can still cause trouble.

Retention policies: choose what you can afford to lose

Frigate currently distinguishes continuous retention, motion retention, and alert/detection retention. For example, you might retain one day of continuous footage, seven days of motion footage and fourteen days of relevant alerts. The largest applicable retention policy governs each segment; exports are managed separately. This is useful when NAS capacity is limited, but it is not equivalent to keeping fourteen days of complete footage.

Policy	What is kept	Storage effect	Operational warning
Continuous 24/7	Every recording segment for selected days	Highest, predictable baseline	Capacity grows even in quiet scenes
Motion retention	Segments with motion	Highly scene-dependent	Wind, rain, shadows and timestamps can fill storage
Alert/detection retention	Segments overlapping classified activity	Keeps important events longer	Object detection quality affects what survives
Exported evidence	Manually exported recordings	Separate from ordinary retention	Protect and back up important exports separately

Frigate can delete old footage when free space becomes critically low, regardless of your preferred retention window. Do not rely on that emergency cleanup as capacity planning. Set NAS quotas, track real used space and alert early. Also check NAS snapshot retention: snapshots of a high-churn surveillance share can consume unexpectedly large additional capacity, even when Frigate itself has deleted older segments.

NAS outage behaviour: the failure test that matters most

Before trusting the system, simulate a NAS outage during a controlled maintenance window. Confirm exactly what Frigate does when its media path becomes unavailable. Depending on NFS/SMB behaviour, writes can block, fail or produce FFmpeg/recording errors; do not promise that Frigate will buffer an entire outage in RAM. The tmpfs cache is short-lived and finite, not an automatic failover recording disk. Some live views and detections may continue, but this must be observed rather than assumed.

1. Confirm the recording share is mounted and a recent segment is visible in Frigate History.
2. Disconnect the NAS network interface or stop the NAS share in a planned test; note exact start time.
3. Watch Frigate logs, recording status, tmpfs usage, CPU and whether new recordings are retained.
4. Restore the NAS share and verify the host mount, container filesystem and permissions before resuming normal service.
5. Review the timeline for gaps and verify new recordings are written to the NAS, not the mini PC’s root filesystem.
6. Document the recovery procedure, including how you restart Frigate after a stale mount and how you notify the household of recording loss.

If uninterrupted recording through NAS maintenance is mandatory, change the architecture: record locally on a dedicated disk, then copy supported exports or backups off-host. Do not casually move or delete Frigate-managed recording files with cron/rsync while the service is active; the SQLite index can become inconsistent with the media directory. The project documents media reconciliation for recovery, not as a substitute for a coherent storage design.

Back up the right data — and test restores

A RAID array is not a backup, and a NAS snapshot is not an off-site copy. Protect the local /srv/frigate/config directory, especially the database, secrets and configuration. Stop Frigate or use a consistent SQLite backup mechanism before copying its database; a simple live file copy may not capture a consistent state. Record the Docker Compose file, version/tag, camera firmware settings, MQTT credentials storage and NAS mount configuration. For critical evidence, export important recordings to a separate backup destination with access controls and a retention policy.

Data	Primary location	Protection method	Restore test
Frigate YAML/settings	Mini-PC local SSD	Versioned, encrypted backup	Recreate container and load settings
SQLite database	Mini-PC local SSD	Consistent backup with Frigate stopped or SQLite-aware tooling	Check events and recording index
Routine retained video	NAS share	RAID/snapshots where appropriate; capacity monitoring	Play footage from representative dates
Critical incident exports	Separate protected folder / off-site copy	Immutable or offline copy when appropriate	Open file on independent machine
Docker Compose + mount setup	Local host plus config backup	Text backup with sensitive values protected	Rebuild after fresh OS install

A restore rehearsal should include rebuilding the mini PC on a spare SSD or VM, reattaching the same NAS share, restoring the database and verifying that the recording timeline matches actual files. A restored /config with an empty media folder may show missing recordings; media without the matching database may appear orphaned. Frigate documents recovery and media-sync tooling, but that is a last resort, not a reason to neglect consistent backups.

Troubleshooting: common symptoms and precise checks

Symptom	Likely cause	First check
NAS shows less capacity than expected	Wrong filesystem mounted at /media/frigate	docker exec frigate df -h /media/frigate
Recordings disappear during NAS reboot	NFS/SMB connection lost or stale	findmnt, Frigate logs and NAS export status
Database is locked	SQLite on network storage or multiple writers	Confirm /config is local SSD and only one instance writes DB
No space left on device despite free NAS space	tmpfs cache or /dev/shm full	df -h for each container path
Frigate container crashes with Bus error	Insufficient /dev/shm	Recalculate shm_size for detect streams
High CPU, low GPU activity	Decoder device mapping/preset incorrect	ls /dev/dri, FFmpeg logs, GPU stats
No detections in Home Assistant	MQTT not configured or integration unavailable	Broker logs, Frigate MQTT settings, HA integration
Live view fails in HA but works in Frigate	RTSP port 8554 blocked or go2rtc mapping mismatch	Firewall and go2rtc stream names
Recordings use far more storage than expected	Bitrate/retention/snapshots differ from assumptions	Camera bitrate, Frigate policy, NAS snapshots

Start with filesystem truth, not the Frigate dashboard alone. df reports filesystem space; Frigate’s recordings figure is calculated from indexed recording segments. Deleting media files manually can leave the two inconsistent. For recurring NAS write errors, also check switch port counters, NAS I/O latency, disk health, quota and network mount logs before blaming Frigate.

Commissioning checklist for a dependable installation

• The mini PC’s local SSD contains Frigate configuration and SQLite; the NAS contains only media.
• The exact NFS/SMB mount is verified before Frigate starts and after every host reboot.
• Docker sees the expected NAS filesystem capacity, not the local root filesystem.
• Each camera has correct detect/record roles and known average recording bitrate.
• Intel GPU access, decoder preset and OpenVINO model are checked under real activity.
• Home Assistant’s MQTT broker and Frigate integration are working without public unauthenticated ports.
• Recording retention fits usable NAS capacity, with quota and low-space alerts.
• UPS coverage includes the mini PC, NAS, PoE switch and relevant network equipment.
• NAS outage, power-loss and restore tests have been completed and documented.
• Critical recordings and configuration have independent backup copies.

Frequently Asked Questions

Can Frigate record directly to a Synology, QNAP or UGREEN NAS?

Yes, provided the NAS offers a correctly configured network share and the Linux mini PC mounts it reliably. Frigate sees the mounted host directory as /media/frigate. The exact NAS export/share configuration differs by vendor, and Frigate recommends local recording storage where reliability is paramount.

Should I put the Frigate database on the NAS?

No. Keep the default SQLite database on a local persistent SSD under /config. The Frigate project warns that network filesystems can cause database locking and corruption. Back up the database consistently to the NAS or another destination, rather than operating it directly over NFS/SMB.

Does Frigate continue recording when Home Assistant is offline?

Normally yes: Frigate is an independent application. It needs its camera streams, its own host and the recording destination, not Home Assistant itself. MQTT-driven Home Assistant entities and automations may be unavailable while Home Assistant or the broker is down.

Will an Intel N100 mini PC handle eight cameras?

Possibly, but the answer depends on detection-stream resolution, frame rate, codec, model, scene activity, concurrent live viewers and driver support. Use the current Frigate hardware guidance and test your real cameras; there is no universal eight-camera guarantee from the processor name alone.

Does a 2.5GbE connection improve Frigate recordings?

Only if Gigabit Ethernet is the actual bottleneck. A handful of 4Mbps cameras creates modest throughput, even with separate detect streams and NAS writes. Network reliability, camera connection stability and NAS latency often matter more than headline link speed. Larger multi-camera systems or shared busy networks may benefit from 2.5GbE.

What happens if the NAS disconnects?

Recording can stop, block or error until the share returns. A tmpfs cache is not a durable, unlimited recording buffer. Configure mount guards and monitoring, test outage recovery, and prefer local recording media if continuous footage is essential.

Verdict: the configuration we would choose

For a practical residential Frigate installation with an existing NAS, our preferred two-box design is an Intel mini PC on wired Ethernet, a local SSD for /config, an explicitly verified NAS NFS recording mount, sensible camera substreams, hardware-assisted decoding and a dedicated MQTT connection to Home Assistant. Keep the NAS share isolated, back up the local database, and treat the mount as a monitored dependency. This makes compute and storage independently upgradeable without pretending the NAS link cannot fail.

If evidence continuity is more important than compactness or storage consolidation, use a local recording disk and send separate protected copies to the NAS instead. The extra disk is often cheaper than discovering that a routine NAS reboot silently created a gap in your security footage.

Related ESP32 and Home Server Guides

• Best Frigate Hardware for 4, 8 or 16 IP Cameras — selecting a suitable NVR host and sizing retention.
• Mini PC Plus NAS vs a NAS-Only Home Server — the wider two-box architecture.
• Best 2.5GbE Switches for a Smart Home and Home Lab — when faster managed networking helps.
• Best NAS for Home Assistant Backups and Docker — storage-platform selection and backup planning.

Official Documentation and Further Reading

• Frigate: Planning a New Installation — network storage caveats and memory sizing.
• Frigate: Installation — Docker Compose, storage paths, tmpfs and shared-memory calculation.
• Frigate: Recording — retention, media paths and free-space behaviour.
• Frigate: Camera Configuration — detect and record stream roles.
• Frigate: FFmpeg Presets — hardware decoding presets.
• Frigate: Object Detectors — current OpenVINO and other detector support.
• Frigate: Home Assistant Integration — MQTT and integration setup.
• Frigate: System and SQLite Database — default database path and network storage warning.
• Frigate: Common Errors — database, shared memory and cache diagnostics.
• Docker: Compose Service Bind Mounts — long syntax and create_host_path.
• Synology: NFS Shared Folder Access — NAS export and Linux mount procedure.