h0rnman

Hey all, I'm having an issue with my wireguard configuration that i just can't wrap my head around. I can connect from remote devices as long as i list only my local ip subnet in the allowed ips list on the client. As long as i do, the tunnel builds and I see traffic, but i only have access to my unraid server ip. Any attempt to access other IPs on my network fails. If I set the client to allow 0.0.0.0/0, everything fails as well. The tunnel is acting like it's set to Remote Server Access only but it's definitely set to Remote Tunneled Access. This used to work some time around v6.7, but after it broke I stopped messing with it for a while (once I figured out that setting the allowed ips to my local subnet worked well enough at the time) but I'm trying to get true remote tunneling set up finally.

Ok, so I ran another non-correcting check (which still had all the errors), then I restarted, ran a correcting check (again errors), then a non-correcting check (came back all clear). So it looks like whatever gremlin was in the parity check is gone and that the last correcting check appeared to have executed successfully. I'm still somewhat concerned that there's a scenario where parity can report as valid even though the checks report errors, and with all of the checking and rebooting, the root cause is still a mystery.

So I did a little more digging on my end, and I managed to figure out two things. First, it's multiple items that are writing these log entries. I was able to determine one of them was the Disk Locator plugin. I don't *actually* need that one, so I uninstalled it and now those messages are gone. I did reboot and ran another non-correcting parity check, which resulted in much of the same behavior (several million errors detected, but came back as Parity is Valid). I also ran a short and a long SMART test on the disk and both came back clean. Attaching another diag, and I'm also re-running the non-correcting check in case something with the plugin was acting up and will post when it's done. So far, syslog is just showing several of these: kernel: md: recovery thread: P incorrect, sector=874360 followed by kernel: md: recovery thread: stopped logging so not a lot of help nas02-diagnostics-20240521-1518-pre-ParityCheck.zip

The main log shows those same messages: kernel: program smart smartctl is using a deprecated ISCSI ioctl, please convert it to SG_IO. I've run correcting parity checks already and it throws the same messages about ioctl and SG_IO

Corrected syslog configuration, reran non-correcting parity twice, posting new log gather nas02-diagnostics-20240518-1602.zip

Attaching Diags I haven't changed the physical disks, though I did move the physical SATA connector to another port because the one I was using was giving me troubles with CRC errors. nas02-diagnostics-20240517-0835.zip

The last few parity check results have left me a bit concerned. My disks all show green, and the Error Count column shows 0 for all disks, but when the parity check runs, it always comes back with a large number of errors. In the most current run, it reports finding 28541795 of them. This has been the case for the last several parity runs but I don't know exactly when they started as the check error count is below the fold and not something I generally paid attention to. I'm seeing the following message flooding the logs but I don't know if it has any bearing on this: kernel: program smart smartctl is using a deprecated ISCSI ioctl, please convert it to SG_IO. Honestly, I don't really know where to start with this and I'm hoping maybe someone can point me in the right direction... in my experience, a disk throwing that many errors on a parity check should show other signs of failure and I'm worried that smartctl is failing and lying about the health of my parity disk.

I stopped the array, set that slot to No Device, Started the array, Stopped, Added it back as Disk 3, then restarted the array one last time. Both times I've done this, I get those write errors. I'll have a chance to check connections tonight. I'm hoping that's all it is.

Attaching Diagnostics nas02-diagnostics-20210924-1903.zip

Hey guys, I recently had a power outage, and ever since, I am stuck with a disk that keeps getting offlined due to write errors. The disk itself is less than a year old, and SMART and xfs_repair both report no errors, and it's been fully functional up until the power outage (no errors). I have tried to re-add the disk to the array twice now, but it's failed both times with the same write errors. I've attached my SMART report and what I think are the relevant sections of the Syslog. To those with more experience, does this look like a bad disk or more like a bad cable? WDC_WD40EFAX-68JH4N0_WD-WX62D10LETLZ-20210924-1847.txt syslog.txt