search

Sonarr / Sonarr

Smart PVR for newsgroup and bittorrent users.
https://sonarr.tv
GNU General Public License v3.0
10.06k stars 1.22k forks source link

MacOS 10.15 - Full Disk Access Required #3168

Closed baz1860 closed 3 years ago

baz1860 commented 4 years ago

Describe the bug The next version of MacOS (10.15) requires physical interaction by the user to allow access to the either the file system, or to any networked shares. At the moment Sonarr just accepts being refused access to the filesystem/network shares and doesn't trigger any option to allow access on the desktop.

Logs

19-6-14 21:40:59.0|Trace|MediaInfo|Read a total of 89270 bytes (0.0%)
19-6-14 21:40:59.0|Debug|AggregateLanguage|Using language: English
19-6-14 21:40:59.0|Debug|Parser|Parsing string 'Too.Old.to.Die.Young.S01E04.1080p.WEB.H264-METCON'
19-6-14 21:40:59.0|Trace|Parser|^(?<title>.+?)(?:(?:[-_\W](?<![()\[!]))+S?(?<season>(?<!\d+)(?:\d{1,2})(?!\d+))(?:[ex]|\W[ex]){1,2}(?<episode>\d{2,3}(?!\d+))(?:(?:\-|[ex]|\W[ex]|_){1,2}(?<episode>\d{2,3}(?!\d+)))*)\W?(?!\\)
19-6-14 21:40:59.0|Debug|Parser|Episode Parsed. Too Old to Die Young - S01E04 
19-6-14 21:40:59.0|Debug|Parser|Language parsed: English
19-6-14 21:40:59.0|Debug|QualityParser|Trying to parse quality for Too.Old.to.Die.Young.S01E04.1080p.WEB.H264-METCON
19-6-14 21:40:59.0|Debug|Parser|Quality parsed: WEBDL-1080p v1
19-6-14 21:40:59.0|Debug|Parser|Release Group parsed: METCON
19-6-14 21:40:59.0|Trace|AggregateQuality|Finding quality. Source: Web. Resolution: 1080
19-6-14 21:40:59.0|Debug|AggregateQuality|Using quality: WEBDL-1080p v1
19-6-14 21:40:59.0|Debug|AbsoluteEpisodeNumberSpecification|Series type is not Anime, skipping check
19-6-14 21:40:59.0|Trace|ConfigService|Using default config value for 'episodetitlerequired' defaultValue:'Always'
19-6-14 21:40:59.0|Trace|ConfigService|Using default config value for 'skipfreespacecheckwhenimporting' defaultValue:'False'
19-6-14 21:40:59.0|Debug|SameFileSpecification|No existing episode file, skipping
19-6-14 21:40:59.0|Debug|VideoFileInfoReader|Getting media info from /Volumes/ScratchDrive/sonarr/Too.Old.to.Die.Young.S01E04.1080p.WEB.H264-METCON/Too.Old.to.Die.Young.S01E04.1080p.WEB.H264-METCON.mkv
19-6-14 21:40:59.1|Trace|MediaInfo|Read file offset 0-32768 (32768 bytes)
19-6-14 21:40:59.1|Trace|MediaInfo|Read file offset 4580239640-4580296142 (56502 bytes)
19-6-14 21:40:59.1|Trace|MediaInfo|Read a total of 89270 bytes (0.0%)
19-6-14 21:40:59.1|Debug|DetectSample|Runtime is over 90 seconds
19-6-14 21:40:59.1|Trace|ConfigService|Using default config value for 'downloadclientworkingfolders' defaultValue:'_UNPACK_|_FAILED_'
19-6-14 21:40:59.1|Trace|ConfigService|Using default config value for 'downloadpropersandrepacks' defaultValue:'PreferAndUpgrade'
19-6-14 21:40:59.1|Debug|ImportDecisionMaker|File accepted
19-6-14 21:40:59.1|Debug|Parser|Parsing string 'Too.Old.to.Die.Young.S01E04.1080p.WEB.H264-METCON'
19-6-14 21:40:59.1|Trace|Parser|^(?<title>.+?)(?:(?:[-_\W](?<![()\[!]))+S?(?<season>(?<!\d+)(?:\d{1,2})(?!\d+))(?:[ex]|\W[ex]){1,2}(?<episode>\d{2,3}(?!\d+))(?:(?:\-|[ex]|\W[ex]|_){1,2}(?<episode>\d{2,3}(?!\d+)))*)\W?(?!\\)
19-6-14 21:40:59.1|Debug|Parser|Episode Parsed. Too Old to Die Young - S01E04 
19-6-14 21:40:59.1|Debug|Parser|Language parsed: English
19-6-14 21:40:59.1|Debug|QualityParser|Trying to parse quality for Too.Old.to.Die.Young.S01E04.1080p.WEB.H264-METCON
19-6-14 21:40:59.1|Debug|Parser|Quality parsed: WEBDL-1080p v1
19-6-14 21:40:59.1|Debug|Parser|Release Group parsed: METCON
19-6-14 21:40:59.1|Trace|PreferredWordService|Calculating preferred word score for 'Too.Old.to.Die.Young.S01E04.1080p.WEB.H264-METCON'
19-6-14 21:40:59.1|Debug|EpisodeFileMovingService|Moving episode file: /Volumes/ScratchDrive/sonarr/Too.Old.to.Die.Young.S01E04.1080p.WEB.H264-METCON/Too.Old.to.Die.Young.S01E04.1080p.WEB.H264-METCON.mkv to /Volumes/Plex/TV/Too Old to Die Young/Season 1/Too Old to Die Young - 1x04 - Volume 4 - The Tower WEBDL-1080p METCON.mkv
19-6-14 21:40:59.1|Debug|DiskTransferService|Move [/Volumes/ScratchDrive/sonarr/Too.Old.to.Die.Young.S01E04.1080p.WEB.H264-METCON/Too.Old.to.Die.Young.S01E04.1080p.WEB.H264-METCON.mkv] > [/Volumes/Plex/TV/Too Old to Die Young/Season 1/Too Old to Die Young - 1x04 - Volume 4 - The Tower WEBDL-1080p METCON.mkv]
19-6-14 21:40:59.1|Trace|SymbolicLinkResolver|Checking path /Volumes/Plex/TV/Too Old to Die Young/Season 1/Too Old to Die Young - 1x04 - Volume 4 - The Tower WEBDL-1080p METCON.mkv for symlink returned error ENOENT, assuming it's not a symlink.
19-6-14 21:40:59.1|Trace|DiskTransferService|Attempting to move hardlinked backup.
19-6-14 21:40:59.1|Trace|DiskProviderBase|Deleting file: /Volumes/ScratchDrive/sonarr/Too.Old.to.Die.Young.S01E04.1080p.WEB.H264-METCON/Too.Old.to.Die.Young.S01E04.1080p.WEB.H264-METCON.mkv.backup~
19-6-14 21:40:59.1|Warn|ImportApprovedEpisodes|Couldn't import episode /Volumes/ScratchDrive/sonarr/Too.Old.to.Die.Young.S01E04.1080p.WEB.H264-METCON/Too.Old.to.Die.Young.S01E04.1080p.WEB.H264-METCON.mkv

[v3.0.1.513] System.UnauthorizedAccessException: Access to the path is denied.
  at System.IO.File.Move (System.String sourceFileName, System.String destFileName) [0x00117] in /Users/builder/jenkins/workspace/build-package-osx-mono/2018-08/external/bockbuild/builds/mono-x64/mcs/class/corlib/System.IO/File.cs:330 
  at NzbDrone.Common.Disk.DiskProviderBase.MoveFileInternal (System.String source, System.String destination) [0x00000] in M:\BuildAgent\work\63739567f01dbcc2\src\NzbDrone.Common\Disk\DiskProviderBase.cs:240 
  at NzbDrone.Mono.Disk.DiskProvider.MoveFileInternal (System.String source, System.String destination) [0x00076] in M:\BuildAgent\work\63739567f01dbcc2\src\NzbDrone.Mono\Disk\DiskProvider.cs:189 
  at NzbDrone.Common.Disk.DiskProviderBase.MoveFile (System.String source, System.String destination, System.Boolean overwrite) [0x000e1] in M:\BuildAgent\work\63739567f01dbcc2\src\NzbDrone.Common\Disk\DiskProviderBase.cs:227 
  at NzbDrone.Common.Disk.DiskTransferService.TryMoveFileTransactional (System.String sourcePath, System.String targetPath, System.Int64 originalSize, NzbDrone.Common.Disk.DiskTransferVerificationMode verificationMode) [0x0008f] in M:\BuildAgent\work\63739567f01dbcc2\src\NzbDrone.Common\Disk\DiskTransferService.cs:507 
  at NzbDrone.Common.Disk.DiskTransferService.TransferFile (System.String sourcePath, System.String targetPath, NzbDrone.Common.Disk.TransferMode mode, System.Boolean overwrite, NzbDrone.Common.Disk.DiskTransferVerificationMode verificationMode) [0x003cc] in M:\BuildAgent\work\63739567f01dbcc2\src\NzbDrone.Common\Disk\DiskTransferService.cs:329 
  at NzbDrone.Common.Disk.DiskTransferService.TransferFile (System.String sourcePath, System.String targetPath, NzbDrone.Common.Disk.TransferMode mode, System.Boolean overwrite, System.Boolean verified) [0x0000e] in M:\BuildAgent\work\63739567f01dbcc2\src\NzbDrone.Common\Disk\DiskTransferService.cs:213 
  at NzbDrone.Core.MediaFiles.EpisodeFileMovingService.TransferFile (NzbDrone.Core.MediaFiles.EpisodeFile episodeFile, NzbDrone.Core.Tv.Series series, System.Collections.Generic.List`1[T] episodes, System.String destinationFilePath, NzbDrone.Common.Disk.TransferMode mode) [0x00129] in M:\BuildAgent\work\63739567f01dbcc2\src\NzbDrone.Core\MediaFiles\EpisodeFileMovingService.cs:119 
  at NzbDrone.Core.MediaFiles.EpisodeFileMovingService.MoveEpisodeFile (NzbDrone.Core.MediaFiles.EpisodeFile episodeFile, NzbDrone.Core.Parser.Model.LocalEpisode localEpisode) [0x0005f] in M:\BuildAgent\work\63739567f01dbcc2\src\NzbDrone.Core\MediaFiles\EpisodeFileMovingService.cs:81 
  at NzbDrone.Core.MediaFiles.UpgradeMediaFileService.UpgradeEpisodeFile (NzbDrone.Core.MediaFiles.EpisodeFile episodeFile, NzbDrone.Core.Parser.Model.LocalEpisode localEpisode, System.Boolean copyOnly) [0x0017c] in M:\BuildAgent\work\63739567f01dbcc2\src\NzbDrone.Core\MediaFiles\UpgradeMediaFileService.cs:76 
  at NzbDrone.Core.MediaFiles.EpisodeImport.ImportApprovedEpisodes.Import (System.Collections.Generic.List`1[T] decisions, System.Boolean newDownload, NzbDrone.Core.Download.DownloadClientItem downloadClientItem, NzbDrone.Core.MediaFiles.EpisodeImport.ImportMode importMode) [0x0028e] in M:\BuildAgent\work\63739567f01dbcc2\src\NzbDrone.Core\MediaFiles\EpisodeImport\ImportApprovedEpisodes.cs:111

System Information

markus101 commented 4 years ago

Sonarr has no means to ask when it's trying to access the drive and that's not something that will happen, so it not triggering anything on the desktop is completely expected behaviour.

Is this something Sonarr can ask for when it's first installed or would it need to be done for every version?

baz1860 commented 4 years ago

With it being a first beta, it’s unclear as to whether each upgrade would need this but previous practice for MacOS has meant that full disk access is only required on first launch of whichever app requires it.

Some apps (Calibre/NZBGet specifically) are already triggering the update without an update so it seems currently that apps with a GUI will automatically trigger the check that you want to allow access.

It’s possible this is actually going to be something that mono will need to patch rather than Sonarr, but currently as Sonarr can’t access any drives it can’t see/move/rename any episodes and isn’t updating any shows.

Sent with GitHawk

ontologyrecapitulates commented 4 years ago

Create a MS git account just to comment on this specific bug. What a pain,

I can confirm this is happening on Mac OS Catalina10.15 beta. Sonarr cannot rename files in the download folder Sonarr cannot move files to an external drive

I have given Sonarr "Full Disk Access" in System Preference/Security & Privacy/Full Disk Access Sonarr appears to have "Full Disk Access" in System Preference/Security & Privacy/Files & Folders

Does anyone have a functioning work around?

formerandroider commented 4 years ago

@ontologyrecapitulates the only workaround at the moment is to manually execute the Sonarr.exe file from the command line with mono.

ontologyrecapitulates commented 4 years ago

@formerandroider Thanks for your help. I've tried three different guesses in the osx terminal and can't translate into a woking command. Can you give me the actual one that works? (I'm too embarrassed by my guesses to list them here).

georgeperez commented 4 years ago

@ontologyrecapitulates mono /Applications/Sonarr.app/Contents/MacOS/NzbDrone.exe worked for me.

narmbrister commented 4 years ago

Been trying to find a workaround for ages that avoids having terminal open while running Sonarr, and I finally found one! Granting full disk access to sh (/bin/sh) has completely fixed it for me.

Note: I didn't need to grant disk access to any other apps/files like Sonarr or mono-sgen64.

galli-leo commented 4 years ago

Can you please verify that this is still an issue on the latest developer beta (19A546d)? I tested this with Radarr and was able to both import movies to a USB drive as well as import from the default Downloads directory without an issue. I did not grant any application full disk access and launched the Radarr app normally.

dkids commented 4 years ago

It does seem to be working now, after killing and re-starting the Radarr process. Earlier, before re-starting, it was not importing downloads nor recognizing files that I'd moved into place manually (by recognizing I mean running "update move info and scan disk" after the file was moved to the proper directory).

I would be fine with closing this ticket and re-opening if there are problems with the actual Catalina release.

Thank you!

ewancluckie commented 4 years ago

Still getting issues on the latest Beta (19A573a) - The same issues with permissions to access the file system."Unable to parse media info from file: xxx/xxx/xxx: Access to path "xxx/xxx/xxx" is denied."

System.UnauthorizedAccessException

Has anyone found a permanent solution?

formerandroider commented 4 years ago

@ewancluckie @narmbrister's solution of permitting full disk access to /bin/sh works consistently for me, otherwise there's nothing I can suggest. Really, changes need to be made to allow for Sonarr to show the relevant permission request modals.

ewancluckie commented 4 years ago

@ewancluckie @narmbrister's solution of permitting full disk access to /bin/sh works consistently for me, otherwise there's nothing I can suggest. Really, changes need to be made to allow for Sonarr to show the relevant permission request modals.

@formerandroider Sorry for what is probably a very basic question, but how do you do that exactly?

formerandroider commented 4 years ago

@ewancluckie System Preferences->Security & Privacy->Privacy [Tab]->Full disk access [Sidenav]->[Click padlock to unlock settings]->+ [Button]->Press Shift+Cmd+. [period] to show hidden files->Choose your root drive (generally Macintosh HD) from the dropdown->Select the bin directory->Select the sh binary->Click Open->Restart Sonarr.

galli-leo commented 4 years ago

@ewancluckie Where exactly is your file located? e.g. on an external drive? I tried with the latest beta and it still works fine for me, for accessing Downloads folder and a different partition of my internal drive (haven't tested external yet).

@formerandroider AFAIK, there is no way to show a permissions dialog, the only thing we can do is tell people to add /bin/sh to Full Disk Access (or if we had a native wrapper in the app package, the Sonarr.app itself).

ourcore commented 4 years ago

My torrents are downloaded to my user downloads folder and moved to an external drive, which started failing when I updated to 10.15. Adding the /bin/sh file to have full disk access fixed my issue.

ewancluckie commented 4 years ago

@galli-leo Yep. Files are located on an external disk and I'm running the latest beta. The solution from @formerandroider and @narmbrister has worked for me. Still getting some pop-up warnings from mono occasionally, but both Radarr and Sonarr are working again.

dany20mh commented 4 years ago

So my setup is kind of not working, I can open the app with terminal, and I also have sh, zsh, mono and the Sonnar app approved for read/write in privacy settings. My files are locate on a drive that gets created by NetDrive, and if I move a file from finder, it will work perfectly fine and it will write to the drive, but Sonnar won't move downloaded file and in the terminal showing error message that the drive doesn't have any space which is inaccurate. I tried V2 and V3 with same result and I'm not sure what else I'm missing. Is anyone know how can I fix that?

formerandroider commented 4 years ago

@dany20mh have you tried enabling the Skip Free Space Check advanced option (under Media Management)?

dany20mh commented 4 years ago

@formerandroider Thanks, that option was only in V3 and it fix my issue with drive space issue.

dberlin commented 4 years ago

One correct and complete solution: Use mono's mkbundle to generate a real executable. Add full disk access to that.

(This currently has to be redone on updates, but could be made part of the update process).

On a mac, go to /Applications/Sonarr.app/Contents/MacOS

run mkbundle --simple -o Sonarr nzbdrone.exe

(If you are using v3, use Sonarr.exe)

It should generate a standalone executable named Sonarr that can be added for full disk access and work properly.

It is a real macos x64 executable that bundles all the pieces + mono into a single exe.

Of course, right now you have to run it separately. However, that should be fixable in sonarr itself, since mkbundle works correctly on every platform mono supports.

cjattard commented 4 years ago

Just a thought - As this bug also displays itself in the Production release of macOS Catalina should we update the title and elevate the label of this bug from suboptimal to Bug? Thanks

cmbv commented 4 years ago

I've tried the methods above and combinations of all suggestions and it will only work with adding sh to full disk access, which I'm not going to do due to the security implications.

I currently have Sonarr running via command line using a launch agent I created:

cd /Applications/Sonarr.app/Contents/MacOS/
mono Sonarr.exe

The launch agent is formatted as follows:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
   <key>Label</key>
   <string>Sonarr</string>
   <key>ProgramArguments</key>
   <array><string>/Applications/SonarrLaunch/sonarrStart.sh</string></array>
   <key>RunAtLoad</key>
   <true/>
   <key>KeepAlive</key>
  <true/>
</dict>
</plist>

No problems with the app staying open, so these work as expected.

I've added combinations of the Sonarr.app, Sonarr executable file, mono-sgen64 to full disk access. Still having access errors:

Import failed, path does not exist or is not accessible by Sonarr

Absolutely baffled. Open to suggestions, but it looks like I'll be waiting for an update.

formerandroider commented 4 years ago

@cmbv the issue is that none of them are actually the process that’s running the software. In all of these scenarios, sh is the root process.

I’ve been trying to get a native macOS wrapper application created, but I haven’t been having much success.

cmbv commented 4 years ago

@cmbv the issue is that none of them are actually the process that’s running the software. In all of these scenarios, sh is the root process.

I’ve been trying to get a native macOS wrapper application created, but I haven’t been having much success.

@formerandroider Yeah, I completely agree. I just can’t understand why some seem to have had success with other methods outside of granting full disk access to sh.

formerandroider commented 4 years ago

I think the difference is those that are having media copied to external drives, vs those that are just having it copied/moved from the Downloads folder. macOS is more strict regarding access to removable stroage.

That is just a guess, though.

ontologyrecapitulates commented 4 years ago

" that are having media copied to external drives"

Agree. The files land in a subfolder of Downloads just fine. Where it falls over is the rename/move to the external RAID.

narmbrister commented 4 years ago

@cmbv thanks for pointing out the security concerns. Unfortunately I know just enough about these things to make hacky fixes, but not enough to know why I shouldn't haha. I get the basic idea behind restricting disk access for applications, but would you mind telling me what I've opened myself up to by granting it to /bin/sh specifically?

formerandroider commented 4 years ago

@narmbrister technically and theoretically speaking, it would now allow any shell script or application that runs via a shell script full disk access, which does sorta defeat the purpose of the restrictions in the first place.

narmbrister commented 4 years ago

@formerandroider got it. Which makes it even more bizarre that you can't manually grant access to specific folders (unless I'm missing something). It seems odd that my internal drive is fair game, but god forbid an application should be able to access my external drive with all my precious tv shows!

jonlbauer commented 4 years ago

Ok, so... is there a game plan for actually fixing this without leaving our system vulnerable?

I'm surprised that this isn't a super busy entry... I know that there's a smaller subset of folks on Mac's using Sonarr, but still. :-)

ldexterldesign commented 4 years ago

FYI

Granting full disk access to /bin/sh fixes manual import but doesn't fix automatic import which stays broken for me (see update)

My log errors if anyone can help:

19-10-20 02:19:04.4|Error|VideoFileInfoReader|Unable to parse media info from file: /Users/ldexterldesign/Downloads/-qbittorrent/-complete/Gardeners.World.S52E32.480p.x264-mSD[eztv].mkv

[v3.0.3.645] System.UnauthorizedAccessException: Access to the path "/Users/ldexterldesign/Downloads/-qbittorrent/-complete/Gardeners.World.S52E32.480p.x264-mSD[eztv].mkv" is denied.
  at System.IO.FileStream..ctor (System.String path, System.IO.FileMode mode, System.IO.FileAccess access, System.IO.FileShare share, System.Int32 bufferSize, System.Boolean anonymous, System.IO.FileOptions options) [0x00259] in /Users/builder/jenkins/workspace/build-package-osx-mono/2019-06/external/bockbuild/builds/mono-x64/mcs/class/corlib/System.IO/FileStream.cs:274 
  at System.IO.FileStream..ctor (System.String path, System.IO.FileMode mode, System.IO.FileAccess access, System.IO.FileShare share, System.Int32 bufferSize, System.Boolean isAsync, System.Boolean anonymous) [0x00000] in /Users/builder/jenkins/workspace/build-package-osx-mono/2019-06/external/bockbuild/builds/mono-x64/mcs/class/corlib/System.IO/FileStream.cs:149 
  at System.IO.FileStream..ctor (System.String path, System.IO.FileMode mode, System.IO.FileAccess access) [0x00000] in /Users/builder/jenkins/workspace/build-package-osx-mono/2019-06/external/bockbuild/builds/mono-x64/mcs/class/corlib/System.IO/FileStream.cs:86 
  at (wrapper remoting-invoke-with-check) System.IO.FileStream..ctor(string,System.IO.FileMode,System.IO.FileAccess)
  at NzbDrone.Common.Disk.DiskProviderBase.OpenReadStream (System.String path) [0x0001b] in M:\BuildAgent\work\63739567f01dbcc2\src\NzbDrone.Common\Disk\DiskProviderBase.cs:414 
  at NzbDrone.Core.MediaFiles.MediaInfo.VideoFileInfoReader.GetMediaInfo (System.String filename) [0x0006e] in M:\BuildAgent\work\63739567f01dbcc2\src\NzbDrone.Core\MediaFiles\MediaInfo\VideoFileInfoReader.cs:57 

19-10-20 02:19:04.4|Error|DetectSample|Failed to get runtime from the file, make sure mediainfo is available

TBH very close to a clean Catalina install because fixing broken apps because of macOS' new security/privacy settings has ruined my week

Hope this helps and to hear back

Cheers

dberlin commented 4 years ago

Clean catalina will not fix this.

The underlying issue is the way catalina changed things.

Normally i'd send patches, but given the way apple is going, i'm just gonna move away from Catalina as a server.

formerandroider commented 4 years ago

@ldexterldesign this must be due to something unique with your installation, as I've only ever used automatic import and it's been working without issue since granting full disk access to /bin/sh.

I doubt it'd be related, but I wonder if it's your torrent client that's setting some additional metadata? I've been using Transmission.

@dberlin please consider sending patches anyway :)

ldexterldesign commented 4 years ago

@dberlin

Clean catalina will not fix this

You're probably correct, I'm shortly due a scheduled annual reinstall anyway. I suspect I've mucked up my ~ permissions attempting to fix other apps this week too so hopefully it'll fix that.

[...] I'm just gonna move away from Catalina as a server

Init. I installed Ubuntu on my Apple hardware recently but it has dog performance. As soon as I find laptop hardware on par with a 2015 MacBook Pro then I'll migrate to Linux. Sick of Apple hardware TBH and now software too!

Cheers

jef commented 4 years ago

Overview

To what @formerandroider and @cmbv suggested, I found a working path for their solutions. @formerandroider solution is spot on for giving mono access and @cmbv is close to how mono is called and given permissions within launchctl and macOS' point of view. Thanks for @omikron for mentioning some good testing and notes on v3 alternatives.

📝 Note: This is for Sonarr v2, if you're using v3 please replace "NzbDrone.exe" with "Sonarr.exe" in the following writeup. from: @omikron

Instructions

If you are currently running macOS Catalina (full release) and not using the auto start with the Users' Login Items, this should work for you:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>Sonarr</string>
    <key>ProgramArguments</key>
    <array>
        <string>/Library/Frameworks/Mono.framework/Versions/Current/Commands/mono</string>
        <string>--debug</string>
        <string>/Applications/Sonarr.app/Contents/MacOS/NzbDrone.exe</string>
    </array>
    <key>RunAtLoad</key>
    <true/>
    <key>KeepAlive</key>
    <true/>
</dict>
</plist>

ℹ️ Optional: Run launchctl load ~/Library/LaunchAgents/com.github.sonarr.plist if you want to run it on boot.

Hopefully this helps.

In addition, if you're using Radarr and are having similar problems with permissions, the solution is the same. You will switch this line:

<string>/Applications/Sonarr.app/Contents/MacOS/NzbDrone.exe</string>

with this line:

<string>/Applications/Radarr.app/Contents/MacOS/Radarr.exe</string>

You should also change the Label to Radarr; as well as the file name (e.g. com.github.radarr).

🚨 Opinionated Note: Please do not give /usr/local/bin or /bin or whatever else that has many executables Full Disk Access. This can be very dangerous.

Jafalex commented 4 years ago

Thanks @hijxf for the summary, it worked for me as well. I can't believe I spent a solid 4-5 hours trying to fix my NAS folder permissions when it's a Catalina (or Mono, or Sonarr/Radarr) issue, so frustrating!

Btw, I still had to give sh full disk access for things to work properly, which you haven't mentioned, is it because you didn't have to do that for it to work?

Cheers

jef commented 4 years ago

@jafalex, glad it's working! I did not give sh full disk access. In our cases, we don't need to as we are using mono directly. If we used @cmbv's example, they are using sh. But since we aren't, I don't think it's necessary.

Sorry about your perm stuff on your NAS :( What a pain...

tovkal commented 4 years ago

The workaround proposed by @hijxf worked for me, but I was getting a warning that prevented copying of finished downloads

19-10-23 20:22:55.1|Warn|FreeSpaceSpecification|Not enough free space (0) to import: /Users/tovkal/Downloads/Transmission/Mr.Robot.S04E03.1080p.WEB.h264-TBS[rarbg]/mr.robot.s04e03.1080p.web.h264-tbs.mkv (1444040744)

was able work around that too by enabling this advanced setting: Settings ➡️ Media Management ➡️ Importing ➡️ Skip Free Space Check ➡️ Yes

jef commented 4 years ago

was able work around that too by enabling this advanced setting: Settings ➡️ Media Management ➡️ Importing ➡️ Skip Free Space Check ➡️ Yes

That's interesting... I haven't gotten any of those logs yet. This would make me think that something else doesn't have access to your disk, which I find strange as mono is the only process. I don't believe NzbDrone.exe spawns child processes for it's work.

ldexterldesign commented 4 years ago

FYI

My VideoFileInfoReader log [e]rrors were caused by macOS adding extended file attributes to a load of my system files. Removing the (quarantine) attribute(s) fixed that log error but I'm still in file access permission hell.

My auto import is still broken:

19-10-24 00:46:51.7|Error|DownloadMonitoringService|Couldn't process tracked download Unbelievable.S01.COMPLETE.720p.NF.WEBRip.x264-GalaxyTV[TGx]

[v3.0.3.652] System.UnauthorizedAccessException: Access to the path '/Users/ldexterldesign/Downloads/-qbittorrent/-complete/Unbelievable.S01.COMPLETE.720p.NF.WEBRip.x264-GalaxyTV[TGx]' is denied. ---> System.IO.IOException: Operation not permitted
   --- End of inner exception stack trace ---
  at System.IO.Enumeration.FileSystemEnumerator`1[TResult].CreateDirectoryHandle (System.String path, System.Boolean ignoreNotFound) [0x00032] in <b814b509d4ad406fb40c6c93e38929e7>:0 
  at System.IO.Enumeration.FileSystemEnumerator`1[TResult]..ctor (System.String directory, System.IO.EnumerationOptions options) [0x00048] in <b814b509d4ad406fb40c6c93e38929e7>:0 
  at System.IO.Enumeration.FileSystemEnumerable`1+DelegateEnumerator[TResult]..ctor (System.IO.Enumeration.FileSystemEnumerable`1[TResult] enumerable) [0x00000] in <b814b509d4ad406fb40c6c93e38929e7>:0 
  at System.IO.Enumeration.FileSystemEnumerable`1[TResult]..ctor (System.String directory, System.IO.Enumeration.FileSystemEnumerable`1+FindTransform[TResult] transform, System.IO.EnumerationOptions options) [0x00042] in <b814b509d4ad406fb40c6c93e38929e7>:0 
  at System.IO.Enumeration.FileSystemEnumerableFactory.UserFiles (System.String directory, System.String expression, System.IO.EnumerationOptions options) [0x00014] in /Users/builder/jenkins/workspace/build-package-osx-mono/2019-06/external/bockbuild/builds/mono-x64/external/corefx/src/System.IO.FileSystem/src/System/IO/Enumeration/FileSystemEnumerableFactory.cs:90 
  at System.IO.Directory.InternalEnumeratePaths (System.String path, System.String searchPattern, System.IO.SearchTarget searchTarget, System.IO.EnumerationOptions options) [0x0003c] in /Users/builder/jenkins/workspace/build-package-osx-mono/2019-06/external/bockbuild/builds/mono-x64/external/corefx/src/System.IO.FileSystem/src/System/IO/Directory.cs:178 
  at System.IO.Directory.GetFiles (System.String path, System.String searchPattern, System.IO.EnumerationOptions enumerationOptions) [0x00000] in /Users/builder/jenkins/workspace/build-package-osx-mono/2019-06/external/bockbuild/builds/mono-x64/external/corefx/src/System.IO.FileSystem/src/System/IO/Directory.cs:140 
  at System.IO.Directory.GetFiles (System.String path, System.String searchPattern, System.IO.SearchOption searchOption) [0x00000] in /Users/builder/jenkins/workspace/build-package-osx-mono/2019-06/external/bockbuild/builds/mono-x64/external/corefx/src/System.IO.FileSystem/src/System/IO/Directory.cs:137 
  at NzbDrone.Common.Disk.DiskProviderBase.GetFiles (System.String path, System.IO.SearchOption searchOption) [0x00047] in M:\BuildAgent\work\63739567f01dbcc2\src\NzbDrone.Common\Disk\DiskProviderBase.cs:155 
  at NzbDrone.Core.MediaFiles.DiskScanService.GetVideoFiles (System.String path, System.Boolean allDirectories) [0x00019] in M:\BuildAgent\work\63739567f01dbcc2\src\NzbDrone.Core\MediaFiles\DiskScanService.cs:142 
  at NzbDrone.Core.MediaFiles.DownloadedEpisodesImportService.ProcessFolder (System.IO.DirectoryInfo directoryInfo, NzbDrone.Core.MediaFiles.EpisodeImport.ImportMode importMode, NzbDrone.Core.Tv.Series series, NzbDrone.Core.Download.DownloadClientItem downloadClientItem) [0x00035] in M:\BuildAgent\work\63739567f01dbcc2\src\NzbDrone.Core\MediaFiles\DownloadedEpisodesImportService.cs:164 
  at NzbDrone.Core.MediaFiles.DownloadedEpisodesImportService.ProcessPath (System.String path, NzbDrone.Core.MediaFiles.EpisodeImport.ImportMode importMode, NzbDrone.Core.Tv.Series series, NzbDrone.Core.Download.DownloadClientItem downloadClientItem) [0x00023] in M:\BuildAgent\work\63739567f01dbcc2\src\NzbDrone.Core\MediaFiles\DownloadedEpisodesImportService.cs:87 
  at NzbDrone.Core.Download.CompletedDownloadService.Import (NzbDrone.Core.Download.TrackedDownloads.TrackedDownload trackedDownload) [0x00014] in M:\BuildAgent\work\63739567f01dbcc2\src\NzbDrone.Core\Download\CompletedDownloadService.cs:106 
  at NzbDrone.Core.Download.CompletedDownloadService.Process (NzbDrone.Core.Download.TrackedDownloads.TrackedDownload trackedDownload, System.Boolean ignoreWarnings) [0x000f6] in M:\BuildAgent\work\63739567f01dbcc2\src\NzbDrone.Core\Download\CompletedDownloadService.cs:100 
  at NzbDrone.Core.Download.TrackedDownloads.DownloadMonitoringService.ProcessClientItems (NzbDrone.Core.Download.IDownloadClient downloadClient, NzbDrone.Core.Download.DownloadClientItem downloadItem) [0x00042] in M:\BuildAgent\work\63739567f01dbcc2\src\NzbDrone.Core\Download\TrackedDownloads\DownloadMonitoringService.cs:136 
