[6.3.5] Share not excluding


TDD

Recommended Posts

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.

Link to comment
  • 3 weeks later...

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.

Link to comment

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.

Link to comment
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.

Link to comment

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.

Link to comment
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.

Link to comment

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.

Screenshot - 10_19_2017 , 10_54_58 PM.jpg

Link to comment

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:mailer@lime-technology.com] 
Sent: Saturday, October 21, 2017 1:16 AM
To: feedback@lime-technology.com
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

 

 

 

 

Link to comment
  • 2 months later...
  • 3 weeks later...

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.

Link to comment

I am.  Here are my specific docker maps:

 

image.thumb.png.fdede10782d7a429fc4b9f5615c9e5f0.png

 

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.

Link to comment

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

Link to comment

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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.