How to Set Up a Media Server Stack on Synology

A Synology NAS can do far more than store media files. With the right architecture, it can also become the central platform for Plex, automated media management, download handling, library organization, and backup.

The difficult part is rarely installing each application individually.

Problems usually appear when Plex, Sonarr, Radarr, qBittorrent, and related services do not agree on folder paths, permissions, ownership, or workflow responsibilities.

A reliable Synology media server stack should therefore be designed as one coordinated system rather than as several unrelated containers.

This guide focuses on how to structure that environment correctly. It assumes qBittorrent itself is already working and does not repeat basic connection or WebUI setup steps.

What Does a Synology Media Server Stack Include?

A typical self-hosted media stack may include:

• Plex Media Server for organizing and streaming media
• Sonarr for managing television libraries
• Radarr for managing movie libraries
• qBittorrent as the download client
• Optional additional media-management applications
• Synology shared folders for downloads and final media
• Container Manager for running containerized applications

Plex can run either directly as a Synology package or in a container. Plex officially supports NAS installations and Docker-based deployments, although hardware capability becomes particularly important if transcoding is required.

The rest of the stack is commonly deployed using containers because that approach provides clearer separation between application configuration and stored media.

Plan the Folder Structure Before Installing Containers

Folder design is one of the most important decisions in the entire build.

A poorly designed structure can create failed imports, duplicate data, slow file moves, and broken hardlinks.

A practical Synology layout might look conceptually like this:

/volume1/data/

with subfolders such as:

• media/movies
• media/tv
• downloads/torrents
• downloads/complete
• downloads/incomplete

Then each application receives access to the same parent data location.

For example:

/volume1/data → /data

inside Sonarr, Radarr, and qBittorrent.

This consistency is extremely important.

Both Sonarr and Radarr specifically warn that mismatched container paths are a common Docker problem. If qBittorrent reports a completed download as /torrents/example, while Sonarr sees the same physical folder as /downloads/example, automation can fail or require Remote Path Mapping.

Use One Shared Data Mount Where Possible

It can be tempting to create separate mounts such as:

• /movies
• /tv
• /downloads
• /torrents

That looks organized, but inside Docker those mounts can appear as separate filesystems.

Sonarr and Radarr recommend using a common volume such as /data, with media and downloads underneath it.

A cleaner container view would therefore be:

/data/media/movies

/data/media/tv

/data/downloads/torrents

This makes paths predictable across the entire stack. It also improves the ability to use hardlinks.

Why Hardlinks Matter in an Automated Media Stack

Without hardlinks, an automated workflow may have to physically copy a downloaded file from the download directory into the media library.

For a 40 GB movie, that can temporarily require another 40 GB of storage and create significant disk activity. Hardlinks allow two directory entries to reference the same underlying data without immediately duplicating the file. That can be particularly useful when the download client must continue retaining a file while Radarr or Sonarr also makes it available in the organized Plex library.

Radarr and Sonarr both identify volume layout as critical for enabling fast moves and hardlinks. Separate container mounts such as /movies and /downloads can prevent this behavior because Docker presents them as different filesystems.

For this reason, a unified /data mount is usually a better architectural choice.

Standardize Synology Permissions Across Containers

The next major source of trouble is permissions. qBittorrent may successfully create a downloaded file, but Sonarr may be unable to move or rename it. Radarr may be able to import a movie, but Plex may not be able to read it. The solution is not to give every container unrestricted administrative privileges.

Instead, create a deliberate permission model. A common approach is to use a dedicated Synology user or group for media applications and ensure that all relevant services share appropriate permissions to the required directories. Radarr specifically recommends running related applications with a common group so download clients and media managers can read and write the shared folders they require.

Separate Application Configuration From Media Data

Each container should have its own persistent configuration directory.

For example:

/volume1/docker/sonarr

/volume1/docker/radarr

/volume1/docker/qbittorrent

These could map individually to:

/config

inside their respective containers.

The actual media should remain somewhere else, such as:

/volume1/data

This separation makes administration much easier.

You can back up application settings independently from a multi-terabyte media library, replace a container without touching the underlying media, and troubleshoot an application without reorganizing storage.

The official qBittorrent container likewise separates its configuration path from its downloads path.

Configure the Workflow in the Right Direction

Once paths and permissions are correct, the workflow should become straightforward.

A simplified architecture looks like this:

Sonarr/Radarr → qBittorrent → Download Folder → Import → Media Library → Plex

Sonarr or Radarr manages the requested library item.

The download client handles the transfer. Once complete, the relevant media manager identifies the finished file, renames and organizes it, and places or hardlinks it into the correct media directory. Plex then scans the final media library. Each application should have one clearly defined job. Trying to make qBittorrent organize the final Plex library independently while Sonarr or Radarr also manages naming and imports can create conflicting automation.

Avoid Unnecessary Remote Path Mapping

Remote Path Mapping is useful in certain architectures, but it should not be the first solution to a poorly designed container layout. Sonarr and Radarr document Remote Path Mapping specifically as a workaround when a download client reports a path that appears differently inside the media-management container. If all applications run on the same Synology NAS, consistent volume mounts can often eliminate the need for this extra translation layer.

For example, if every related container sees:

/data/downloads/torrents

as exactly the same path, there is nothing to translate. That makes troubleshooting much simpler.

Let Plex Read the Final Library, Not Manage Downloads

Plex should generally be positioned near the end of the workflow. Its primary role is to index, organize, stream, and present the finalized library. It does not need write access to every download directory simply because the other applications do.