ldexterldesign@MacBook-Pro ~ % ls -l /Users/ldexterldesign/Downloads/-qbittorrent/-complete
total 1740832
-rw-r--r--  1 ldexterldesign  staff  890964041 23 Oct 16:50 BBC.This.World.2019.The.Day.California.Burned.720p.HDTV.x264.AAC.MVGroup.org.mkv
drwxr-xr-x@ 4 ldexterldesign  staff        128 23 Oct 00:49 Great Crimes and Trials Documentary Series
drwxr-xr-x  4 ldexterldesign  staff        128 24 Oct 00:50 Its.Always.Sunny.in.Philadelphia.S14E04.WEB.x264-PHOENiX[TGx]
drwxr-xr-x@ 4 ldexterldesign  staff        128 23 Oct 01:46 Unbelievable.S01.COMPLETE.720p.NF.WEBRip.x264-GalaxyTV[TGx]
ldexterldesign@MacBook-Pro ~ % xattr /Users/ldexterldesign/Downloads/-qbittorrent/-complete/Unbelievable.S01.COMPLETE.720p.NF.WEBRip.x264-GalaxyTV\[TGx\]
com.apple.FinderInfo
com.apple.metadata:_kMDItemUserTags
19-10-24 00:47:59.7|Error|RootFolderService|Unable to get free space and unmapped folders for root folder /Users/ldexterldesign/Downloads/-sonarr

