Removing user share from cache not working

[jfrancais]

I am currently running the newest release of Unraid.  I have a bunch of user shares and some are configured to use my cache drive.  It is working fine but I'm finding my cache drive is getting full on occasion before the mover runs because I have one share I'm writing a lot to daily.  I no longer need it as part of the cache since isnt an issue, so I tried removing it from the cache share.  I run the mover and ensure data is off the cache and all on the array and then modify the user share to no longer use cache, but new data still seems to be written to cache for that user share.  I've tried restarting array and restarting computer after change but still files keep getting written to cache for that user share.  This was happening in the previous version of Unraid before update so it isnt new.  Can anyone assist?

[RobJ]

Please see Need help? Read me first!, and attach the diagnostics zip.

[jonp]

I am currently running the newest release of Unraid.  I have a bunch of user shares and some are configured to use my cache drive.  It is working fine but I'm finding my cache drive is getting full on occasion before the mover runs because I have one share I'm writing a lot to daily.  I no longer need it as part of the cache since isnt an issue, so I tried removing it from the cache share.  I run the mover and ensure data is off the cache and all on the array and then modify the user share to no longer use cache, but new data still seems to be written to cache for that user share.  I've tried restarting array and restarting computer after change but still files keep getting written to cache for that user share.  This was happening in the previous version of Unraid before update so it isnt new.  Can anyone assist?

 

jfrancais,

 

I have tried to create this issue but was not successful.  Steps performed:

 

created a new share

set use cache setting to 'yes'

wrote files to share

files were written to cache

invoked the mover to move files from cache to array

verified files were on array

edited share and set use cache setting to 'no'

wrote files to share

files were written directly to array

 

As RobJ has suggested, please read the "Read me first" post and attach your system diags.

[jfrancais]

Ah, sorry, I have attached diagnostics.  A little more information I discovered in generating this.... I can't replicate via smb share.  If I copy a file to the share on my windows machine it works as expected.  I then used sabnzdb to download a file and it showed up on the cache drive for that share.  (PhAzE 2016.09.17.1 )  Nothing in my config file or in the plugin config is pointing to user share directory.

gobo-diagnostics-20160922-1253.zip

[jonp]

Ah, sorry, I have attached diagnostics.  A little more information I discovered in generating this.... I can't replicate via smb share.  If I copy a file to the share on my windows machine it works as expected.  I then used sabnzdb to download a file and it showed up on the cache drive for that share.  (PhAzE 2016.09.17.1 )  Nothing in my config file or in the plugin config is pointing to user share directory.

 

You probably have configured Sab to directly write to the cache and bypass the user share file system altogether.  Please review your Sab configuration and ensure that it points through /mnt/user/sharename instead of /mnt/cache/sharename.

[jfrancais]

No i confimed both the sab config file and all the plugin config options, the all point to the user share, not the cache drive path.  Sickbeard paths ar the same and files written by sickbeard (coming from sab) also have the same problem.

 

Ah, sorry, I have attached diagnostics.  A little more information I discovered in generating this.... I can't replicate via smb share.  If I copy a file to the share on my windows machine it works as expected.  I then used sabnzdb to download a file and it showed up on the cache drive for that share.  (PhAzE 2016.09.17.1 )  Nothing in my config file or in the plugin config is pointing to user share directory.

 

You probably have configured Sab to directly write to the cache and bypass the user share file system altogether.  Please review your Sab configuration and ensure that it points through /mnt/user/sharename instead of /mnt/cache/sharename.

[jfrancais]

Further to this, I removed and reinstalled the sabnzdb plug in.  (deleted all files for plug in, rebooted machine)  Reset .ini file to previous.  path to write files is /mnt/user/Public and the Public share is set to not be cached.  Files still end up on cache drive.  Mover won't pick them up unless I endable cacheing on share before running.  Transmission plugin using same path does NOT do this and files go straight to array.

 

No i confimed both the sab config file and all the plugin config options, the all point to the user share, not the cache drive path.  Sickbeard paths ar the same and files written by sickbeard (coming from sab) also have the same problem.

 

Ah, sorry, I have attached diagnostics.  A little more information I discovered in generating this.... I can't replicate via smb share.  If I copy a file to the share on my windows machine it works as expected.  I then used sabnzdb to download a file and it showed up on the cache drive for that share.  (PhAzE 2016.09.17.1 )  Nothing in my config file or in the plugin config is pointing to user share directory.

 

You probably have configured Sab to directly write to the cache and bypass the user share file system altogether.  Please review your Sab configuration and ensure that it points through /mnt/user/sharename instead of /mnt/cache/sharename.

[jfrancais]

OK, I have switched to using a docker image for sabnzdb.  Now files are going to the proper place.  But any files being processed with the sickbeard (and sickrage) take the file and when renaming end up on a cache drive even though the share is set to not cache.

 

should there be a /mnt/user0 directory file shares set to not cached?

 

Unsure where to go next.

[trurl]

This has to be something about the way your applications are configured. You just haven't figured out what it is yet. Maybe you could post some screenshots for one of the apps that is doing this.

[jfrancais]

I'm fairly certain not.  All the paths in both sabnzdb and sickrage/sickbeard were set to /mnt/user/Public/XXXX and Public is my usershare with cache turned off.

Sabnzbd is now working fine with cache locations since I moved to docker vs application.  Only path difference is that the path is set up in the docker config vs the app it self.  Other than that I'm using the same paths.  Rest of the config is the same.

 

I will try a docker image of sickrage next I guess and see if it fixes it for that app.

 

and just to clarify, should there be a path /mnt/user0/Public is Public is set to not be cached?  Could that be the issue?

[trurl]

and just to clarify, should there be a path /mnt/user0/Public is Public is set to not be cached?

yes

 

[jfrancais]

Further to this, I installed a Docker version of SickRage and restored the config from the plugin version.  The docker paths are pointing the the same path as the plugin paths.  Files end up in the proper spot and not on that cache drive.

 

I have attached a screen shot of the directory difference from plugin (top) to docker (bottom).  The /tv path in the docker config is set to be /mnt/user/Public which is the share that is set to not cache.

 

This fixed the issue for me, but I think there is something happening in the background with either the OS or the plugins that are referencing cache when it shouldnt. 

[itimpi]

You should include screenshots showing the docker container settings so we can see what the directory mapping is set to.

[jfrancais]

I mentioned it in the post above, but there is a screen shot