[6.3.5] Share not excluding

[TDD]

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.

[Lev]

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.

[TDD]

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.

[itimpi]

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.  

[TDD]

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.

[DZMM]

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

[clowrym]

I have noticed Sonarr & Radarr don't seem follow the free space rules either.

[trurl]

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.

[TDD]

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.

[DZMM]

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.

[trurl]

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.

[TDD]

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.

[DZMM]

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

 

 

 

 

[TDD]

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.

[TDD]

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.

[Squid]

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

[TDD]

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.

[Squid]

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

[TDD]

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.