MacOS 10.15 - Full Disk Access Required #3168

baz1860 · 2019-06-14T20:50:21Z

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

Sonarr Version: 3.0.1.513
Operating System: MacOS 10.15 "Catalina" Dev Beta 1
mono (macOS) Version: 5.18.1.0

The text was updated successfully, but these errors were encountered:

markus101 · 2019-06-15T07:24:00Z

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 · 2019-06-15T10:50:54Z

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 · 2019-07-29T19:34:41Z

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 · 2019-08-04T11:59:24Z

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

ontologyrecapitulates · 2019-08-04T23:32:35Z

@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 · 2019-08-15T02:51:53Z

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

narmbrister · 2019-08-21T02:15:00Z

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.

macOS Catalina 10.15 beta 6 (19A536g)
Sonarr Version: 2.0.0.5338
Mono Version: 5.20.1.19

galli-leo · 2019-09-06T11:52:27Z

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 · 2019-09-09T01:21:53Z

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 · 2019-09-27T12:29:14Z

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 · 2019-09-27T12:30:51Z

@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 · 2019-09-27T12:58:52Z

@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 · 2019-09-28T21:10:40Z

@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 · 2019-09-29T11:18:22Z

@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 · 2019-09-29T12:35:32Z

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 · 2019-09-29T13:28:42Z

@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 · 2019-10-09T23:21:37Z

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 · 2019-10-09T23:44:40Z

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

dany20mh · 2019-10-11T01:05:48Z

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

dberlin · 2019-10-11T03:59:30Z

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 · 2019-10-14T08:03:34Z

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 · 2019-10-14T17:55:12Z

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 · 2019-10-14T18:10:30Z

@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 · 2019-10-14T18:35:59Z

@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 · 2019-10-14T18:40:45Z

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 · 2019-10-14T19:31:40Z

" 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 · 2019-10-15T00:20:47Z

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

ghost · 2020-06-05T14:49:20Z

yes, sorry - just worked that out.

In the meantime, I downloaded directly the latest version which put me on v3.0.3.849 immediately. I did not uninstall first.

ghost · 2020-06-05T14:51:24Z

I had to use <cmd>open the first time (no worries) and it appears to be working perfectly just by running from the app (without any mono related script) :-)

jonlbauer · 2020-06-05T14:51:37Z

Hm. I'm on 3.0.3.850 - updated through the app. - Jon

…

On Fri, Jun 5, 2020 at 7:49 AM JCHH ***@***.***> wrote: yes, sorry - just worked that out. In the meantime, I downloaded directly the latest version which put me on v3.0.3.849 immediately. I did not uninstall first. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3168 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABSHYQKKJ55WB4FD2H5XHG3RVEAYLANCNFSM4HYNBSTQ> .

Taloth · 2020-06-05T14:54:12Z

I downloaded directly the latest version which put me on v3.0.3.849 immediately.

849 is the current phantom-develop not the osx fix. If you install normally you have to download the zip I linked, not from via sonarr.tv website.

ghost · 2020-06-05T14:54:37Z

OK, will try that now...

ghost · 2020-06-05T14:58:21Z

I assume you are hoping that simply running from the app (no mono script) is going to work?

I'm getting nothing that way (using the download link but did not uninstall first (do I have to uninstall?).

ghost · 2020-06-05T15:06:35Z

OK, it's working now.

Uninstalling only removed the .app itself, but I did it anyway.

The first time to run, I had to use the <cmd><open> and I noticed in Activity Monitor that it started running before I OK'd it. Sonarr did not work after I OKd it - even though a process was running.

I uninstalled and reinstalled. This time, when I used <cmd><open>, I killed the process that started before my OKing. Then, after I OKd, the process started again. This time it worked.

Killing the process and restarting "normally" (2nd time on) was fine. It's just that first-run which is tricky.

Taloth · 2020-06-05T15:14:37Z

Should've checked ps aux in the console to see if mono was running or not.
The steps you've taken sound convoluted but I can't discern exactly what you did.
tbh. Sounds like you deleted the app prior to actually stopping sonarr, but can't be sure without more information.

No matter how you start it, you start Sonarr and will show in the activity monitor as such. After the bootstrap does it things it switches to mono in-process. This is the whole point of the exercise so that OSX still knows it's Sonarr and associates the permissions correctly.

PS: Yes, you have to 'uninstall'/stop+remove the existing App because normal users won't have it installed. I'm honestly not sure what normally happens if you run Sonarr twice like that.

jonlbauer · 2020-06-05T15:36:58Z

Taloth,

I can confirm that after upgrading to the phantom-osx-catalina branch and upgrading to it in app - I'm running Sonarr without terminal and for the first time since I've been running Catalina, Sonarr CAN see my NAS attached directories. YAY!

THANKS to all of the people that made this finally happen!!!

Jon

Taloth · 2020-06-05T15:49:35Z

What would you like for us to check after we have 3.0.3.850 running?

Sonarr CAN see my NAS attached directories.

That. 😄
I assume you got a popup to give it permission and that it shows up in Security & Privacy? Where you should be able to withdraw permission again.