Plex’s own documentation notes that the account running Plex must have sufficient read and execute access to media directories. Using minimum necessary permissions reduces the number of applications capable of modifying your final library. That becomes increasingly valuable as the stack grows.

Consider Whether Plex Should Run Natively or in Container Manager

There are two reasonable approaches on a Synology NAS.

Running Plex using the native Synology package can simplify access to NAS-specific hardware and package management. Running Plex as a container can make the overall architecture more consistent with the rest of the stack and make configuration portability easier.

The better choice depends on the Synology model, DSM environment, transcoding requirements, and how comfortable the administrator is maintaining containers. Plex also recommends checking NAS capabilities carefully when transcoding is expected, because not every NAS processor provides the same media-processing performance.

Organize the Stack With Synology Container Manager

On supported Synology systems, Container Manager provides a convenient way to operate Docker-based applications.

Instead of treating every container as an isolated manual deployment, group related services into a controlled project structure.

Keep configuration information documented, including:

• Container name
• Image source
• Port mappings
• Volume mappings
• User and group IDs
• Time zone
• Restart behaviour
• Network configuration
• Application dependencies

This makes future troubleshooting much easier than trying to reconstruct how the stack was originally assembled.

Use Consistent User and Group IDs

Many community container images support variables such as PUID and PGID.

These identifiers allow the application running inside the container to interact with files using a specific Synology user and group identity. The exact implementation varies by image, so administrators should follow the documentation for the chosen container rather than assume that every image uses the same variables.

The official qBittorrent container, for example, currently includes optional PUID, PGID, PAGID, timezone, and umask variables in its Compose configuration. Whatever method is used, consistency matters more than arbitrary values.

Don’t Run Containers With More Privileges Than Necessary

It may be tempting to solve permission problems by giving applications broad filesystem access. That usually hides the underlying configuration issue rather than solving it. Sonarr needs access to the television library and relevant download directory. Radarr needs access to the movie library and relevant download directory.

qBittorrent needs access to its download locations. Plex primarily needs access to the finished media it serves. Restricting each service to the resources it actually requires creates a cleaner and more defensible deployment.

Protect the Application Configurations

Media libraries can often be recreated or re-ripped from legitimate source media. Application configuration may be harder to reconstruct than expected. Sonarr and Radarr contain databases, quality profiles, naming rules, indexing configuration, history, and other operational information.

Plex maintains library metadata and server configuration. qBittorrent stores settings and session information in its configuration directory. Include these application directories in your Synology backup strategy. For a large environment, protecting several gigabytes of container configuration may save far more time than rebuilding the entire stack manually after a storage failure.

Be Careful With Automatic Container Updates

Automation is useful until an update breaks compatibility.

Automatically replacing every container image immediately after a new version appears can create unnecessary risk.

A more controlled process is:

1. Back up the application’s configuration.
2. Review relevant release notes.
3. Update one component at a time.
4. Confirm it starts correctly.
5. Test communication with dependent services.
6. Verify imports and library access.
7. Proceed to the next component.

This is particularly important when several applications depend on one another.

If qBittorrent, Sonarr, Radarr, and Plex are all updated simultaneously, identifying the cause of a new problem becomes much harder.

Give qBittorrent Enough Time to Shut Down

One less obvious operational detail involves container shutdown.

The official qBittorrent Docker documentation warns that Docker’s normal short stop interval may interrupt qBittorrent before it finishes shutting down properly. Its example configuration uses an extended stop grace period of 30 minutes. That does not mean every shutdown will require 30 minutes. It gives the application enough opportunity to terminate cleanly when necessary. This becomes especially relevant during NAS reboots or container-stack updates.

Don’t Expose Every Web Interface to the Internet

A stack may include several management interfaces.

That does not mean every one should have a public port forwarded through the router.

Interfaces for Sonarr, Radarr, qBittorrent, Container Manager, and DSM should generally remain protected behind trusted local access, VPN connectivity, a properly secured reverse proxy, or another deliberate remote-access architecture.

Exposing management interfaces directly increases the attack surface of the NAS. For business environments, remote administration should be designed as part of the security architecture rather than added casually after the media stack is running.

The Best Media Stack Is Predictable

A well-designed Synology media server should not require constant manual correction.

The strongest environments usually share a few characteristics:

• One consistent storage hierarchy
• Common container paths
• Deliberate user and group permissions
• Hardlink-friendly filesystem design
• Separate configuration directories
• Clear responsibilities for each application
• Controlled updates
• Protected configuration backups
• Restricted administrative access

When those foundations are correct, Plex, Sonarr, Radarr, and qBittorrent can operate as one coordinated system instead of a collection of applications repeatedly fighting over files and permissions. The goal is not simply automation. It is predictable automation that remains understandable when something eventually needs troubleshooting. All media-management and download tools should, of course, be used only with content you are authorized to access, download, or manage.

About Epis Technology

Epis Technology helps organizations design and maintain Synology environments for storage, application hosting, Docker and Container Manager workloads, secure remote access, networking, media storage, backup, and disaster recovery. Build a reliable media stack with expert Synology consulting.

The company can assist with Synology permissions, storage layouts, virtualization, container architecture, performance troubleshooting, Hyper Backup, snapshots, Microsoft 365 and Google Workspace protection, cybersecurity, and infrastructure modernization. By designing the underlying Synology environment correctly, Epis Technology helps businesses and advanced users build systems that remain secure, manageable, and reliable as applications and storage requirements grow.