[v3.0.3.652] System.UnauthorizedAccessException: Access to the path '/Users/ldexterldesign/Downloads/-sonarr' is denied. ---> System.IO.IOException: Operation not permitted
   --- End of inner exception stack trace ---
  at System.IO.Enumeration.FileSystemEnumerator`1[TResult].CreateDirectoryHandle (System.String path, System.Boolean ignoreNotFound) [0x00032] in <b814b509d4ad406fb40c6c93e38929e7>:0 
  at System.IO.Enumeration.FileSystemEnumerator`1[TResult]..ctor (System.String directory, System.IO.EnumerationOptions options) [0x00048] in <b814b509d4ad406fb40c6c93e38929e7>:0 
  at System.IO.Enumeration.FileSystemEnumerable`1+DelegateEnumerator[TResult]..ctor (System.IO.Enumeration.FileSystemEnumerable`1[TResult] enumerable) [0x00000] in <b814b509d4ad406fb40c6c93e38929e7>:0 
  at System.IO.Enumeration.FileSystemEnumerable`1[TResult]..ctor (System.String directory, System.IO.Enumeration.FileSystemEnumerable`1+FindTransform[TResult] transform, System.IO.EnumerationOptions options) [0x00042] in <b814b509d4ad406fb40c6c93e38929e7>:0 
  at System.IO.Enumeration.FileSystemEnumerableFactory.UserDirectories (System.String directory, System.String expression, System.IO.EnumerationOptions options) [0x00014] in /Users/builder/jenkins/workspace/build-package-osx-mono/2019-06/external/bockbuild/builds/mono-x64/external/corefx/src/System.IO.FileSystem/src/System/IO/Enumeration/FileSystemEnumerableFactory.cs:104 
  at System.IO.Directory.InternalEnumeratePaths (System.String path, System.String searchPattern, System.IO.SearchTarget searchTarget, System.IO.EnumerationOptions options) [0x00045] in /Users/builder/jenkins/workspace/build-package-osx-mono/2019-06/external/bockbuild/builds/mono-x64/external/corefx/src/System.IO.FileSystem/src/System/IO/Directory.cs:180 
  at System.IO.Directory.GetDirectories (System.String path, System.String searchPattern, System.IO.EnumerationOptions enumerationOptions) [0x00000] in /Users/builder/jenkins/workspace/build-package-osx-mono/2019-06/external/bockbuild/builds/mono-x64/external/corefx/src/System.IO.FileSystem/src/System/IO/Directory.cs:150 
  at System.IO.Directory.GetDirectories (System.String path) [0x00000] in /Users/builder/jenkins/workspace/build-package-osx-mono/2019-06/external/bockbuild/builds/mono-x64/external/corefx/src/System.IO.FileSystem/src/System/IO/Directory.cs:142 
  at NzbDrone.Common.Disk.DiskProviderBase.GetDirectories (System.String path) [0x00047] in M:\BuildAgent\work\63739567f01dbcc2\src\NzbDrone.Common\Disk\DiskProviderBase.cs:148 
  at NzbDrone.Core.RootFolders.RootFolderService.GetUnmappedFolders (System.String path) [0x00066] in M:\BuildAgent\work\63739567f01dbcc2\src\NzbDrone.Core\RootFolders\RootFolderService.cs:142 
  at NzbDrone.Core.RootFolders.RootFolderService+<>c__DisplayClass13_0.<GetDetails>b__0 () [0x00075] in M:\BuildAgent\work\63739567f01dbcc2\src\NzbDrone.Core\RootFolders\RootFolderService.cs:189 
  at System.Threading.Tasks.Task.InnerInvoke () [0x0000f] in /Users/builder/jenkins/workspace/build-package-osx-mono/2019-06/external/bockbuild/builds/mono-x64/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs:2476 
  at System.Threading.Tasks.Task.Execute () [0x00000] in /Users/builder/jenkins/workspace/build-package-osx-mono/2019-06/external/bockbuild/builds/mono-x64/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs:2319 
