This page covers how to configure NAS storage devices for a Trash Panda–style Plex ecosystem.

The goal here is not theoretical perfection or enterprise purity. The goal is availability, performance, and predictability in a real-world hobbyist deployment that serves Plex, ARR automation, and users who expect things to just work.

This guidance assumes:

• A NAS with at least two physical network interfaces
• A segmented network with NFS, LAN, and DMZ VLANs already defined
• Linux-based service hosts consuming storage primarily over NFS, with optional SMB access from LAN based Windows clients.

Before diving into configuration, it’s important to be explicit about priorities:

1. Availability > Raw Performance
Media that is temporarily unavailable is worse than media that transfers a little slower.

2. Predictable Performance
Large sequential reads dominate Plex workloads. We optimize for that.

3. Operational Simplicity
Recovery should be boring. Expansion should be deliberate. Maintenance should be rare.

4. Security Through Segmentation
Storage traffic stays isolated. User traffic stays convenient.

Everything below flows from those principles.

A dual-NIC NAS is foundational to this ecosystem to ensure total separation and isolation of NFS traffic.

NIC 1 – NFS VLAN
Dedicated, high-throughput storage traffic between the NAS and media services.

NIC 2 – LAN VLAN
Management access and SMB connectivity for user-facing devices.

These interfaces should never be bonded. They serve different purposes and different trust levels.

• Assigned exclusively to the NFS VLAN
• No default gateway
• Jumbo Frames enabled (MTU 9000), end-to-end
• Access restricted to known service hosts only

This interface exists solely to move large media files efficiently and quietly.

• Assigned to the LAN VLAN
• Default gateway present
• Standard MTU (1500)
• Used for:
  
  • NAS management UI
  • SMB shares
  • Backup monitoring
    

This separation ensures storage traffic never competes with user traffic and is never exposed to unnecessary risk.

Media libraries are large, slow-moving, and painful to rebuild. RAID exists here to keep the system online, not to replace backups.

• RAID 6 (preferred for larger arrays)
  • Tolerates two disk failures
  • Slower writes, excellent availability

• RAID 10 (if disk count and budget allow)
  • Strong performance
  • Faster rebuilds
  • Higher usable capacity cost

• RAID 5
  • Rebuild risk is unacceptable with modern drive sizes

• Single-disk redundancy only
  • Downtime during rebuilds is common and long

If your NAS supports it and you can afford the bay:

• Configure at least one hot spare

Automatic rebuilds reduce downtime and human intervention — both are wins.

Keep it simple.

• One primary volume for media and metadata
• Avoid unnecessary volume fragmentation
• Expansion should be planned, not improvised

Complex layouts tend to create operational debt without meaningful benefit for media workloads.

The ideal file system for this ecosystem has:

• Strong sequential read performance
• Stable NFS and SMB support
• Mature tooling and recovery options

Common choices:

• EXT4
  • Extremely stable
  • Excellent performance
  • Low overhead

• XFS
  • Very good for large files
  • Scales well with volume size

• Btrfs / ZFS
  • Powerful, but heavier
  • Snapshot features are useful, but come with complexity

For first-time builders, simplicity beats features. Choose what your NAS platform supports best and what you understand how to recover.

NFS is the primary protocol for Plex, ARR services, and Unmanic in this ecosystem.

• Lower overhead than SMB
• Excellent Linux support
• Predictable performance
• Clean permission model for service accounts

• Export only to NFS VLAN IPs
• Use explicit host-based access controls
• Disable root squash *only if you fully understand the implications*

Typical exports include:

• Media libraries
• Incomplete and completed download paths
• Transcode or processing work directories (if needed)

• Jumbo Frames must be supported end-to-end
• Avoid exporting the same paths over both NFS and SMB
• Consistency matters more than micro-optimizations

SMB exists for human interaction, not core services.

• Browsing media from desktop systems
• Manual file inspection or cleanup
• Occasional direct access from Windows or macOS

• SMB access only on the LAN VLAN
• Read/write permissions scoped to user accounts
• No service containers or VMs should rely on SMB mounts

This keeps automation fast and user access convenient without entangling the two.

RAID is not a backup. Snapshots are not a backup.

Backups exist to save you from:

• Accidental deletion
• Corruption
• Catastrophic failure
• Poor decisions made at 2 AM

• External USB HDD
• Capacity large enough to hold the full media library
• Directly attached to the NAS

• One-way sync from NAS → backup disk
• No live mounts
• No automation that can delete backup data

Backups should be:

• Predictable
• Boring
• Verifiable

The NAS is the quiet workhorse of the entire Plex ecosystem.

If configured correctly:

• You will rarely think about it
• Performance will feel effortless
• Failures will be survivable

Optimize for availability, isolation, and simplicity, and the rest of the system becomes much easier to manage.