Zylan

Thanks, I forgot to include that I believe the SAS hba (9211-8i) may have been overheating lately. However the issues have persisted since I added more cooling. I initially discounted this as the first issue was the SSD which was connected directly to the motherboard.

My build has been running fine for around a year, but in the past week I have had a few issues flare up which I'm trying to separate. My cache array is 4 240gb SSD's in RAID 10. This had been running well for a while, however recently unraid had semi-frozen up a few times and one of the ssd's was showing errors. I replaced the cable, tried a different controller, etc, no change, so I've pulled the dodgy drive and am about to replace. However, after restarting my array showed one drive had failed - one of my new 8tb drives. I ran extended SMART tests on all the drives and coming back fine. No smart errors at all except 488 reallocated sectors on the parity drive. I wasn't concerned about losing anything on the drive so have rebuilt over the top. This seemed to be ok after rebuilding. I had also noticed errors on a few other array drives (all drives except SSD's are connected to the same HBA) however those hadn't continued until this morning. My server locked up again, and on restart was trying to do a parity check (at 100kb/s) which I couldn't stop, which detected 22 errors in a few minutes. Restarting again seemed to stop that, however parity check's are still very slow. It also takes around 45 seconds to load the settings page for the parity drive, whereas the others are only 1-2 seconds. hdparm -t shows expected speeds for all the drives (~170mb/s for magnetic, ~500mb/s for ssd's) I've ordered another 8tb drive to replace the parity, but i'm shooting blind here. Diagnostics attached. Any advice? unraid-diagnostics-20181029-1304.zip

Ok, so I didn't realise I could type in that field. it87 has given me the motherboard, but no CPU temps. I've found nct6775 seems to resolve most the values. The CPU temp is reading crazy high (130 deg celsius), so there might be an offset needed for that one? Is it even possible to apply an offset to these values?

Every time I re-plug my Aeotec Z-Wave stick it seems I have to re-chmod the permissions for it to be detected properly by openHab This doesn't seem like it should be happening, and it has the same path all the time, so that's not changing (/dev/ttyACM0) Has anyone had this issue before? Any hints? I've done a search and couldn't find anything.

It hasn't removed the appdata files - the actual guts of the docker. You just have to recreate them, and map them back to the same folders (automatic if you didn't change anything), and remember the port mappings if these have significance for you.

I actually noticed this issue a few minutes ago. It is the Advanced Buttons plugin that was to blame, maybe it was broken in the last 6.4.1 I removed it - that posted errors, but seemed to work: Feb 13 14:48:35 unraid nginx: 2018/02/13 14:48:35 [error] 5375#5375: *2248 FastCGI sent in stderr: "Unable to open primary script: /usr/local/emhttp/plugins/advanced.buttons/AdvancedButtons.php (No such file or directory)" while reading response header from upstream, client: 192.168.1.63, server: , request: "POST /plugins/advanced.buttons/AdvancedButtons.php HTTP/2.0", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "42e98c2c4042ad8b79564935706d20daf536e1d9.unraid.net", referrer: "https://42e98c2c4042ad8b79564935706d20daf536e1d9.unraid.net/Plugins" I can now update dockers properly If you switch to the advanced view you can see the orphaned images of your old dockers so you know what you're missing, but unless you have backups you might have to try and remember your old path / port mappings.