ldexterldesign@MacBook-Pro ~ % ls -l /Users/ldexterldesign/Downloads
total 0
drwxrwxrwx@ 3 ldexterldesign  staff   96 14 Aug 13:50 -lidarr
drwxrwxrwx@ 9 ldexterldesign  staff  288 21 Oct 18:50 -qbittorrent
drwxrwxrwx@ 3 ldexterldesign  staff   96 15 Sep 23:22 -radarr
drwxrwxrwx@ 4 ldexterldesign  staff  128 23 Oct 01:22 -sonarr
ldexterldesign@MacBook-Pro ~ % xattr /Users/ldexterldesign/Downloads/-sonarr
com.apple.macl

Hoping @hijxf's [f]ix will resolve...

If anyone else is suffering this issue then be useful to know it's not just me and my install

Aside, Apple followed up the Catalina upgrade with an update that addressed problems surrounding upgrading with low disk space (definitely my situation, as I routinely max out my disk with torrents) so perhaps related..? CC @Tovkal

Hope this helps

Regards

e: https://github.com/Sonarr/Sonarr/issues/3168#issuecomment-544166066 f: https://github.com/Sonarr/Sonarr/issues/3168#issuecomment-544201112

rakheshster commented 4 years ago

I had the same issue as @Tovkal and @ldexterldesign. I followed the same steps as @hijxf and while that got Sonarr and Radarr to launch they weren't seeing the downloaded files from NZBget. They couldn't rename any of the existing episodes either. Giving "sh" full disk access was the only workaround.

