Media Server Storage Design: NAS, CIFS/NFS Mounts, Permissions, and Local Cache

A detailed storage design guide for Plex, Sonarr, Radarr, SABnzbd, and Tdarr covering NAS mounts, CIFS/NFS choices, Linux permissions, local cache, and rebuild-friendly paths.

Rights and lawful use: Apply this NAS, mount, cache, and permissions design only to media you own or are authorized to store and process. A reliable CIFS or NFS path does not grant permission to acquire, copy, transcode, or share someone else's copyrighted work.

Who this is for: This guide serves Plex and Arr operators deciding which final-library paths belong on a NAS, which SABnzbd and Tdarr work belongs on local storage, and how Linux mount and group permissions should connect those tiers.

The Storage Problem Most Homelabs Eventually Hit

Media automation is deceptively storage-heavy. The final movie file may only be written once, but the path to get there can involve download chunks, par repair, unpacking, failed retries, import moves, Plex analysis, thumbnail generation, Tdarr transcode cache, replacement files, and backups. If all of that happens on a network mount, performance can look fine one day and terrible the next.

The beginner rule is simple: keep final media on the NAS and keep temporary work local. The technical rule is more specific: high-churn workloads should use low-latency local storage, final libraries should use stable mounted storage, and every process should create files with permissions the next process can use.

Recommended Layout

/data
  /downloads
    /incomplete # local SSD/NVMe recommended
    /usenet
      /movies # completed staging
      /tv
  /media # NAS mount or large local array
    /movies
    /movies-animated
    /movies-comedy
    /tv
  /cache # local SSD/NVMe recommended
    /plex
    /tdarr
    /sabnzbd

This layout gives applications one logical path while still allowing you to mount different physical storage underneath it. For example, /data/media can be a NAS mount while /data/cache and /data/downloads/incomplete are local NVMe folders.

Interactive storage map
What Belongs on Local Disk vs NAS

Click through the storage decisions that keep imports fast, cache writes local, and final media durable.

  1. High churnSAB Incomplete

    Active article writes, repair, and unpack work belong on local SSD/NVMe when possible.

  2. TemporaryPlex / Tdarr Cache

    Transcode cache is scratch space. It should be fast and disposable, not a remote bottleneck.

  3. StagingCompleted Downloads

    Completed category folders wait for Radarr or Sonarr to import. Keep paths predictable.

  4. DurableFinal Media

    Movies and TV library roots live on the NAS or protected media volume.

  5. RebuildConfig Backups

    Back up compose files, app configs, databases, scripts, and restore notes away from the host.

Mount markerUse a marker file or systemd dependency so apps do not write into an empty mount point.
Shared groupUse a media group and UMASK 002 so apps can hand files to each other cleanly.

What Belongs on the NAS

  • Final movie and TV libraries.
  • Application configuration backups.
  • Exported restore notes and compose files.
  • Long-term logs or daily health reports.
  • Media that is already imported, validated, and ready for Plex.

NAS storage is ideal for capacity and centralization. If it supports snapshots, it also gives you a recovery point when a bad script, bad permission change, or mistaken delete affects a library. The NAS should be the home of finished assets, not the scratchpad for every temporary operation.

What Belongs on Local Disk

  • SABnzbd incomplete downloads.
  • SABnzbd repair and unpack work.
  • Plex transcode temporary directory.
  • Tdarr cache and staging files.
  • One-off test encodes and sample previews.
  • Short-lived logs used by automation scripts.

Local SSD or NVMe matters because these workloads are random, temporary, and write-heavy. They do not need NAS durability during processing. They need speed and low latency. Once the file is complete and imported, then it belongs in the final NAS-backed media folder.

CIFS vs NFS in Plain English

CIFS/SMB is often easiest when the NAS is a Synology or Windows-friendly appliance. It integrates well with user accounts and is familiar. NFS is often lighter for Linux-to-Linux or Linux-to-NAS workflows and can be very fast, but identity mapping needs care. Either can work. The bad setup is not CIFS or NFS by itself. The bad setup is an unreliable mount with inconsistent ownership, hidden permission translation, or temporary workloads running across it.

  • Use CIFS/SMB when: your NAS management model is SMB-first, your permissions are easier to reason about there, or you need compatibility with Windows clients.
  • Use NFS when: your media servers are Linux-first, you want lower overhead, and you can control UID/GID mapping cleanly.
  • Avoid both for: incomplete downloads, Plex transcode temp, and Tdarr transcode cache unless you have a very specific reason and have tested it.

Mount Reliability

