Arch Linux User Repository

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.

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

You need to add environment strings to the systemd service. For non english locale the service will fail, https://github.com/Radarr/Radarr/issues/5454.

Environment="LANG=en_GB.UTF-8"
Environment="LANGUAGE=en_GB:en"

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

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 (https://sonarr.tv/#downloads-v3-linux-archlinux) 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.

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.

@fryfrog I'm using a systemd override.conf (through systemctl edit radarr) to run Radarr (and Sonarr) as a different user. But because of the current tmpfiles with your package the file ownership is changed back to user radarr on system boot. To fix this for now I created a symbolic link called radarr.conf in /etc/tmpfiles.d/ linking to /dev/null as recommended in systemd man pages.

Is this how you would recommend users of your packages to fix this as well? And what's the use of setting permissions and ownership on /var/lib/radarr on every boot anyways? Once the package is installed I wouldn't expect something else to make changes to ownership/permissions. I never heard of tmpfiles and how to override them before so to me it was quite a puzzle solving this and I'm guessing more users might run into this.

@codeswhite, could you file a GitHub issue on Radarr? This is actually just a binary package. In the issue, it is worth mentioning that lidarr and readarr probably have the same issue.

Hi, i've noticed that the binary is compiled without the recommended exploit protection:

$ sudo checksec --proc=Radarr
...snip...
         COMMAND    PID RELRO           STACK CANARY            SECCOMP          NX/PaX        PIE                     FORTIFY
          Radarr    123 Partial RELRO   Canary found            No Seccomp       NX enabled    No PIE                  No

Those Partial RELRO and No PIE will result in a much easier arbitrary code execution exploit in the Radarr binary.

@jlanzobr: You can see radarr.service right up there in Sources and see that it is not using the mono binary. So instead, you need to stop using your custom service and use the one from the package. And you should switch to using a systemd override via systemctl edit when you want to modify parts of a .service file.

The systemd init file needs to be updated. The path (/usr/bin/mono --debug /usr/lib/radarr/bin/Radarr -nobrowser -data=/var/lib/radarr) is no longer correct.

@emphire: I'll probably never do a script because I find it annoying to control options in two places. But before tmpfiles, all my packages used the .install file. The systemd tmpfiles seemed like the suggested way, but I'll have another look. I don't care either way about that, would go w/ which ever is the "Arch" way there. You can do so much w/ tmpfiles, like links and folders and ownership and ... seems like its original intent doesn't match its capabilities. :)

Thanks for the response @fryfrog. Sorry it took me a while to get back. In the first line of the docs (https://www.freedesktop.org/software/systemd/man/tmpfiles.d.html), it says it's for volatile and temporary files. Using tmpfiles works but feels a bit hacky for this reason. I find the script file is handy to have for troubleshooting and running it manually instead of as a service. Thanks for maintaining the package.

Hey @emphire, check out the radarr-aphrodite package which has done a little of what you're talking about.

They added a package_info that lets me disable the built in updater and display a message, so I've put /usr/lib/radarr back to root:root which I think you'll appreciate. I'm waiting for that to come to the normal version, then I'll change it there too.

I moved all my packages from doing it in the .install file to using tmpfiles, I believe based on feedback from #archlinux-aur. Do you have some packaging guidelines that talk about doing this as part of the package vs via tmpfiles? I mean, the name obviously implies it... but I prefer it over doing it in the install precisely because it'll fix permissions more often if needed. And can be easily overridden by the user, unlike doing it from the package.

Finally, the script that runs mono that runs Radarr... that is one of the things that bugs me a little about the sonarr package I don't own, for some reason I just don't like it. Also, the next version of Radarr is dotnet core so doesn't even need Mono, you just run it directly. If you want to change some parameters, now you need to hunt down that file if they're mono options or edit the script if they're not... or don't edit the script because the package is going to blow it away, edit the .service.

Thanks for the feedback, if you can convince me of any of these specific changes, I'll be happy to make them and I'll then do it for all the packages I own. But at the very least, I think the most import part of it (the root:root ownership of /usr/lib/radarr) is coming eventually. :)

I made some tweaks to the package I was hoping you could include in the next release.

