Every episode is put into an individual folder just outside series folders

Sonarr version (exact version): 2.0.0.5338
Mono version (if Sonarr is not running on Windows): 5.20.1.34
OS: Ubuntu 18.04.3 LTS
Debug logs: Coming soon
Description of issue: I have downloads from SABnzbd set to folder/path of /nas/tvshows. Until recently, all was working well, until a failure in my Sonarr container forced me to remove and rebuild it. I am quite likely missing something in that configuration, because despite the /nas/tvshows directory (which is outside any Docker containers) being bound to both SAB and Sonarr, I have the following problem:

Directly below /nas/tvshows are individual folders for each series. Then within each series folder are season folders, then the files for each season should (and used to) go in there. Now what happens is that a new folder is being created in /nas/tvshows with the release name for each and every individual episode that SAB/Sonarr grabs. I have each series’ folder set to the root of the series (/nas/tvshows/seriesName).

Expected behavior is that I would end up with /nas/tvshows/seriesName/Season\ 4/seriesName.S04E03.720p.Boogers.mkv.

Actual behavior is that I get /nas/tvshows/seriesName.S04E03.720p.Boogers/{file1.srt,file2.mkv,file3.nfo}

I can enable and send debug logs if needed, but I’m hoping that I’m missing something obvious in either my container config or Sonarr config (SABnzbd hasn’t changed).

Debug log says “System.UnauthorizedAccessException: Access to the path is denied.” which I find hard to believe because I’ve gone through and done a recursive chown 777 on the entire /nas/tvshows directory hierarchy. Continuing to dig.

[v2.0.0.5338] System.InvalidOperationException: Operation not permitted ---> Mono.Unix.UnixIOException: Operation no
   --- End of inner exception stack trace ---
  at Mono.Unix.UnixMarshal.ThrowExceptionForLastError () [0x00005] in <4a040cc44eb54354b3d289eb2bbc1e23>:0
  at Mono.Unix.UnixMarshal.ThrowExceptionForLastErrorIf (System.Int32 retval) [0x00004] in <4a040cc44eb54354b3d289eb
  at Mono.Unix.UnixFileSystemInfo.CreateLink (System.String path) [0x0000c] in <4a040cc44eb54354b3d289eb2bbc1e23>:0
  at NzbDrone.Mono.Disk.DiskProvider.TryCreateHardLink (System.String source, System.String destination) [0x00013] i