A media stack should not boot into a half-working state where Plex starts before the NAS mount is available. If Plex, Radarr, Sonarr, or Tdarr sees an empty mount point, some apps may think the library disappeared. Use systemd mount dependencies or automount options so services wait for storage.

# Mount command equivalent of an /etc/fstab entry.
# /etc/fstab entries must stay on one physical line.
# This builder prints a readable line you can review before adding it.
cifs_opts=(
  credentials=/root/.smb-media
  uid=1000
  gid=1000
  iocharset=utf8
  vers=3.1.1
  nofail
  x-systemd.automount
  x-systemd.requires=network-online.target
)

printf '%s %s %s %s %s %s\n' \
  '//YOUR_NAS/media' \
  '/data/media' \
  'cifs' \
  "$(IFS=,; echo "${cifs_opts[*]}")" \
  '0' \
  '0'

Do not copy this blindly. The point is to use explicit credentials, explicit ownership, modern SMB protocol support, network-online awareness, and automount behavior. For NFS, the options differ, but the same concept applies: mounts should be reliable before media services do real work.

Permissions That Survive New Files

A one-time chmod -R is cleanup, not a design. If SABnzbd creates files that Radarr cannot move, or Tdarr replaces files Plex cannot read, the permission model is broken at creation time. Use a shared group such as media, put app users in that group, and make new files group-writable.

sudo groupadd -f media
sudo usermod -aG media plex
sudo usermod -aG media sonarr
sudo usermod -aG media radarr
sudo usermod -aG media sabnzbd
sudo usermod -aG media tdarr
sudo chgrp -R media /data
sudo chmod -R g+rwX /data

For Docker containers, align PUID, PGID, and UMASK. For systemd services, check the service user and group. For SABnzbd specifically, the Unix permissions setting can influence the final access rights given to completed downloads.

SABnzbd Incomplete vs Completed

Incomplete should usually be local. Completed can be local or near the final media root depending on your import strategy. If completed is local and the library is on NAS, Radarr/Sonarr will copy or move across filesystems. If completed and final media are on the same filesystem, hardlinks and atomic moves are easier. Choose based on your storage speed, capacity, and how much you value hardlinks.

Tdarr Cache Placement

Tdarr cache should be local and large enough for the largest files you expect to process. A Tdarr node can create temporary output files before replacing the original. If that cache is on NAS storage, you push heavy write load across the network and make transcodes slower. Local cache also reduces the blast radius of a bad transcode job because temporary files are isolated from final media until validation passes.

Plex Transcode Directory

Plex transcode cache should also be local. If you have enough RAM and know what you are doing, a RAM-backed transcode directory can be fast, but it can also fail badly if users transcode large files and exhaust memory. For most homelabs, a local SSD/NVMe folder is the safer default.

Testing Storage Correctly

  1. Reboot the media server and confirm mounts come up automatically.
  2. Start Plex, Sonarr, Radarr, SABnzbd, and Tdarr after the reboot.
  3. Download a small test item through SABnzbd.
  4. Confirm Sonarr or Radarr imports it without manual intervention.
  5. Confirm Plex can play it.
  6. Confirm Tdarr can create cache output and replace the file.
  7. Confirm final permissions are still correct after replacement.
  8. Unmount or simulate NAS downtime in a controlled window and confirm services fail safely.

Common Mistakes

  • Using a final media root as a download folder.
  • Putting incomplete downloads on NAS because it looks tidy.
  • Letting Plex start when the media mount is empty.
  • Fixing permissions manually instead of fixing the service umask.
  • Using different container paths for apps that need to cooperate.
  • Leaving Tdarr cache on the same slow network mount as final media.
  • Not documenting which paths are local and which are mounted.

Beginner Walk-Through: Why Incomplete Downloads Should Be Local

When SABnzbd downloads a file, it does not receive one perfect finished movie or episode. It receives many articles, verifies them, repairs missing pieces when possible, and unpacks the result. That creates a lot of temporary reads and writes. A NAS is excellent for storing the finished library, but it is usually not the best scratchpad for this kind of churn.

Putting incomplete work on local SSD or NVMe keeps the noisy work close to the CPU and network card. Once the file is complete, Radarr or Sonarr can import it into the final library. That is the point where NAS storage makes sense.

Technical Mount Notes

  • Use stable mount points. Do not let apps write to an empty local directory when the NAS mount is missing.
  • Use systemd automount or service dependencies so media apps wait for storage.
  • Use marker files to verify the mounted filesystem is really present.
  • Avoid changing UID/GID mapping after the library is populated unless you plan the migration.
  • Measure import behavior. A cross-filesystem move can become a copy plus delete, which is slower than an atomic move.

A Practical Mount Verification Script