ldexterldesign commented 4 years ago

@rakheshster

+1

Plan to reinstall macOS this week so will report back if this is an issue with a fresh install. Would rather not compromise the security of my system just for Sonarr.

Regards

jef commented 4 years ago

Plan to reinstall macOS this week so will report back if this is an issue with a fresh install. Would rather not compromise the security of my system just for Sonarr.

I'd do some more troubleshooting before you go that route, IMO. What have you given Full Disk Access aside sh?

Can you also make sure you have your user and group permissions for that folder group? Even though there is Full Disk Access, it may be wonky depending on the troubleshooting steps you took.

Try a $ chown -R <YOUR USER NAME>:staff /Users/ldexterldesign/Downloads/{-qbittorrent,-lidarr,-sonarr,-radarr}. That will recursively give those folders and files permission to you and the staff group (I believe staff is macOS' 'admin' group). Mostly everything in there should have '644' permissions, but I wouldn't be concerned about that.

I had the same issue as @Tovkal and @ldexterldesign. I followed the same steps as @hijxf and while that got Sonarr and Radarr to launch they weren't seeing the downloaded files from NZBget. They couldn't rename any of the existing episodes either. Giving "sh" full disk access was the only workaround.

I'm wondering if NZBget is another process that runs outside of the Sonarr/Radarr mono process. In that case, you'd have to see how NZBget is running and then allow that process to have Full Disk Access.

jeffsmith commented 4 years ago

Even following @hijxf steps, I'm still running into the dreaded potential malware error in Catalina:

“Sonarr” cannot be opened because the developer cannot be verified.

Whether I run Sonarr via sh or directly through mono. Has anyone gotten past that issue successfully? Thanks in advance for any guidance.

Edit: Adding terminal output as well in case it's of any help:

[Info] Bootstrap: Starting Sonarr - /Applications/Sonarr.app/Contents/MacOS/Sonarr.exe - Version 3.0.3.652 [Info] Router: Application mode: Interactive [Info] MigrationLogger: *** Migrating data source=/Users/username/.config/Sonarr/sonarr.db;cache size=-10000;datetimekind=Utc;journal mode=Truncate;pooling=True;version=3;Full FSync=True *** [Info] MigrationLogger: *** Migrating data source=/Users/username/.config/Sonarr/logs.db;cache size=-10000;datetimekind=Utc;journal mode=Truncate;pooling=True;version=3;Full FSync=True *** [Info] OwinHostController: Listening on the following URLs: [Info] OwinHostController: http://*:8989/ [Info] SonarrBootstrapper: Starting Web Server

formerandroider commented 4 years ago

@jeffsmith that's because the Sonarr executable hasn't been notarized/signed. It's common for companies that don't want to/can't give Apple money.

Just right click it and select 'Open' to bypass the dialog. It's safe to ignore, if you downloaded the application from a trusted source. It isn't a malware warning.

jef commented 4 years ago

Just right click it and select 'Open' to bypass the dialog. It's safe to ignore, if you downloaded the application from a trusted source. It isn't a malware warning.

Yep! This!

jeffsmith commented 4 years ago

Thanks @formerandroider and @hijxf. Slightly embarrassed that I overlooked that and wasted a ton of time troubleshooting.

jef commented 4 years ago

Thanks @formerandroider and @hijxf. Slightly embarrassed that I overlooked that and wasted a ton of time troubleshooting.

A learning experience, none the less 💯

ghost commented 4 years ago

I just get a "The application "SONARR" can't be opened" dialogue,

Jafalex commented 4 years ago

I just get a "The application "SONARR" can't be opened" dialogue,

Me too. You don't want to run the app from the applications folder for it to work, instead set things up using the Terminal app as detailed here https://github.com/Sonarr/Sonarr/issues/3168#issuecomment-544201112