Package Details: radarr

Git Clone URL: (read-only, click to copy)
Package Base: radarr
Description: Movie download automation for usenet and torrents.
Upstream URL:
Licenses: GPL3
Submitter: fryfrog
Maintainer: fryfrog (onedr0p)
Last Packager: fryfrog
Votes: 55
Popularity: 0.74
First Submitted: 2016-12-29 18:44 (UTC)
Last Updated: 2023-08-14 15:44 (UTC)

Dependencies (13)

Required by (9)

Sources (7)

Latest Comments

1 2 3 4 5 6 Next › Last »

MarsSeed commented on 2023-08-08 18:16 (UTC)

This package should be renamed to radarr-bin.

bkb commented on 2023-01-18 20:57 (UTC) (edited on 2023-02-10 19:26 (UTC) by bkb)

Add to servarr meta package group

qark commented on 2022-12-18 12:20 (UTC) (edited on 2022-12-18 12:24 (UTC) by qark)

@fryfrog I tried to make more or less conventional PKGBUILD. This works for me.

I followed build and package steps from Radarr's azure-pipelines.yml and files.

I guess this PKGBUILD could be applied to other *arr packages fixing name inconsistency.

fryfrog commented on 2022-05-04 16:29 (UTC)

The UMask= only controls the permissions of files and folders created by the software, it has no effect on existing files/folders. For a user per software w/ a shared group setup, a umask of 002 is appropriate, which results in folders w/ 775 and files 664. In a one user/group setup, using 022 would result in 755 for folders and 644 for files. But again, that is only newly created ones. You'd need to use chown and chmod to fix existing files or perhaps change the User= and Group= that radarr runs as.

You should hop on the Disord or /r/radarr sub-reddit and get real help, this is more appropriate for actual package issues.

alfzki commented on 2022-05-04 04:18 (UTC)

Could you guide me about which value should I use for UMask ? I tried 000 but Radarr still couldn't access nor read /home/user

zynex commented on 2021-08-22 18:38 (UTC) (edited on 2021-08-22 18:39 (UTC) by zynex)

You need to add environment strings to the systemd service. For non english locale the service will fail,


Adding those made the service working for me as stated in the GitHub issue.

johnny12 commented on 2021-08-04 10:43 (UTC)

Thanks for your quick reply!

You're right that there is a comment in those files (which is how I found out what was going on eventually) but I didn't bother to look in them initially because I wasn't aware of .tmpfiles and how it works at all. For me the most logical place to inform users would be in the official Sonarr/Radarr installation docs ( as an optional step 4 maybe?

Also I'm not 100% sure that running the software as a different user is the best way to go but because I also use FUSE mounts as that user this way all the software can access the mountpoints without any permission and ownership issues at all, this has simply always worked for me.

fryfrog commented on 2021-08-03 23:28 (UTC)

I think it is mainly because the other big way of doing it is w/ an .install file which creates and sets ownership of that folder. It isn't part of the package itself, since its all runtime stuff.

What would have helped you figure it out quicker? There is a #comment at the top of the tmpfile. Maybe an additional comment at the top of the service file?

Are you sure running it as a different user is the right move for you? A typical setup would probably override the Group= and UMask= so that your whole setup runs each software as its own user, but a shared group.

You're the first I know of across all the automation packages to really have this concern, but I don't mind improving things. I probably won't move away from .sysusers and .tmpfiles, but am always open to suggestions.