19-10-15 12:32:50.2|Debug|DiskTransferService|Rolling back incomplete file move [/nas/tvshows/Chicago.Fire.S08E01.iN
19-10-15 12:32:53.2|Warn|ImportApprovedEpisodes|Couldn't import episode /nas/tvshows/Chicago.Fire.S08E01.iNTERNAL.72

[v2.0.0.5338] System.UnauthorizedAccessException: Access to the path is denied.
  at System.IO.File.Move (System.String sourceFileName, System.String destFileName) [0x00116] in <254335e8c4aa42e392
  at NzbDrone.Common.Disk.DiskProviderBase.MoveFileInternal (System.String source, System.String destination) [0x000
  at NzbDrone.Mono.Disk.DiskProvider.MoveFileInternal (System.String source, System.String destination) [0x00076] in
  at NzbDrone.Common.Disk.DiskProviderBase.MoveFile (System.String source, System.String destination, System.Boolean
  at NzbDrone.Common.Disk.DiskTransferService.TryMoveFileVerified (System.String sourcePath, System.String targetPat
  at NzbDrone.Common.Disk.DiskTransferService.TryMoveFileTransactional (System.String sourcePath, System.String targ
  at NzbDrone.Common.Disk.DiskTransferService.TransferFile (System.String sourcePath, System.String targetPath, NzbD
  at NzbDrone.Common.Disk.DiskTransferService.TransferFile (System.String sourcePath, System.String targetPath, NzbD
  at NzbDrone.Core.MediaFiles.EpisodeFileMovingService.TransferFile (NzbDrone.Core.MediaFiles.EpisodeFile episodeFil
  at NzbDrone.Core.MediaFiles.EpisodeFileMovingService.MoveEpisodeFile (NzbDrone.Core.MediaFiles.EpisodeFile episode
  at NzbDrone.Core.MediaFiles.UpgradeMediaFileService.UpgradeEpisodeFile (NzbDrone.Core.MediaFiles.EpisodeFile episo
  at NzbDrone.Core.MediaFiles.EpisodeImport.ImportApprovedEpisodes.Import (System.Collections.Generic.List`1[T] deci

19-10-15 12:32:53.2|Debug|Api|[GET] /api/queue?sort_by=timeleft&order=asc: 200.OK (2 ms)
19-10-15 12:32:54.1|Debug|Api|[GET] /api/health: 200.OK (1 ms)
19-10-15 12:32:54.2|Debug|Api|[GET] /api/health: 200.OK (0 ms)
19-10-15 12:32:54.4|Debug|Api|[GET] /api/diskspace: 200.OK (224 ms)
19-10-15 12:32:54.6|Debug|Api|[GET] /api/diskspace: 200.OK (226 ms)
19-10-15 12:32:55.6|Debug|Api|[GET] /api/log?page=1&pageSize=50&sortKey=time&sortDir=desc: 200.OK (88 ms)
19-10-15 12:32:55.6|Debug|Api|[GET] /api/log?page=1&pageSize=50&sortKey=time&sortDir=desc: 200.OK (4 ms)
19-10-15 12:32:56.9|Debug|Api|[GET] /api/log/file: 200.OK (13 ms)
19-10-15 12:32:57.0|Debug|Api|[GET] /api/log/file/sonarr.debug.txt: 200.OK (13 ms)
19-10-15 12:32:58.5|Debug|Api|[GET] /api/log/file/sonarr.debug.txt: 200.OK (3 ms)
19-10-15 12:33:57.8|Debug|Api|[GET] /api/log/file/sonarr.debug.txt: 200.OK (3 ms)

More complete, properly-formatted log:

19-10-15 12:32:50.2|Debug|EpisodeFileMovingService|Moving episode file: /nas/tvshows/Chicago.Fire.S08E01.iNTERNAL.720p.WEB.x264-BAMBOOZLE-xpost/chicago.fire.s08e01.internal.720p.web.x264-bamboozle.mkv to /nas/tvshows/Chicago Fire/Season 8/Chicago Fire - S08E01 - Sacred Ground WEBDL-720p.mkv
19-10-15 12:32:50.2|Debug|DiskTransferService|Move [/nas/tvshows/Chicago.Fire.S08E01.iNTERNAL.720p.WEB.x264-BAMBOOZLE-xpost/chicago.fire.s08e01.internal.720p.web.x264-bamboozle.mkv] > [/nas/tvshows/Chicago Fire/Season 8/Chicago Fire - S08E01 - Sacred Ground WEBDL-720p.mkv]
19-10-15 12:32:50.2|Debug|DiskProvider|Hardlink '/nas/tvshows/Chicago.Fire.S08E01.iNTERNAL.720p.WEB.x264-BAMBOOZLE-xpost/chicago.fire.s08e01.internal.720p.web.x264-bamboozle.mkv' to '/nas/tvshows/Chicago.Fire.S08E01.iNTERNAL.720p.WEB.x264-BAMBOOZLE-xpost/chicago.fire.s08e01.internal.720p.web.x264-bamboozle.mkv.backup~' failed.

[v2.0.0.5338] System.InvalidOperationException: Operation not permitted ---> Mono.Unix.UnixIOException: Operation not permitted [EPERM].
   --- End of inner exception stack trace ---
  at Mono.Unix.UnixMarshal.ThrowExceptionForLastError () [0x00005] in <4a040cc44eb54354b3d289eb2bbc1e23>:0 
  at Mono.Unix.UnixMarshal.ThrowExceptionForLastErrorIf (System.Int32 retval) [0x00004] in <4a040cc44eb54354b3d289eb2bbc1e23>:0 
  at Mono.Unix.UnixFileSystemInfo.CreateLink (System.String path) [0x0000c] in <4a040cc44eb54354b3d289eb2bbc1e23>:0 
  at NzbDrone.Mono.Disk.DiskProvider.TryCreateHardLink (System.String source, System.String destination) [0x00013] in M:\BuildAgent\work\5d7581516c0ee5b3\src\NzbDrone.Mono\Disk\DiskProvider.cs:182 

19-10-15 12:32:50.2|Debug|DiskTransferService|Rolling back incomplete file move [/nas/tvshows/Chicago.Fire.S08E01.iNTERNAL.720p.WEB.x264-BAMBOOZLE-xpost/chicago.fire.s08e01.internal.720p.web.x264-bamboozle.mkv] to [/nas/tvshows/Chicago Fire/Season 8/Chicago Fire - S08E01 - Sacred Ground WEBDL-720p.mkv].
19-10-15 12:32:53.2|Warn|ImportApprovedEpisodes|Couldn't import episode /nas/tvshows/Chicago.Fire.S08E01.iNTERNAL.720p.WEB.x264-BAMBOOZLE-xpost/chicago.fire.s08e01.internal.720p.web.x264-bamboozle.mkv

[v2.0.0.5338] System.UnauthorizedAccessException: Access to the path is denied.

First, separate sorted and unsorted files, it’s your download client putting them in those folders outside the season folder and you shouldn’t mix those with sorted files.

The Operation not permitted error is coming from trying to create a hardlink, which isn’t a huge deal here, since ultimately it’s going to move, not copy.

DiskTransferService|Rolling back incomplete file move

This is a problem, it tells me Sonarr is trying to import the file via copying, but the file is being truncated, this is a common issue with SMB/CIFS shares and mono. If you’re using SMB/CIFS then try NFS instead, if possible.

System.UnauthorizedAccessException: Access to the path is denied.

Happens during the roll back, possibly related to the file being owned by a different owner and permissions now allowing it to be deleted.

First, separate sorted and unsorted files, it’s your download client putting them in those folders outside the season folder and you shouldn’t mix those with sorted files.

Done:

This is a problem, it tells me Sonarr is trying to import the file via copying, but the file is being truncated, this is a common issue with SMB/CIFS shares and mono. If you’re using SMB/CIFS then try NFS instead, if possible.

Sonarr and SABnzbd are deployed in containers on the same machine. No CIFS or SMB involved.

theres a couple of threads around that show a good way to layout your folder structure so that moves are possible when using containers

youve got sab saving to /config/Downloads/complete (which i doubt sonarr has easy access to) whereas most people would have it save to /downloads/complete, ie you typically dont “contaminate” your config folder with actual data

if you had a folder structure, on your host, like this

/volume1/data/media
/volume1/data/media/downloads
/volume1/data/media/downloads/sab
/volume1/data/media/downloads/sab/complete
/volume1/data/media/downloads/sab/incomplete
/volume1/data/media/tv
/volume1/data/media/tv/series1
/volume1/data/media/tv/series2
/volume1/data/media/movies

then

  • mount /volume1/data/media into each container as /media, eg --mount type=bind,source=/volume1/data/media,target=/media
  • tell sab to save in /media/downloads/sab/complete
  • set the root folder for all series to /media/tv (theres a bulk edit page to make that easy)

if you do that then sonarr can move the file, and not have to copy it, because it now has a common root for the sab save path and the sonarr tv path

if it doesnt work after that then im not sure whats going on

Thank you! I’ve got this sorted now, and it is importing and renaming episodes correctly. The last lingering issue is that it is leaving behind empty folders in the /nas/downloads/sabnzbd/complete directory for each episode. Is there a built-in way in Sonarr to remove those upon successful import? Or should I just set up a quick cron job to rmdir all the things in there once a day?

Thanks again for the assistance, you guys are great!

Answering my own question:

Had to pass the proper PUID and PGID environment variables into the container at deploy-time. Re-deployed the container and everything cleans up after itself as expected.

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.