Suddenly Can't Write to Cache Drive

[UncleDirtNap]

I have this array running (ver 6.9.2) with a few dockers, Sonarr, Radar and Sabnzbd and it's been up and running fine for several weeks.  All of a sudden tonight Sabnzbd starts showing these errors and doesn't seem to have permissions to write to the cache drive. 

 

Indeed, not just Sabnzbd, but I can't write anything to the appdata\downloads folder on the cache drive and get a permissions error when I try to create folder there from Windows machines as well.  The rest of the cache drive is accessible though.

 

Looked at the log file and it's just basically filled with the same errors.  Not sure what to do, nothing was changed or updated on this machine recently ... just suddenly started doing this out of the blue.

 

Any suggestions would be greatly appreciated

[itimpi]

You are likely to get better informed feedback if you post your system’s diagnostics zip file.

 

it sounds as if some sort of problem had occurred with the cache drive - the diagnostics would allow us to confirm if this is the case.

[UncleDirtNap]

Thanks, here it is.

 

Also, just to clarify, it's not the entire cache drive I can't write to as the title indicates, just the appdata\downloads\complete and appdata\downloads\incomplete folders

 

 

stream-machine_new-diagnostics-20220430-0928.zip

[JorgeB]

No issues in the log that I can see, but diags are just after rebooting, did you already get the error before the diags were saved?

[UncleDirtNap]

5 hours ago, JorgeB said:

No issues in the log that I can see, but diags are just after rebooting, did you already get the error before the diags were saved?

 

Literally within seconds of rebooting.  SABNZBD is constantly trying to write to the folder, I'm assuming to complete pending downloads and generating a continuous stream of these errors.

 

I brought up the old server that this one was built to replace, it was up and ran fine for a very long time, to do side by side settings comparison and one thing I did notice is that on the old one the appdata\downloads folder shows up in the shares, where as on the new on it doesn't and I have no idea why.   I tried to recreate it as a share to see what would happen and it looks like the folder gets created (no errors or anything unusual) but the share isn't there.

 

 

[bumpyclock]

I have the same issue. I am using binhex-sabnzbdvpn container and unable to write to the download/complete directory

[UncleDirtNap]

Thanks, here it is.

 

Also, just to clarify, it's not the entire cache drive I can't write to as the title indicates, just the appdata\downloads\complete and appdata\downloads\incomplete folders

 

 

[UncleDirtNap]

Well it happened again.  Hoping the issue was just some random corruption of the cache drive I stopped all the containers in my docker, shutdown the server and replaced the cache drive with a brand new, fresh out of the box Seagate Firecuda NVME (previous on was a new Crucial/Micron)

 

Started the server back up, reinstalled the three docker containers (Sonarr, Radarr and Sabnzbd)  using the same settings I'd copied from my old server that had been running flawlessly for several years.  Server was up and running for exactly 2 days, 2 hours and 55 minutes functioning properly, multiple downloads from both Sonarr and Radarr then out of the blue the errors started again:

 

 

A couple things different so far, first the messages don't seems to be related to a specific file being download last time (nothing has tried to download recently though and last successful download was 15 hours ago) and I can still write to (copy files, create folders, delete same) the appdata\downloads\complete and appdata\downloads\complete shares from a Windows machine. 

 

I'm attaching the diagnostic zip file again, this one taken just minutes after the errors started.

stream-machine_new-diagnostics-20220504-1812.zip

[JorgeB]

Appdata is set to cache="yes", so every time the mover runs it moves files to the array, set to cache=prefer, stop docker service and move everything to cache.

[UncleDirtNap]

14 hours ago, JorgeB said:

Appdata is set to cache="yes", so every time the mover runs it moves files to the array, set to cache=prefer, stop docker service and move everything to cache.

 

Thanks for the reply! Though I'm a bit unclear on the last part of your instructions;  I've looked at all the drives in the array and I don't see any folders or files that appear to have come from or belong on the cache drive.  Not sure if I'm looking for the wrong thing (files and/or folders from the containers and data folders) or looking in the wrong place.

[JorgeB]

Appdata exists on both disk1 and cache, move everything to cache, with the current setting files on that folder are being moved from cache to disk1 and depending on the mappings, i.e., if you use /mnt/cache/appdata instead of /mnt/user/appdata there will be missing files for the apps.

[UncleDirtNap]

On 5/6/2022 at 2:58 AM, JorgeB said:

Appdata exists on both disk1 and cache, move everything to cache, with the current setting files on that folder are being moved from cache to disk1 and depending on the mappings, i.e., if you use /mnt/cache/appdata instead of /mnt/user/appdata there will be missing files for the apps.

 

I looked all over disk1 and still don't see anything that I should move.  So I went ahead and changed cache=yes to cache=prefer, stopped and restarted the array and no errors since.

 

I do use /mnt/cache/appdata, should I change it to /mnt/user/appdata??

 

 

Edited May 8, 2022 by UncleDirtNap

[JorgeB]

17 hours ago, UncleDirtNap said:

I do use /mnt/cache/appdata

That's fine, and preferable IMHO, as long as the use cache is not set to "yes" like it was, or some data would be moved to the array and missing in the docker(s)