PS: this particular test we already did ourselves, I just want to verify it with some random people in case someone has a setup that's different than what we tested with. We tested it with both admin and standard users, and some other odd combos but I felt like it was useful to do a final test before throwing it over the wall. especially since we don't have a separate phantom-master yet.

jonlbauer · 2020-06-05T15:53:14Z

I didn't get any popups, but I can see that Sonarr IS listed in my Security & Privacy section of Settings, in the Files and Folders section and says "Sonarr.app Full Disk Access" Maybe that's what's allowing it to do what it's doing? - Jon

…

On Fri, Jun 5, 2020 at 8:49 AM Taloth ***@***.***> wrote: What would you like for us to check after we have 3.0.3.850 running? Sonarr CAN see my NAS attached directories. That. 😄 I assume you got a popup to give it permission and that it shows up in Security & Privacy? Where you should be able to withdraw permission again. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3168 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABSHYQOZRZJK6JTXSFLOQ73RVEH2BANCNFSM4HYNBSTQ> .

Taloth · 2020-06-05T16:04:56Z

You probably did that a long time ago when fiddling with scripts and options and discovering where to do Full Disk Access.
Remove the permission. (maybe need to restart sonarr afterwards)

jonlbauer · 2020-06-05T16:09:58Z

Hm. Apple doesn't allow you to delete anything in that list. I ALSO see Sonarr listed with a check mark under the "Full Disk Access" area. I THINK that the "Files and Folders" area must be populated with the apps that are given permission in the "Full Disk Access" setting. Not sure... - Jon

…

On Fri, Jun 5, 2020 at 9:05 AM Taloth ***@***.***> wrote: You probably did that a long time ago when fiddling with scripts and options and discovering where to do Full Disk Access. Remove the permission. (maybe need to restart sonarr afterwards) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3168 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABSHYQMA4K4U77HLMUQUNBLRVEJUBANCNFSM4HYNBSTQ> .

ghost · 2020-06-05T16:11:41Z

What would you like for us to check after we have 3.0.3.850 running?

Sonarr CAN see my NAS attached directories.

That. 😄
I assume you got a popup to give it permission and that it shows up in Security & Privacy?

I can see my NAS shares too. I did not get a pop-up , it just worked.

I deleted Sonarr from "full disk access". Note that Mono has permission for network volumes and removable volumes. Should they also be removed for this test?

When I restarted, Sonarr asked for Network access (I gave it) and it can see my NAS OK :-)

brechtdebaene · 2020-06-05T16:14:41Z

Awesome! thanks for the help guys. the catalina branch just works.

is there an equivalent branch for Radarr? I can't seem to find one other than develop.
cheers

Taloth · 2020-06-05T17:01:13Z

I feel like the ppl that got full disk access on Sonarr already had that due to an earlier attempt.

fyi with tccutil reset All com.osx.sonarr.tv you can reset the permissions.

jonlbauer · 2020-06-05T17:08:17Z

Ok, I used that tccutil command, restarted Sonarr, and when I tried to access a network share with Sonarr, got a pop up for disk access. Once granted, I now see Sonarr listed under "Files and Folders" with "Network Volumes" and it seems to be working fine. So no "Full Disk Access" now... - Jon

…

On Fri, Jun 5, 2020 at 10:01 AM Taloth ***@***.***> wrote: I feel like the ppl that got full disk access on Sonarr already had that due to an earlier attempt. fyi with tccutil reset All com.osx.sonarr.tv you can reset the permissions. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3168 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABSHYQIO3MDVK4RAN7LW5NDRVEQHBANCNFSM4HYNBSTQ> .

jonlbauer · 2020-06-05T17:14:49Z

@brechtdebaene -> I believe that the developers for Radarr are a different group. Hope they see this progress and quickly adopt it too! I'm on the "nightly" build for Radarr - v0.2.0.1494 and I have to manually copy movies that are downloaded.

Jon

Taloth · 2020-06-05T17:33:00Z

