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

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.

Quick Answer

Use stable paths for final media and separate temporary download and transcode work from the library. Record which paths are local and which are NAS mounts, then verify access as each service identity. Test startup, import, replacement, and a controlled storage outage before enabling automation. A shared path name does not establish hardlink support, and neither a mount check nor this unperformed example proves recovery.

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.

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

Choose CIFS/SMB or NFS according to the NAS permissions model and the clients you must support. For either protocol, document how service identities map to file access and test reads, writes, imports, and mount recovery. This article provides no comparative measurements that establish one protocol as faster for your workload.

• 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: it fits your Linux hosts and NAS export policy, and you can verify the required UID/GID mapping.
• 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

Inspect permissions created by SABnzbd, Radarr/Sonarr and Tdarr as well as existing files. The commands below make no changes. Record each service identity, mount and ACL before requesting a path-specific correction from the storage owner. For new local directories, use the guarded new-tree example in the linked architecture chapter; do not apply it to NAS exports or existing data. GNU chmod documentation explains why a recursive change reaches files as well as directories.

(
set -euo pipefail
# Inspection only: no memberships, ownership, modes, or files are changed.
: "${MEDIA_USER:?export the actual service account to inspect}"
id "$MEDIA_USER"
namei -l /data/media /data/downloads /data/cache
findmnt --target /data/media --output SOURCE,FSTYPE,TARGET
getfacl -p /data/media /data/downloads /data/cache
)

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

Provision Tdarr cache separately from the final library and check free space for the intended files and worker count. Tdarr documents that output is written to cache and then copied back to replace the source. Cache placement alone does not prevent a bad replacement. Keep recoverable originals and validate output before permitting copy-back; no cache-performance or replacement test was performed here.

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.
• Verify the expected mounted source and filesystem type; a marker alone is not proof of the intended NAS mount.
• 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

(
set -euo pipefail
: "${EXPECTED_MEDIA_SOURCE:?export the reviewed NAS share or export}"
: "${EXPECTED_MEDIA_FSTYPE:?export cifs, nfs, or nfs4}"
case "$EXPECTED_MEDIA_FSTYPE" in cifs|nfs|nfs4) ;; *) exit 1 ;; esac
[[ ! -L /data && ! -L /data/media ]]
mountpoint -q /data/media
actual_source=$(findmnt --noheadings --raw --mountpoint /data/media --output SOURCE)
actual_type=$(findmnt --noheadings --raw --mountpoint /data/media --output FSTYPE)
[[ "$actual_source" == "$EXPECTED_MEDIA_SOURCE" ]]
[[ "$actual_type" == "$EXPECTED_MEDIA_FSTYPE" ]]
test -d /data/media/movies
test -d /data/media/tv
printf 'Expected NAS mount and directories present; no files written.\n'
)

The Bash check exits unsuccessfully if the reviewed share/export, filesystem type or required directories do not match. Unlike a marker alone, it compares the mounted source and type, and it never creates a marker. Configure the expected values from the approved NAS inventory, not from a possibly incorrect live mount. This is a point-in-time check, not a startup or runtime interlock. Keep automation paused until its service dependencies and controlled NAS-loss behavior are implemented and tested; a later disconnect can still occur after this check passes.

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 SMB, use your NAS vendor's share and Linux-client instructions together with the mount.cifs manual. Have the administrator provision the mount and a root-owned 0600 credentials file through the approved secret-management process. Do not paste credentials into shell history or overwrite an existing credential file. Review UID/GID mapping, share ACLs and dialect compatibility before mounting; keep media services stopped while changing the mount.

After the separately reviewed SMB mount is established, run the read-only mount check above with the expected source set to the approved //server/share and type cifs. Failure means stop and diagnose the mount; do not create a marker or local media folders to make the check pass. This article does not install or replace credentials, fstab entries or mount units.

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 NFS, use the NAS export instructions and the Linux NFS mount documentation to review identity mapping, export permissions and mount options. Keep media services stopped until the intended export is mounted and verified. No relative performance advantage is established here.

After the separately reviewed NFS mount succeeds, run the read-only check above with the expected source set to the approved server:/export and the actual planned NFS filesystem type (nfs or nfs4). No marker-creation command is provided: a failed mount must not turn into a writable local library. If the mount or source check fails, leave services paused and repair the mount through the storage runbook.

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.

• Plex Homelab Architecture: Storage, GPU Transcoding, and Library Design
• Media Server Storage Design: NAS, CIFS/NFS Mounts, Permissions, and Local Cache
• Prowlarr Setup Guide: Clean Indexer Management for Sonarr and Radarr
• Sonarr Homelab Setup Guide: Install, Update, Optimize, and Connect to Tdarr
• Radarr Homelab Setup Guide: Install, Update, Optimize, Lists, and Tdarr Integration
• SABnzbd Performance Tuning for a Homelab Media Server
• Custom Formats and Quality Profiles Explained for Radarr and Sonarr
• Radarr Import Lists That Do Not Fill Your Library With Junk
• Plex + Tdarr GPU Strategy: Sharing NVIDIA GPUs Without Hurting Playback
• Reverse Proxy for Media Apps: Nginx Proxy Manager, SSL, Access Lists, and Security
• Backup and Disaster Recovery for Plex, Sonarr, Radarr, Tdarr, Prowlarr, and SABnzbd
• Monitoring and Health Checks for a Plex and Arr Homelab
• The Complete Plex, Arr, and Tdarr Homelab Media Automation Series

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

References

• Servarr Docker Guide
• TRaSH Guides: hardlinks, atomic moves, paths, and permissions
• systemd.mount documentation
• SABnzbd Unix permissions
• SABnzbd configuration overview
• Plex library settings