Here is the git diff: http://ix.io/2lup

The changes are:

1. The /usr/lib/radarr directory and its contents was owned by the radarr user. It's more secure to have it owned by root so radarr has readonly access to it so that variable data can be restricted to /var/lib/radarr.

2. tmpfiles.d is intended for temporary and volatile files. I moved the directory permissions setting into an install file - this also means that the permissions won't get set on every boot (just on install).

3. I added /usr/bin/radarr so it can be run in browser mode from the commandline as a regular user if desired (untested). It also cleans-up the .service file a little.

Here are the changed files if the diff is hard to read: PKGBUILD: http://ix.io/2luu radarr.install: http://ix.io/2luq radarr.service: http://ix.io/2lur radarr.sh: http://ix.io/2lus radarr.tmpfiles: http://ix.io/2lut

Thanks!

It didn't seem worth bumping pkgrel for, but if you refresh you'll get it. I did it to sonarr-develop, radarr-develop, sonarr-phantom and lidarr too. But radarr-aphrodite and lidarr-develop have switched to dotnet core so they don't need it.

Thanks for the great idea.

@joehillen: Great idea, will do! :)

Could you set SyslogIdentifier=radarr in the service file? Otherwise it shows as "mono" in the journal.

The mono command has the --debug option, not Radarr. You should post on reddit or get help in Discord to figure out what is going on, it doesn't do that on my system. Or you're welcome to just over ride the ExecStart= command via normal systemd methods.

Good luck.

Why radar has --debug flag in its command? It floods my system journal with 100000 log entries daily....

Whoops sorry I had not seen your reply.

Thank you very much!

At the top of the radarr.tmpfiles file is a comment, # Override this file with a modified version in /etc/tmpfiles.d/ which tells you how to over ride the file/folder ownership and links.

You've probably already figured out how to override the .service file, right?

Hello,

I'm using radarr with this PKGBUILD, but I have an issue.

I set radarr to use another user in the systemd service file, but the /usr/lib/radarr and /usr/var/radarr folders keep resetting to radarr:radarr. What do I need to change to fix this?

Thank you!

In the radarr.service file, Restart=on-failure is supposed to deal w/ that.

How do you make it happen? Using the restart built into Radarr? Or using the built in updater? I never use either, personally.

Any way to keep this from happening? Seems to happen when radarr tries to use it's built-in restarting mechanism rather than the systemd service:

$ ps aux | grep -i radarr
365:radarr    1582  2.5  0.3 2354004 218192 ?      Rsl  08:43   0:33 /usr/bin/mono --debug /usr/lib/radarr/Radarr.exe -nobrowser -data=/var/lib/radarr
436:radarr    3495 47.3  0.0 235356 56148 ?        Rl   09:05   0:01 /usr/bin/mono --debug /usr/lib/radarr/Radarr.exe /data=/var/lib/radarr /nobrowser /restart

Which causes the logs to fill up with messages that the IP radarr is using is already in use.

Thanks man!

The files had two versions in their name. I talked to @gallileo and he'll flip them from draft -> pre-release when they're ready. :)

Edit: File names are fixed now at least!

No worries, I haven't done a release here in awhile so I didn't want to break things. The only difference I see it not saying develop in the package name.

@onedr0p, the release up on github is a draft and weirdly named. I'm going to see what @gallileo says about it before updating. :/

@nicoulaj: Seems reasonable, updated this package and radarr-develop as well as a couple of the sonarr packages.

I think the service starts too early at boot, I can see this stack trace with the sonarr package that uses the exact systemd service file:

Sep 09 17:53:29 storm sonarr[852]: [Error] TaskExtensions: Task Error
Sep 09 17:53:29 storm sonarr[852]: [v2.0.0.5228] System.Net.WebException: DNS Name Resolution Failure: 'services.sonarr.tv'
Sep 09 17:53:29 storm sonarr[852]:   at NzbDrone.Common.Http.Dispatchers.ManagedHttpDispatcher.GetResponse (NzbDrone.Common.Http.HttpRequest request, System.Net.CookieContainer cookies) [0x0015e] in <8faeb593f49341d6a7a6d2c3c281887c>:0
Sep 09 17:53:29 storm sonarr[852]:   at NzbDrone.Common.Http.Dispatchers.FallbackHttpDispatcher.GetResponse (NzbDrone.Common.Http.HttpRequest request, System.Net.CookieContainer cookies) [0x000b5] in <8faeb593f49341d6a7a6d2c3c281887c>:0
Sep 09 17:53:29 storm sonarr[852]:   at NzbDrone.Common.Http.HttpClient.ExecuteRequest (NzbDrone.Common.Http.HttpRequest request, System.Net.CookieContainer cookieContainer) [0x0007e] in <8faeb593f49341d6a7a6d2c3c281887c>:0
Sep 09 17:53:29 storm sonarr[852]:   at NzbDrone.Common.Http.HttpClient.Execute (NzbDrone.Common.Http.HttpRequest request) [0x00008] in <8faeb593f49341d6a7a6d2c3c281887c>:0
Sep 09 17:53:29 storm sonarr[852]:   at NzbDrone.Common.Http.HttpClient.Get (NzbDrone.Common.Http.HttpRequest request) [0x00007] in <8faeb593f49341d6a7a6d2c3c281887c>:0
Sep 09 17:53:29 storm sonarr[852]:   at NzbDrone.Common.Http.HttpClient.Get[T] (NzbDrone.Common.Http.HttpRequest request) [0x00000] in <8faeb593f49341d6a7a6d2c3c281887c>:0
Sep 09 17:53:29 storm sonarr[852]:   at NzbDrone.Core.Update.UpdatePackageProvider.GetLatestUpdate (System.String branch, System.Version currentVersion) [0x0006c] in <f8c4a2c9e6194b509efc6018724d76df>:0
Sep 09 17:53:29 storm sonarr[852]:   at NzbDrone.Core.Update.CheckUpdateService.AvailableUpdate () [0x00016] in <f8c4a2c9e6194b509efc6018724d76df>:0
Sep 09 17:53:29 storm sonarr[852]:   at NzbDrone.Core.HealthCheck.Checks.UpdateCheck.Check () [0x000f7] in <f8c4a2c9e6194b509efc6018724d76df>:0
Sep 09 17:53:29 storm sonarr[852]:   at NzbDrone.Core.HealthCheck.HealthCheckService+<>c.<PerformHealthCheck>b__11_0 (NzbDrone.Core.HealthCheck.IProvideHealthCheck c) [0x00000] in <f8c4a2c9e6194b509efc6018724d76df>:0
Sep 09 17:53:29 storm sonarr[852]:   at System.Linq.Enumerable+SelectArrayIterator`2[TSource,TResult].ToList () [0x00014] in <55cb1ea97846413983036e5d2581cc09>:0
Sep 09 17:53:29 storm sonarr[852]:   at System.Linq.Enumerable.ToList[TSource] (System.Collections.Generic.IEnumerable`1[T] source) [0x0001f] in <55cb1ea97846413983036e5d2581cc09>:0
Sep 09 17:53:29 storm sonarr[852]:   at NzbDrone.Core.HealthCheck.HealthCheckService.PerformHealthCheck (NzbDrone.Core.HealthCheck.IProvideHealthCheck[] healthChecks) [0x00025] in <f8c4a2c9e6194b509efc6018724d76df>:0
Sep 09 17:53:29 storm sonarr[852]:   at NzbDrone.Core.HealthCheck.HealthCheckService.HandleAsync (NzbDrone.Core.Lifecycle.ApplicationStartedEvent message) [0x00000] in <f8c4a2c9e6194b509efc6018724d76df>:0
Sep 09 17:53:29 storm sonarr[852]:   at NzbDrone.Core.Messaging.Events.EventAggregator+<>c__DisplayClass6_2`1[TEvent].<PublishEvent>b__1 () [0x00035] in <f8c4a2c9e6194b509efc6018724d76df>:0
Sep 09 17:53:29 storm sonarr[852]:   at System.Threading.Tasks.Task.InnerInvoke () [0x0000f] in <815942dd495d4ccc954b977c1d4bee11>:0
Sep 09 17:53:29 storm sonarr[852]:   at System.Threading.Tasks.Task.Execute () [0x00000] in <815942dd495d4ccc954b977c1d4bee11>:0

It is followed by NetworkManager startup traces. I think the correct way is:

Wants=network-online.target
After=network-online.target

@RenVilo: Are you... running Arch Linux on your QNAP?

I'm running a QNAP NAS with QMono, SABNZBD, Sonarr and Radarr. Everything boots up and is fine except that in Sonarr and Radarr I can't add an Indexer to www.nzbfinder.ws or any other provider. I've tested this from my PC's version and it works fine. I've read that you have to add "Environment=MONO_TLS_PROVIDER=legacy" but I have no idea how to do this and seems Mono vs QMono might have a different file structure. I can't find "sonarr.service" or the path "usr/lib/systemd/system"

Info on my versions:

Sonarr: V2.0.0.5163 QMono: V5.12.0.266 (of TS-X19 but have tried other previous releases of V5. No V4 available) OS: QNAP Version 4.3.3.0546

https://www.dropbox.com/s/xiwzpfgj87mbibx/sonarr.debug.txt?dl=0

https://www.dropbox.com/s/y09dkbz5yq2nw02/sonarr.trace.txt?dl=0

Please can someone assist.

@pezz: That is great! I'll add that as a #comment in the file, thanks for figuring it out, it is sure to help someone in the future. And it's okay that your idea of correct isn't correct! ;)

Heh, your idea of "more correct" is different to mine.

Anyway, I deleted my previous comment as I did some reading up on tmpfiles and anything in /etc/tmpfilles.d overrides anything the package puts in /usr/lib so I can easily make my own setup permanent.

So it's a non-issue now, apologies for the noise.

@pezz, I haven't forgot about your plight... but I still think it is better for most users to have the directories owned correctly. I'm trying to think of a good way to support your use case too. I tried simply modifying the tmpfiles.d file locally, but it gets over written. I could go back to some logic in the install file, but using tmpfiles really simplified all the packages I maintain. Have you considered just doing your install the more correct way? You could also just modify the tmpfile and make it immutable, but that is a poor solution. :/

Also, I can't see your most recently reply here. :/

True, Sonarr's AUR package doesn't and I don't see many instances of users w/ permissions issues.

That said, you totally can (and should) setup your environment so daemons run as their own users and files are owned the right way. You just use a shared group like media and a file permission of umask 002 which is 775 for folders and 664 for files. My Radarr runs as radarr, Sonarr as sonarr, NZBGet as nzbget, rTorrent as rtorrent and Plex as plex. I do use systemd unit over rides to change the group, they're all in a shared group, all setup to create files and folders w/ the right permissions. You need to start off w/ the right permissions, so a chown and chmod to get things sorted at the start. I use something like find /path -type f -exec chmod 664 '{}' ';' to fix files, d and 775 to fix folders.

I have Sonarr, Radarr, Kodi and some other things that all run as the same user so that they can interact with the media and storage directories.

Can't have 2 things (especially in the case of Sonarr and Radarr) run as 2 different users and expect them all to have a good time, I expect many people do the same.

Sonarr does not change the permissions of /var/lib/sonarr after a package update.

@pezz, I added the ownership of /usr/lib and /var/lib recently, mainly to fix most users setups. Though I think it still did it as part of post upgrade. Can you tell me a little about why you run as a different user? I'd like this package to work well for most people and I'm not sure which route would be better. Do more people bone their permissions and have issues or do more people run it as another user? :/

I'd like to see /var/lib/radarr removed from tmpfiles.

Some of us run Radarr as a different user and it fails to start because of it chowning that directory back to the radarr user.

Perhaps set the initial permissions in post.install but then repsect the user's choice from then on.

Cheers.

@smmalis37, have you tested Radarr w/o libgdiplus? It was probably just part of Sonarr's PKGBUILD when I copied it to use for Radarr. If you've tested and know it isn't needed, I can remove it. Otherwise, I'll test in the next few days and see what I find.

libgdiplus is a dependency of mono, not sonarr/radarr directly. There's already an issue on the mono package to move libgdiplus to an optional dependency (https://bugs.archlinux.org/task/46961?project=1&string=mono).