Arch Linux User Repository

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

Alternate versions

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

@CommanderRedYT I'm also seeing this, but only for a single series. I'll try to find out why it's happening.

ffmpeg isn't a dependency because the ffprobe included comes with sonarr.

Does anyone else also face this problem?

[Error] DetectSample: Failed to get runtime from the file, make sure ffprobe is available

I believe this might be caused by the hardening flags in the service file, but I am not entirely sure.

Also, it might make sense to add ffmpeg to optional dependencies

@MoonSlayer It literally tells you what to do at the top of the service file.

You need to remove the "ProtectHome=read-only" flag in the service file, it provides unnecessary blocking of permissions when someone intensionally wants to interact with the home directory, or just put a note somewhere for users unfamiliar with SystemD. I was almost pulling my hair out when i realized SystemD is ignoring my systemctl edits, and i had to directly modify the service file.

@Bosnia, ever since the move to building I've had to do most of them in a chroot via extra-x86_64-build, maybe that'll get you sorted? I just built it that way and it was fine.

You could also switch to the sonarr-bin package.

I'm running into a dotnet-sdk issue when installing the latest version.

requested SDK version: 6.0.113
global.json file: /home/guitar/.cache/yay/sonarr/src/Sonarr-4.0.15.2941/global.json

Installed SDKs:
6.0.428 [/usr/share/dotnet/sdk]

Install the [6.0.113] .NET SDK or update [/home/guitar/.cache/yay/sonarr/src/Sonarr-4.0.15.2941/global.json] to match an installed SDK.

Learn about SDK resolution:
https://aka.ms/dotnet/sdk-not-found
==> ERROR: A failure occurred in prepare().
 Aborting...
-> error making: sonarr-exit status 4
-> Failed to install the following packages. Manual intervention is required:
sonarr - exit status 4

When I edited the global.json file to point to the SDK version that does get installed, I end up running into a yarn issue... not sure if it's related to dotnet.

error rimraf@6.0.1: The engine "node" is incompatible with this module. Expected version "20 || >=22". Got "21.6.2"
error Found incompatible module.

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

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

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

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