Radarr aphrodite is using dotnet core iirc which has it's own binary loader. I don't see them porting it to the existing v2 version (same like I'm not gonna support it for Sonarr v2)

jonlbauer · 2020-06-05T17:34:30Z

Ah right. I read something about Aphrodite. I need to figure out how to get onto that one. Thanks for the reminder.

jonlbauer · 2020-06-05T18:34:55Z

Am on Aphrodite now - worked perfectly following this guide: https://www.reddit.com/r/radarr/comments/gnrvlk/how_to_install_radarr_v3_aphrodite_on_macos/

Jon

Taloth · 2020-06-05T18:36:42Z

The original request still stands #3168 (comment)

If anyone else runs into issues let me know asap. Otherwise I'll ship it to phantom-develop tomorrow.

ixalsera · 2020-06-06T12:37:39Z

Just a note that if anyone is using the Automator approach that I mentioned above, the update will most likely fail (can't write to temp folders I think). If that's the case for you, shut down Sonarr and launch the regular app instead, then initiate the update.

ixalsera · 2020-06-06T12:45:14Z

If anyone else runs into issues let me know asap. Otherwise I'll ship it to phantom-develop tomorrow.

No issues detected (after upgrade from Automator approach), but I'm sure you're still going to get people who have Sonarr running on an unmonitored machine freaking out that Sonarr has "stopped working" (because they haven't seen the Permissions dialogs). I'm willing to draft a short little how-to for the wiki if it's needed/wanted that can explain how to trigger the dialog manually instead of waiting for a refresh or move attempt.

Taloth · 2020-06-06T12:51:40Z

I'm willing to draft a short little how-to for the wiki if it's needed/wanted.

I'd appreciate that. But please also include the normal install steps (such as Ctrl+Open) and the install approval dialogs users will normally encounter.
We should also update the install steps on the website https://sonarr.tv/#downloads-v3-macos
I'll see if I can make the wiki article linkable from the changelog.

We discussed the 'suddenly stopped working' scenario earlier in this thread and concluded that, since Sonarr v3 is beta, a potentially breaking change like this is acceptable.

Taloth · 2020-06-07T16:49:29Z

Closed via 396caa5

Add wiki page here https://github.com/Sonarr/Sonarr/wiki/MacOS-Permissions
Feel free to flesh it out a bit.

TODO: Update install instructions for on the site.

khuysmans · 2020-09-01T07:42:14Z

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

Just upgraded to Catalina and this fixes it for me as well. Thank you for sharing.

Edit: using version 2.0.0.5344 - 13 Mar 2020

Taloth · 2020-09-01T11:58:16Z

If you want it to work without Full Access then you need Sonarr v3.

markus101 added platform: macos suboptimal labels Jun 15, 2019

dkids mentioned this issue Aug 23, 2019

Problems with Catalina Beta even when using command line Radarr/Radarr#3714

Closed

Taloth closed this as completed Jun 7, 2020

github-actions bot locked as resolved and limited conversation to collaborators Jan 23, 2021

MacOS 10.15 - Full Disk Access Required #3168

MacOS 10.15 - Full Disk Access Required #3168

Comments

baz1860 commented Jun 14, 2019 • edited

markus101 commented Jun 15, 2019

baz1860 commented Jun 15, 2019

ontologyrecapitulates commented Jul 29, 2019

formerandroider commented Aug 4, 2019

ontologyrecapitulates commented Aug 4, 2019

georgeperez commented Aug 15, 2019

narmbrister commented Aug 21, 2019

galli-leo commented Sep 6, 2019

dkids commented Sep 9, 2019

ewancluckie commented Sep 27, 2019

formerandroider commented Sep 27, 2019 • edited

ewancluckie commented Sep 27, 2019 • edited

formerandroider commented Sep 28, 2019 • edited

galli-leo commented Sep 29, 2019

ourcore commented Sep 29, 2019

ewancluckie commented Sep 29, 2019

dany20mh commented Oct 9, 2019

formerandroider commented Oct 9, 2019

dany20mh commented Oct 11, 2019

dberlin commented Oct 11, 2019 • edited

cjattard commented Oct 14, 2019

cmbv commented Oct 14, 2019

formerandroider commented Oct 14, 2019

cmbv commented Oct 14, 2019 • edited

formerandroider commented Oct 14, 2019

ontologyrecapitulates commented Oct 14, 2019

narmbrister commented Oct 15, 2019

ghost commented Jun 5, 2020

ghost commented Jun 5, 2020 • edited by ghost

jonlbauer commented Jun 5, 2020 via email

Taloth commented Jun 5, 2020

ghost commented Jun 5, 2020

ghost commented Jun 5, 2020

ghost commented Jun 5, 2020

Taloth commented Jun 5, 2020 • edited

jonlbauer commented Jun 5, 2020

Taloth commented Jun 5, 2020 • edited

jonlbauer commented Jun 5, 2020 via email

Taloth commented Jun 5, 2020

jonlbauer commented Jun 5, 2020 via email

ghost commented Jun 5, 2020 • edited by ghost

brechtdebaene commented Jun 5, 2020

Taloth commented Jun 5, 2020

jonlbauer commented Jun 5, 2020 via email

jonlbauer commented Jun 5, 2020

Taloth commented Jun 5, 2020

jonlbauer commented Jun 5, 2020

jonlbauer commented Jun 5, 2020

Taloth commented Jun 5, 2020

ixalsera commented Jun 6, 2020

ixalsera commented Jun 6, 2020 • edited

Taloth commented Jun 6, 2020

Taloth commented Jun 7, 2020

khuysmans commented Sep 1, 2020 • edited

Taloth commented Sep 1, 2020

baz1860 commented Jun 14, 2019 •

edited

formerandroider commented Sep 27, 2019 •

edited

ewancluckie commented Sep 27, 2019 •

edited

formerandroider commented Sep 28, 2019 •

edited

dberlin commented Oct 11, 2019 •

edited

cmbv commented Oct 14, 2019 •

edited

ghost commented Jun 5, 2020 •

edited by ghost

Taloth commented Jun 5, 2020 •

edited

Taloth commented Jun 5, 2020 •

edited

ghost commented Jun 5, 2020 •

edited by ghost

ixalsera commented Jun 6, 2020 •

edited

khuysmans commented Sep 1, 2020 •

edited