Suddenly i have a problem with one of my shares, the 'tvseries' share.

 

I have 6 disks, and the 'tvseries' share is set up so it INCLUDES disk 2,3,4,5,6 and EXCLUDES disk1. Split level is 1.

(Disk 1 is reserved for other stuff, and contains my download folder for sabnzb. The download folder is also a share)

 

But for some reason, if i move a downloaded item from the download folder (on disk 1) to the 'tvseries' SHARE (/mnt/user/tvseries) for some reason unraid creates the tvseries/season/item on disk1... every time. It should be moved to the existing series folder on any disk BUT disk1.

(using mv from command line, e.g. mv /mnt/user/Downloads/item /mnt/user/TVSeries/Show/Season x/ )

 

I've tried removing the share from simplefeatures, and even deleted the tvseries.cfg from flash, but the behaviour does not change.

It used to work perfectly for months... changing split levels or most free/high water etc doesnt make a difference.

 

The only thing i changed is that the folder(s) used to be named 'TV Series' and now it is 'TVSeries'.

 

How can i solve this?

Weird.

 

If i use a MOVE command from the physical download location on disk1, so: /mnt/disk1/downloads in stead of /mnt/user/downloads, to /mnt/user/share/xxx, it looks like it works... the result is placed on the proper disk and NOT on disk1 anymore.

 

So, why wont the share-system won't work on move commands from usershare to usershare?

It's a peculiarity of the underlying file system below the custom unRAID code used for the user shares. Any time you move between shares or within a share the files will stay on the same disk regardless of it violating the share settings.

So, this is basically a bug?

Not exactly, it's part of the underlying open source code that unRAID is built on. It's been that way forever and Tom is aware of this peculiarity so it must be something that is difficult to fix.

Well, the 'user share' functionality is one of the big features of unraid, and it should be so that if you copy to a user share, the unraid system should place the file on the correct disk, according to the share's include/exclude list, and split level. Since this does not work in this case, it is a bug, simple as that.

 

Anyway, it is something to take notice of.