Jakobustrop

Sorry for the late update. The Problem relatively suddenly went away and what maybe solved the issue, even though i would find it odd, is that I remembered that I had to update the DNS rebinding exceptions in my router (Fritz Box) with the new URL and IP that wasn't in there. I would find it odd because the HTTP 500 error only appeared after some time and only after Log-In, I would have expected such a rebind protection to kick in instantly. and to quickly respond to this. Sadly cant send you a log because the problem went away but I did restart nginx back when it was happening and it restarted just normally. So I think it really was external factors.

It must have happened after Apr 20 18:59:11 and before Apr 21 00:00:38. At Apr 20 18:59:11 I started configuring the Cloudflare Docker and testing that. And a few minutes before Apr 21 00:00:38 I went to check on the Server before going to bed and it had the HTTP 500. And at Apr 21 00:00:38 I tried to login through firefox which also threw the HTTP 500 Error. Edit: Even though it probably got nothing todo with the Problem I uninstalled unassigned.devices.preclear becuase I don't need it and the csrf error was bothering me.

Hello, i have been having Issues with the Web interface becoming completely inaccessible after a fews hours of running my Server. The LogIn page appears but after that only HTTP 500. I can SSH into the server to shut it down / restart it. I have looked through the logs but cant find anything pointing in me in the right direction. For context I build a new Server because my old one is out of space. Right now I am copying TBs of data from the old to the new and trying to setup my dockers better than before. At the moment I only got two Dockers container and no parity disks to copying goes faster. I also got an Intel X540 Dual Lan Card installed maybe that's causing some trouble. I attached my most recent Diagnostic tower-diagnostics-20240421-0915.zip

Yes

I disabled all my Ad-Blockers and Privacy Badger with the same result. And Clearing the cache also made no difference. I am using https but when I turn it off and connect directly via the IP address the problem is gone.

I am on Unraid 6.9.2 and i got a very weird Problem I don't know how to properly Diagnose. In Short: When i try to open the Unraid GUI in Firefox I get the "We can’t connect to the server at ************.unraid.net." message. When I leave it for a bit it will load for some reason and then break after half a minute or so. When using Chrome or the new Version of Edge I do not have any problems whatsoever. It probably has something to do with me having secure connection enabled because when the setting is turned off I can connect and open the Gui no Problem with the IP address. It could be an Problem that existed for a while because I just recently switched to Firefox. I looked through all the VPN and DNS configs to find something pointing me in the right direction but i found nothing.

If you scroll up in this thread someone else has had the same Problem und the Solution is at the top of the page "glibc causing random errors".

Okay, thank you! Imma keep an eye on it.

So the second scan finished correcting the 404 Sync errors. No new errors appeared. jarvis-diagnostics-20201202-1733.zip

Not that I know of. Last shutdown was 35 days ago and the previous Parity check didn't Return errors.

Hey Guys, my monthly Parity check finished and I got 404 Sync Errors. I am a little worried but also had to smile because of 404. My monthly check runs without correcting errors, so I am currently running the second parity check with corrections on. I have combed through the logs and think that the errors occured on my second parity disk because of this Dec 1 04:00:01 Jarvis kernel: mdcmd (65): check NOCORRECT Dec 1 04:00:01 Jarvis kernel: Dec 1 04:00:01 Jarvis kernel: md: recovery thread: check P Q ... Dec 1 07:22:00 Jarvis kernel: md: recovery thread: Q incorrect, sector=3908615760 Dec 1 07:22:00 Jarvis kernel: md: recovery thread: Q incorrect, sector=3908615768 Dec 1 07:22:00 Jarvis kernel: md: recovery thread: Q incorrect, sector=3908615776 Dec 1 07:22:00 Jarvis kernel: md: recovery thread: Q incorrect, sector=3908615784 Dec 1 07:22:00 Jarvis kernel: md: recovery thread: Q incorrect, sector=3908615792 Dec 1 07:22:00 Jarvis kernel: md: recovery thread: Q incorrect, sector=3908615800 There were more lines but i will leave them out because they are the same but increasing in sector. I have also attached the logs. Be aware i went a little overboard on smart tests. I first started an extended test on every disk only afterwards realizing that a short one would suffice. Then stopping every extended and starting a short one on every disk. There were no errors with the disks apart from a few dead sectors that were there from day one(with the parity 2 disks having no errors at all). The array itself also doesn't have any errors and i couldn't find anything in the log pointing me to something. I had a few system hangups in the last months because of VMs but that would have before the monthly test of november but that returned 0 errors. So i am a little stumped to what it could be. I also read it could be RAM but I got 96 gigs of ECC memory which hopefully would prevent something like that. I thought it could have been me shuffling multiple 100 gigs of data around while the parity check is running but those errors occured while i was sleeping so that couldn't have been it. I hope I wrote down everything important in here if not I am sorry and happy to give further info. jarvis-diagnostics-20201201-2207.zip