September 28, 20178 yr Hi all. This one I cannot figure out. With 10 disks, I have a "TV" library set to span all the disks *except* disk 1...hence 2 -> is open game. The share in question is appropriately set to exclude 1, and include the rest. My understanding is that this alone should force any copies to the share to of course exclude 1. This *does* work when I copy files to the share myself. Where it fails is when Sonarr picks up a show and drops it into the TV library. Said show suddenly appears on disk 1. For note, the work flow is that NZBGet fetches a show, drops it into a folder on disk 1. Sonarr sees this and should pick it up and drop it into TV which would bypass disk 1, but it doesn't. The TV share is set to high-water and split of the first two directories. FYI, my shows are contained within sub-folders of TV (ie: TV/Family Guy/SXX...). There are no explicit references to any "/mnt/disk1" or anything like that. Everything is via the "/mnt/user/TV" path. Is this a bug with somehow it being greater than one directory level? Kev.
October 15, 20178 yr I think I hit this condition repetitively over the last few weeks. Finally narrowing it down to what conditions it's triggered under and I don't think you're alone in what you're experiencing.
October 16, 20178 yr Author I am at a loss other than to believe it a bug somehow. I tried a new config and moved the disk 1 to disk 9, changing my shares accordingly so the TV share excluded disk 9 - just to remove the chance that that this was tied to disk 1. Same thing arose - files somehow dropped on disk 9 in a TV folder. I am manually moving the files being dropped on disk 1 to another disk then copying back to the user share to workaround this issue. I am hopeful that somehow it gets "fixed" with 6.4 coming up.
October 16, 20178 yr Community Expert It is a quirk of the way move is handled at the Linux Level. If it appears the source and target may be on the same mount point then a rename is tried and only if that fails does a copy/delete take place.
October 18, 20178 yr Author Well, this certainly seems to defeat the point of the include/exclude parameters? This still doesn't explain why an internal move/copy ends up inside an excluded disk via Sonarr, when an external move/copy works fine. I can take the files that should NOT be on disk 1, place them into a different directory on the same disc, shell in and move them with MC back to the /user/TV share and they respect the exclude and end up anywhere but disk 1. Is this a unique Sonarr thing that is bypassing the rules? Kev.
October 18, 20178 yr have you tried include rather than exclude? I have all my sonarr activity on disk 3 and completed downloads obey my include rules and aren't written to disk 3
October 18, 20178 yr Community Expert 13 minutes ago, clowrym said: I have noticed Sonarr & Radarr don't seem follow the free space rules either. The only free space rule is "don't begin writing a file to a disk that has less than the minimum free setting". There is nothing to prevent writing a file that is too large for the available free space. Minimum free must be set to be larger than the largest file you will ever write. That is the way it has always worked. Don't know if that explains what you are talking about or not.
October 18, 20178 yr Author Yes - I have tried explicitly setting exclude disk 1 and and setting include (all others) to really force the issue. I have moved the disk to another slot too to ensure it isn't a slot issue (ie: disk 1 vs 8 or something). From my understanding, it is not necessary to explicitly complete both the includes and excludes for the same share. I will still fuss with this but it mysterious. All other copies look to respect things just fine. Kev.
October 18, 20178 yr 3 minutes ago, TDD said: Yes - I have tried explicitly setting exclude disk 1 and and setting include (all others) to really force the issue. I have moved the disk to another slot too to ensure it isn't a slot issue (ie: disk 1 vs 8 or something). From my understanding, it is not necessary to explicitly complete both the includes and excludes for the same share. I will still fuss with this but it mysterious. All other copies look to respect things just fine. Kev. I'm fairly certain you only have to exclude or include, not both. It works fine for me just using includes.
October 19, 20178 yr Community Expert Exclude means "use all except the listed drives". Include means "use only the listed drives". There is never any reason to specify both, and it is not recommended.
October 20, 20178 yr Author Well, no combination of include/exclude makes it work. This is a bug and unique somehow to the situation. Even shelling into the server and copying via MC respects the rules. This is a Sonarr thing as mentioned above. My share setup, attached, is for review. Seems sane to me! Kev.
October 23, 20178 yr I'm not sure if this is exactly the same bug, but I spotted one over the weekend that the LT team said will be fixed in the next release. I'm not sure if this is 6.4RCx Quote Thank you for the report. This is a known issue and fixed in next release. Cheers, Tom From: LimeTech [mailto:[email protected]] Sent: Saturday, October 21, 2017 1:16 AM To: [email protected] Subject: unRAID User Bug Report (ID #1343) Bug Report Bug Description: moving files between directories in mc doesn't respect disk include/exclude options How to reproduce: I have two shares /movies_adults (disks 5,6 only) and /movies_kids (disks 3.4 only). I moved movie1 from mnt/user/movie_adults/movie1 to mnt/user/movie_kids/movie1 Expected results: movie1 shoud have been moved to mnt/disk3/movie_kids/movie1 or mnt/disk4/movie_kids/movie1 Actual results: mnt/disk6/movie_kids/movie1 i.e. not disk 3 or 4
January 23, 20188 yr Author An FYI that this bug is still in play. Somehow my Sonarr still gets past the include/exclude and it drops into my disk explicitly set as exclude but preferred overall?? because of the high-water setting. Kev.
February 11, 20188 yr Author I am at a loss to fix this. I have now modified my system so that my main array (disks 1-8) are exclusively for data. They all are set to allow any share included and excluded none. My Docker and various appdata now resides on a cache disk. The cache shares are explicitly set to ONLY use the cache disk. The array shares are explicitly set to NOT use the cache disk. Somehow when Sonarr imports a file, it transfers it out to the TV share in my array (paths are set as /mnt/user/TV) but it ends up on the cache disk despite the rules with the same folder structure. This is the only docker/app that seems to do this. It seems to ignore the cache directives and just follow the share rule for high-water hence it ends up on my most free disk? Any insight here? Kev.
February 11, 20188 yr If you're mapping /mnt to /mnt or /mnt/user to /mnt/user and referencing all the paths in sonaar from a single path mapping then what you're seeing is correct and expected
February 12, 20188 yr Author I am. Here are my specific docker maps: All my internal Sonarr TV paths are then accessed via /mnt/user/TV, /mnt/user TV (Kids), etc. which are the unRaid shares across my array. Perhaps I am not getting why the rules of fill and disk choice would not be followed in this case? All other accesses to the same follow the rules. Copying anything (like with MC) into /mnt/user/TV is following the rules...?! Kev.
February 12, 20188 yr It's because of mount points. Any OS when moving a file will look to see if the source and destination are on the same mount point (in your case /mnt) since that's what you mapped to the container. If they are then it'll just renames the file to the new location instead of a copy and delete operation. Net result is that your file winds up on the cache drive in violation of the rules. Solution is to map another path of /tv mapped to /mnt/user/tv and have sonarr move the files to /tv instead
February 12, 20188 yr Author This makes sense. I have just mapped my two folders into docker and have re-pointed all my tv libraries to the mountpoints inside the root of Sonarr. I think now that this was some kind of limitation from way back when I first started Sonarr and I never bothered to change it or even think of this. This should fix it nicely...TY for making me see the obvious! Fingers crossed it will work now! Kev.
Archived
This topic is now archived and is closed to further replies.