starred/Radarr

Fork 0

mirror of https://github.com/Radarr/Radarr.git synced 2026-03-02 22:57:34 -05:00

Allow configuration of `MediaCover` path #9272

New issue

Closed

opened 2026-02-20 00:12:20 -05:00 by deekerman · 5 comments

deekerman commented

2026-02-20 00:12:20 -05:00

Owner

Originally created by @keyboardr on GitHub (Sep 23, 2025).

Is there an existing issue for this?

I have searched the existing open and closed issues

The MediaCover directory is currently fixed within the main configuration folder for both Radarr and Sonarr. This design is problematic for users with limited storage on their root/OS drive, as this directory can grow to a significant size and exhaust available disk space.

Motivation

My device's setup is a common configuration on low-power devices like the ZimaBlade. My root drive, which holds the OS and application configurations, is a small 27 GB drive. My actual media library is on a separate, much larger drive accessible over the network (NAS). I also have a local 1 TB SATA drive dedicated to caches and temporary files.

Most of my application config folders are under 100 MB. However, both Radarr and Sonarr are exceptions because their respective MediaCover folders can grow to several gigabytes, consuming a large portion of the limited space on my root drive.

Allowing me to configure the path for the MediaCover directory would let me bind this folder to my dedicated 1 TB SATA drive. This would prevent the root drive from filling up and improve overall system stability. This is similar to the issue mentioned in issue #5711, which highlighted a similar need for configurable cache locations.

Describe the solution you'd like

Please add a new setting in the Radarr UI that allows users to specify an alternative path for the MediaCover directory. Given the shared architecture with Sonarr, it would be beneficial for this feature to be implemented across both applications. This would provide the flexibility needed for users with similar disk configurations to manage their storage effectively.

Describe alternatives you've considered

I have attempted to use symlinks and hardlinks to move the MediaCover directory. However, this approach poses several problems, especially when used within a containerized environment (like Docker). Correctly managing these links to ensure they persist across container updates and re-creations is difficult and error-prone. This makes it an unreliable solution for many users.

Anything else?

This request is similar in principle to Issue #5711 (linked for context, as comments are locked).

Originally created by @keyboardr on GitHub (Sep 23, 2025). ### Is there an existing issue for this? - [x] I have searched the existing open and closed issues ### Is your feature request related to a problem? Please describe The `MediaCover` directory is currently fixed within the main configuration folder for both Radarr and Sonarr. This design is problematic for users with limited storage on their root/OS drive, as this directory can grow to a significant size and exhaust available disk space. #### **Motivation** My device's setup is a common configuration on low-power devices like the ZimaBlade. My root drive, which holds the OS and application configurations, is a small **27 GB** drive. My actual media library is on a separate, much larger drive accessible over the network (NAS). I also have a local **1 TB SATA drive** dedicated to caches and temporary files. Most of my application config folders are under 100 MB. However, both Radarr and Sonarr are exceptions because their respective `MediaCover` folders can grow to several gigabytes, consuming a large portion of the limited space on my root drive. Allowing me to configure the path for the `MediaCover` directory would let me bind this folder to my dedicated 1 TB SATA drive. This would prevent the root drive from filling up and improve overall system stability. This is similar to the issue mentioned in issue #5711, which highlighted a similar need for configurable cache locations. ### Describe the solution you'd like Please add a new setting in the Radarr UI that allows users to specify an alternative path for the `MediaCover` directory. Given the shared architecture with Sonarr, it would be beneficial for this feature to be implemented across both applications. This would provide the flexibility needed for users with similar disk configurations to manage their storage effectively. ### Describe alternatives you've considered I have attempted to use `symlinks` and `hardlinks` to move the `MediaCover` directory. However, this approach poses several problems, especially when used within a containerized environment (like Docker). Correctly managing these links to ensure they persist across container updates and re-creations is difficult and error-prone. This makes it an unreliable solution for many users. ### Anything else? This request is similar in principle to [Issue #5711](https://github.com/Radarr/Radarr/issues/5711) (linked for context, as comments are locked).

deekerman

2026-02-20 00:12:20 -05:00

closed this issue
added the
Type: Feature Request

Status: Won't Fix
labels

deekerman commented

2026-02-20 00:12:21 -05:00

Author

Owner

@bakerboy448 commented on GitHub (Sep 23, 2025):

as noted on #5711, no plans to make this configurable at this time.

if you docker this can easily be handled by bind mounting /config/MediaCover

@bakerboy448 commented on GitHub (Sep 23, 2025): as noted on #5711, no plans to make this configurable at this time. if you docker this can easily be handled by bind mounting `/config/MediaCover`

deekerman commented

2026-02-20 00:12:21 -05:00

Author

Owner

@keyboardr commented on GitHub (Sep 23, 2025):

