Package Details: radarr-bin 5.14.0.9383-9

Git Clone URL: https://aur.archlinux.org/radarr-bin.git (read-only, click to copy)
Package Base: radarr-bin
Description: Movie organizer/manager for usenet and torrent users
Upstream URL: https://radarr.video
Licenses: GPL-3.0-or-later
Groups: servarr-bin
Conflicts: radarr
Provides: radarr
Submitter: txtsd
Maintainer: txtsd (fryfrog)
Last Packager: txtsd
Votes: 56
Popularity: 0.88
First Submitted: 2024-10-15 08:17 (UTC)
Last Updated: 2024-11-15 10:20 (UTC)

Dependencies (21)

Required by (17)

Sources (8)

Pinned Comments

txtsd commented on 2024-10-21 03:38 (UTC) (edited on 2024-10-30 12:50 (UTC) by txtsd)

Alternate versions

radarr (source version of this package)
radarr-develop (develop branch)
radarr-develop-bin (binary version of the develop branch)
radarr-nightly-bin (nightly builds)

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 Next › Last »

fryfrog commented on 2018-04-29 21:41 (UTC)

@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! ;)

pezz commented on 2018-04-29 15:38 (UTC)

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.

fryfrog commented on 2018-04-29 14:20 (UTC)

@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. :/

fryfrog commented on 2018-04-19 14:53 (UTC)

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.

pezz commented on 2018-04-19 14:08 (UTC)

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.

fryfrog commented on 2018-04-19 12:18 (UTC)

@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? :/

pezz commented on 2018-04-19 03:07 (UTC)

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.

fryfrog commented on 2018-04-19 02:19 (UTC)

@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.

smmalis37 commented on 2018-04-18 20:41 (UTC)

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).

« First ‹ Previous 1 2 3 4 5 6 7 Next › Last »