Wzyss

I'll give that a look! Thanks for the info.

It is very possible that I ended up running my parity with write corrections and still saw the errors and assumed something was still wrong. That's probably when I came to the forum to post about this. Then once I was told to run yet another check with write corrections enabled, it reported 0 errors. I wish it was easier to tell when the "Write Correction" option was enabled when viewing the history -- that would've cleared a lot of things up.

Interesting... I'm not sure how I went from having parity errors to suddenly not having them. If the correcting parity check didn't find any errors, I'm a bit curious as to why (up until this point) I was receiving them. I've heard that this could be the result of bad files stored on a drive itself and I did do some moving and deleting of old data. Not sure if that statement is true or if my messing around with data had anything to do with what I was seeing. Nonetheless, I appreciate the assistance everyone has provided me here and I'm crossing my fingers and hoping I don't run into this same scenario later down the road.

@trurl So I went ahead and ran a correcting parity check followed by a non-correcting check. Both returned zero errors. Would the correcting parity check still notify you if it had found errors? Nonetheless, it seems everything is fine now. I'll keep my eyes on it.

I've got this running now and will update with the results.

I can't recall for certain, but I have gotten notifications that a parity check has started (off of schedule) and I went and cancelled it because I thought to myself: "Why in the world are you doing this?". The system will auto power on if it loses power but then gets it back, so other than checking the uptime it is something I might not notice. However we do use Plex quite a lot and haven't noticed it just not working at any point in time.

So in this case, what would an unclean shutdown be? I've only had one unexpected shutdown when the UPS itself was tripped. Every other reboot / shutdown was initiated from the admin interface. Also, in reference to correcting the parity, I did run a Parity Check with Write Corrections Enabled, so I would have thought that if the errors were the same, it would attempt to correct them. Again, I'm new to using Parity in this way and I've attempted to read and understand it -- however it blows my mind every time I dig deep into it lol

Yes, the errors are consistently the same. Currently I'm dealing with 12897. A few months prior I was dealing with Parity having 121 errors, but that eventually seems to have fixed itself before this incident. Here's a screenshot of my Parity Check history. The cancellations are usually me realizing I hit Check again instead of the History button. I'm glad this is the case, and I assumed as much. However at this point I wonder what's gone wrong with the Parity. Seeing this made me get a little antsy!

Unraid Version: 6.12.6 I'm a bit new to using Parity and btrfs, I'll be honest. I set up my Unraid box a while ago and everything's been going well! Unfortunately as of late, I've stumbled upon quite a few Parity Checks that have resulted with errors being found. I went thru some of the other forum posts regarding this, but in my case, I don't quite know where to start with getting this fixed. I'll outline what I have done below. What I have done so far: Ran manual Parity check after automatic check just to make sure the errors existed I didn't immediately find anything wrong with any data, so I ran another Parity Check with "Write corrections to parity" enabled This did not seem to fix or resolve the errors as they simply showed up again in the Parity History Ran Scrub (with Array in Normal mode, using BTRFS) on all disks in array All disks return no errors At this point I don't really know what to do from here. I can only recall one incident a while back where the UPS attached to the NAS was tripped and the NAS lost power. Otherwise, she's only ever had clean shutdowns / reboots. I've also attached my diagnostics here just to be a lil ahead of the game. nasty-diagnostics-20240207-1835.zip

Hey, new poster here. When browsing under the General Support section I saw this post: Of course for someone like me, this looks like the place to start! Unfortunately, it seems this forum was either transferred from an old domain or something, as a lot of the helpful links in the mentioned post are broken and point to lime-technology.com. I figured I'd raise awareness of this as I'm sure a lot of new users / posters have tried to use this as a starting point only to have an immediate roadblock to deal with.

This didn't work initially, but I figured I should clear cache on my browser and I can confirm that this works. I was unaware that I had muted notifications for the invalid certificate that I completely forgot the GUI runs over HTTPS. Thanks for pointing me in the right direction, guys.

Honestly I'm unsure what it could be. Attached you'll find the diagnostics zip that was requested. nasty-diagnostics-20191209-1726.zip

Yes, this is the correct IP address. SMB shares work flawlessly using \\10.0.0.10\share. Unfortunately I can't get the GUI to load as it seems to rewrite to the local domain. I can access the GUI if I edit the hosts file of a machine and manually point nasty.local to the IP address of the server. HTTPS doesn't make a difference in this case, it continues to rewrite to the domain.

Currently running unRAID 6.7.2. I'm unable to access the web GUI from any device unless I manually edit the hosts file. The IP of server is 10.0.0.10 and ended up with the domain nasty.local. Devices cannot access the web GUI because upon loading 10.0.0.10, it gets rewritten to nasty.local. Any ideas on what could be causing this?