#!/usr/bin/env bash
set -euo pipefail
mountpoint -q /data/media
test -f /data/media/.media_mount_marker
test -d /data/media/movies
test -d /data/media/tv
echo "media mount healthy"

Run a check like this before starting automation or as part of a daily health report. It catches the ugly case where a path exists but the NAS is not actually mounted.

Mount Health Rules

  • Use systemd mount dependencies for native services so apps start only after media paths exist.
  • Avoid broad recursive ownership changes on the whole NAS; target only the media folders this stack manages.
  • For CIFS mounts, document credentials file permissions, UID/GID mapping, and whether your workload needs options such as noperm or nobrl.
  • For Docker, mount the same host path into every media container as /data whenever possible.
  • Keep Tdarr cache, Plex transcode temp, and SAB incomplete work on local disk unless you have a tested reason to use network storage.

Implementation Playbook: Ubuntu Mounts and Docker Volumes

Ubuntu CIFS Mount Example

For a Synology or SMB-first NAS, CIFS is often the easiest path. Store credentials in a root-readable file, create a mount point, and use options that keep ownership predictable for the media stack.

sudo apt update
sudo apt install -y cifs-utils
sudo mkdir -p /data/media

sudo tee /root/.smb-media >/dev/null <<'EOF'
username=YOUR_NAS_USER
password=YOUR_NAS_PASSWORD
domain=WORKGROUP
EOF

sudo chmod 600 /root/.smb-media

mount_opts="credentials=/root/.smb-media"
mount_opts="$mount_opts,uid=1000,gid=1000"
mount_opts="$mount_opts,dir_mode=0775,file_mode=0664"
mount_opts="$mount_opts,vers=3.1.1"

sudo mount -t cifs //YOUR_NAS/media /data/media \
  -o "$mount_opts"

After testing manually, add the mount to /etc/fstab or create a systemd mount unit. Do not let Plex, Radarr, Sonarr, or Tdarr start against an empty mount point.

Ubuntu NFS Mount Example

For Linux-first environments, NFS can be cleaner and lighter. The critical detail is UID/GID mapping. The user and group IDs on the media host need to line up with the NAS export expectations.

sudo apt update
sudo apt install -y nfs-common
sudo mkdir -p /data/media
sudo mount -t nfs YOUR_NAS:/volume1/media /data/media
findmnt /data/media
touch /data/media/.media_mount_marker

Docker Compose Volume Pattern

Containers should see the same logical paths as each other. Do not map Radarr to /movies, SABnzbd to /downloads, and Tdarr to a third unrelated path if those paths need to refer to the same files.

services:
  radarr:
    volumes:
      - /opt/radarr/config:/config
      - /data:/data
  sonarr:
    volumes:
      - /opt/sonarr/config:/config
      - /data:/data
  sabnzbd:
    volumes:
      - /opt/sabnzbd/config:/config
      - /data/downloads:/data/downloads
  tdarr:
    volumes:
      - /opt/tdarr/server:/app/server
      - /data/media:/data/media
      - /data/cache/tdarr:/temp

Verification Commands

findmnt /data/media
stat -c '%U %G %a %n' /data /data/media /data/downloads /data/cache
sudo -u plex test -r /data/media/movies && echo "plex can read movies"
sudo -u radarr test -w /data/media/movies && echo "radarr can write movies"
sudo -u tdarr test -w /data/cache/tdarr && echo "tdarr cache writable"

Run these before troubleshooting an app. If the filesystem does not behave, the application will not behave either.

What This Does Not Prove

These commands are acceptance checks, not a TechGeeks storage benchmark. They do not prove throughput, latency, hardlink behavior, recovery time, or resilience under NAS failure. Measure those properties with representative files on your own storage, and test a controlled mount loss before relying on the design.

Series Navigation

This storage chapter supplies the path contract used by the rest of the Plex, Arr, and Tdarr series: stable NAS library mounts, local high-churn work areas, and shared permissions. The linked install and automation chapters build on those choices, while the series wrap-up shows how the storage path fits the complete stack.

Related foundation: Building a Production-Grade Tdarr GPU Transcoding Stack for a Homelab.

References

Related TechGeeks resources

Use these next before buying storage or changing mount paths in a live media environment.

Need help applying this?

Bring TechGeeks into the real environment.

If you are working through this on a live network, WordPress site, Linux server, AI workflow, or PisoWiFi deployment, send the context and we can help turn it into a practical plan.

Request helpGet field notesRecommended gear

7 thoughts on “Media Server Storage Design: NAS, CIFS/NFS Mounts, Permissions, and Local Cache

Leave a Reply

Your email address will not be published. Required fields are marked *