Thanks for the suggestion. Unfortunately, that doesn't work because /config still needs to be mounted on the root drive, and Docker gives parent directories precedence. As a result, bind mounting a subdirectory like /config/MediaCover does not override the parent /config mount. For example, the following doesn't work and still causes MediaCover to be created on the root drive:

    volumes:
      - type: bind
        source: /DATA/AppData/radarr/config
        target: /config
      - type: bind
        source: /mnt/Storage1/AppData/radarr/config/MediaCover
        target: /config/MediaCover

It's also worth noting that #5711 was filed 5 years ago, and in a significantly different environment. The size of media-related files has only increased since then (and single-board computers like this have become more popular), making the need for a native, configurable solution even more critical today.

@keyboardr commented on GitHub (Sep 23, 2025): Thanks for the suggestion. Unfortunately, that doesn't work because `/config` still needs to be mounted on the root drive, and Docker gives parent directories precedence. As a result, bind mounting a subdirectory like `/config/MediaCover` does not override the parent `/config` mount. For example, the following doesn't work and still causes `MediaCover` to be created on the root drive: ``` volumes: - type: bind source: /DATA/AppData/radarr/config target: /config - type: bind source: /mnt/Storage1/AppData/radarr/config/MediaCover target: /config/MediaCover ``` It's also worth noting that #5711 was filed 5 years ago, and in a significantly different environment. The size of media-related files has only increased since then (and single-board computers like this have become more popular), making the need for a native, configurable solution even more critical today.

deekerman commented

2026-02-20 00:12:22 -05:00

Author

Owner

@bakerboy448 commented on GitHub (Sep 23, 2025):

The size of media-related files has only increased

This has no relevance to this issue.

MediaCovers is a few gigs at most for 90something percent of users.

This is not going to be changed....unless you get sonarr to change upstream which is highly unlikely and will likely get a similar response.

@bakerboy448 commented on GitHub (Sep 23, 2025): > The size of media-related files has only increased This has no relevance to this issue. MediaCovers is a few gigs at most for 90something percent of users. This is not going to be changed....unless you get sonarr to change upstream which is highly unlikely and will likely get a similar response.

deekerman commented

2026-02-20 00:12:22 -05:00

Author

Owner

@mynameisbogdan commented on GitHub (Sep 24, 2025):

Thanks for the suggestion. Unfortunately, that doesn't work because /config still needs to be mounted on the root drive, and Docker gives parent directories precedence. As a result, bind mounting a subdirectory like /config/MediaCover does not override the parent /config mount. For example, the following doesn't work and still causes MediaCover to be created on the root drive:
    volumes:
      - type: bind
        source: /DATA/AppData/radarr/config
        target: /config
      - type: bind
        source: /mnt/Storage1/AppData/radarr/config/MediaCover
        target: /config/MediaCover
It's also worth noting that #5711 was filed 5 years ago, and in a significantly different environment. The size of media-related files has only increased since then (and single-board computers like this have become more popular), making the need for a native, configurable solution even more critical today.

But what container runtime? I didn't checked with docker yet, but I know it's works 100% in k8s having separate PVCs for these 2 mount points.

@mynameisbogdan commented on GitHub (Sep 24, 2025): > Thanks for the suggestion. Unfortunately, that doesn't work because `/config` still needs to be mounted on the root drive, and Docker gives parent directories precedence. As a result, bind mounting a subdirectory like `/config/MediaCover` does not override the parent `/config` mount. For example, the following doesn't work and still causes `MediaCover` to be created on the root drive: > > ``` > volumes: > - type: bind > source: /DATA/AppData/radarr/config > target: /config > - type: bind > source: /mnt/Storage1/AppData/radarr/config/MediaCover > target: /config/MediaCover > ``` > > It's also worth noting that [#5711](https://github.com/Radarr/Radarr/issues/5711) was filed 5 years ago, and in a significantly different environment. The size of media-related files has only increased since then (and single-board computers like this have become more popular), making the need for a native, configurable solution even more critical today. But what container runtime? I didn't checked with docker yet, but I know it's works 100% in k8s having separate PVCs for these 2 mount points.

deekerman commented

2026-02-20 00:12:22 -05:00

Author

Owner

@keyboardr commented on GitHub (Sep 24, 2025):

I'm using Docker. I haven't used k8s, but some Googling around suggests this is, in fact, one difference between the two.
Here's Google's AI summary: https://markdownpastebin.com/?id=5637db77295b4513af1ef66dffaf4215

@keyboardr commented on GitHub (Sep 24, 2025): I'm using Docker. I haven't used k8s, but some Googling around suggests this is, in fact, one difference between the two. Here's Google's AI summary: https://markdownpastebin.com/?id=5637db77295b4513af1ef66dffaf4215