Package Details: sonarr 4.0.14.2939-1

Git Clone URL: https://aur.archlinux.org/sonarr.git (read-only, click to copy)
Package Base: sonarr
Description: Smart PVR for newsgroup and torrent users
Upstream URL: https://sonarr.tv
Licenses: GPL-3.0-or-later
Groups: servarr
Submitter: txtsd
Maintainer: txtsd (fryfrog)
Last Packager: txtsd
Votes: 6
Popularity: 0.54
First Submitted: 2024-10-15 07:11 (UTC)
Last Updated: 2025-03-17 19:25 (UTC)

Dependencies (22)

Required by (17)

Sources (5)

Pinned Comments

mkomko commented on 2024-11-15 06:59 (UTC)

PSA: If you receive exceptions like "System.IO.IOException: Read-only file system" when Sonarr is importing files after updating to 4.0.10.2544, and you use your home directory for downloaded files (which is advised against), you can either move file management out of your home directory or do something like the following:

$ sudo systemctl edit sonarr

[Service]
# Allow home directory path to be writable again
ReadWritePaths=/home/user/media

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

Alternate versions

sonarr-bin (binary version of this package)
sonarr-develop (develop branch)
sonarr-develop-bin (binary version of the develop branch)

Latest Comments

1 2 Next › Last »

alan.mckinnon commented on 2025-01-08 13:08 (UTC)

@fryfrog sure thing, soon as I figure discord out. 20+ years in this game and never used Discord :-D

fryfrog commented on 2025-01-07 16:18 (UTC)

@alan.mckinnon, hop on Discord and we'll figure out whats wrong and get it sorted.

alan.mckinnon commented on 2025-01-07 15:27 (UTC)

Hi,

Any breaking changes since Dec 22? I notice this issue on most of the *arrs now. I was away from Dec 22 till Jan 5, and stuff worked fine before I left.

After pacman -Syu and updating all arrs, now they won't manually import. Importing one file does move the file, then writes an .nfo file and then the task never completes. It shows up in System -> Tasks and just stays there. Importing more than one file does move the first, then same as above.

Nothing sensible shows up in the trace logs or systemd journal. incomplete, downloaded files and destination are all on NFS on FreeNAS, this setup has worked for years.

Any ideas? System is fully updated Sonarr is latest here: pkgver=4.0.12.2823 pkgrel=1

Can provide all logs and info if needed, didn't post them yet to avoid clutter

fryfrog commented on 2025-01-01 17:24 (UTC)

@einappo, you could override -data w/ the path to your actual appdata location instead of using a symlink. I don't think it would fix the issue you're reporting, but it would remove a layer of indirection.

elnappo commented on 2025-01-01 15:26 (UTC) (edited on 2025-01-01 15:38 (UTC) by elnappo)

Setting StateDirectory=sonarr breaks Sonarr and all other *arr's for me because /var/lib/sonarr is a symlink pointing to another disk. Overriding the unit with StateDirectory= fixes it. There is already a systemd issue https://github.com/systemd/systemd/issues/25097

Furthermore the LogsDirectory= issue has to be fixed in all *arr packages including -bin

zayatura commented on 2024-12-24 17:29 (UTC) (edited on 2024-12-24 17:32 (UTC) by zayatura)

Does it work if you use an override to set it to nothing?

Yes, it works. That's what I also did to get rid of the warning. I guess we don't need systemd managing the log files.

Thanks for maintaining this package!

Note that you seem to have forgotten to update the pkgrel value of this package after updating the service files, so my AUR helper won't see the package as updated.

zayatura commented on 2024-12-24 17:27 (UTC)

Thanks for the report. Does it work if you use an override to set it to nothing?

Np. Yes, that's what I also did to get rid of the warning.

Thanks for maintaining this package!

fryfrog commented on 2024-12-23 19:29 (UTC)

Hey @zayatura, the LogsDirectory= was set to sonarr previously and a systemd update caused the too many levels of symbolic links issue. I "fixed" them all by setting it to /var/lib/sonarr/logs which only actually fixed it because it was invalid. I guess we need to go back and remove the line entirely!

Thanks for the report. Does it work if you use an override to set it to nothing?

zayatura commented on 2024-12-23 19:10 (UTC)

The current systemd service file is invalid, because it sets LogsDirectory=/var/lib/sonarr/logs; starting the service logs the warning 'LogsDirectory= path is absolute, ignoring'. The documentation clearly states that the value set must not be an absolute path, so it checks out.

Not sure if because of this specific issue with the service file, but my service got into a restart loop since the last update:

systemd[1]: Started Sonarr Daemon.
(Sonarr)[2448633]: sonarr.service: Failed to set up special execution directory in /var/log: Too many levels of symbolic links
(Sonarr)[2448633]: sonarr.service: Failed at step LOGS_DIRECTORY spawning /usr/lib/sonarr/bin/Sonarr: Too many levels of symbolic links
systemd[1]: sonarr.service: Main process exited, code=exited, status=240/LOGS_DIRECTORY
systemd[1]: sonarr.service: Failed with result 'exit-code'.

Thought it got out of it after around 10k retries.

mkomko commented on 2024-11-15 06:59 (UTC)

PSA: If you receive exceptions like "System.IO.IOException: Read-only file system" when Sonarr is importing files after updating to 4.0.10.2544, and you use your home directory for downloaded files (which is advised against), you can either move file management out of your home directory or do something like the following:

$ sudo systemctl edit sonarr

[Service]
# Allow home directory path to be writable again
ReadWritePaths=/home/user/media

1 2 Next › Last »