Hadrian_Aurelius

I've been following this thread for awhile and haven't seen any recent updates. I was affected by the issues outlined in the OP but wasn't able to get rid of them without taking my LSI controller out of the equation and going back to running directly off the motherboard SATA controller. I'm planning on bringing back the LSI card to allow me to add more disks to the array but I'm scared of running into this problem again. With the new version of Unraid, has anyone tested whether the new version itself somehow avoids the discussed issues in this thread?

Been a month since I posted about my issues. Parity check completed for the first time in two months without issues (as expected). Once again, this problem started suddenly and mysteriously for me after running problem-free for years. Also, no changes to the Kernel on my system (at least not in many months) so I can't see that being the cause either. In the end, I simply removed my IBM M1015 9220-8i from the equation and I'm back to using sata directly off the motherboard - so far, no issues.

Add me to the seemingly relatively small list of folks this solution (much appreciated fix/write-up) didn't work for. Here's a summary of my experience: Unraid 6.10.3 IBM M1015 9220-8i (IT mode with latest firmware) Drive that keeps dropping off (as of beginning of December 2022) = st10000dm0004 (2gr11l) There are two other st10000dm0004 drives in the system (one is the same revision and the other is a different revision and is the parity drive - 1zc101). There are also 2 x st10000ne0008 in the array. Only the above-listed specific drive has started to drop off and this is after at least two years of no problems. First drop off occurred 01 Dec 2022 (scheduled parity check). I researched the issue, found this thread (and others), checked firmware version for the drive that was getting dropped (despite not seeing why this should make any difference given trouble-free operation for last few years) and found no updates. Did same for HBA card - same - already on latest firmware. Ran through the changes outlined in OP and executed all recommended changes on all above-mentioned drives (not just the one that dropped off). Realizing there could be other factors (cabling, power etc...) I also moved the drive to a different slot on the enclosure I'm using (rsv-sata-cage-34 in a Rosewill 4U whitebox build) and swapped places with another drive. Theory was that if the issue happened again on the same slot, the rsv-sata-cage-34 or associated breakout cable could be suspect. Removed drive from array, ran extended SMART tests - everything normal. Reintroduced drive to array and performed rebuild - no errors. Walked away and forgot about it. 01 Jan 2023, same drive dropped off again during start of parity check. This eliminates slot/cable as culprit as drive was in a new slot with different breakout cable. This time, I removed the IBM M1015 controller and reconnected all drives directly to motherboard. Rebuilt drive over the top of itself again and this time also immediately followed up with a parity check. No errors. I don't really know what to make of all this. Obviously, it's possible I would immediately have had the same drop off issue if I had run the parity check after the first incident on 01 Dec 2022....or would I? Also, when I ran the parity check this time around, I didn't spin the drive down before running it so this might mean the problem is going to show up again on 01 Feb 2023. Even if the issue doesn't occur again in Feb, I'm always going to wonder if it will suddenly show up again at a later date. Still begs the question why this would suddenly start happening after years of problem-free operation and no changes to hardware/software/OS around time of first occurrence. This is a ugly problem and huge time waster when it happens. Rebuilding the array and re-checking parity is not fun. If this happens again to me, I'll follow up in this thread. If it doesn't it seems either: - The Seachest solution doesn't work for the st10000dm0004 drive I started having problems with; or - My IBM M1015 went bad (which makes no sense given that this is only happening on one drive ....so far); or - The IBM M1015 simply decided it doesn't like that drive anymore for some reason: or - We're still missing part of what the cause of this issue is I'm going to go with the that last guess.... Possibly MTF.

The container for me ran fine for a few months. Zero problems. Then one day, it started constantly falling over. Wouldn't start, would crash all the time. Just unending issues. I spent weeks trying to get it working properly. Deleted/wiped everything multiple times, tried tons of different settings but in the end I just gave up and installed the container on an Unbuntu VM and same as others have said, works properly with none of these problems. If the Unraid container works fine for you, great but don't be surprised if it just suddenly fails some day for no apparent reason. This thread is full of people talking about the same unexplained problems.

The Ubuntu VM thing was me. Still running with zero problems. Once again, sorry but the container just doesn't work or if it does, it won't for long.

I have the same problem(s) that other have reported in this thread. After a month of constantly messing around with then wiping the container before it once again inevitably crashes, I've given up and installed the controller in an Ubuntu VM. Works fine and doesn't have any of these problems. Something just isn't right with this container. I run lots of other containers in Unraid and had/have none of the issues this one has.

The workaround I've come up with for the time being is to just use NFS instead. Initially, I thought that wasn't working properly either but I just noticed it actually now is working properly on the affected Windows 10 box where SMB still isn't.

I'm on Windows version 20H2 build 19042.746 and I have also spent hours on this. I've tried every single suggestion in this thread (and others in the forum) and nothing works. Like others have said, the registry settings also aren't even there now so that tip is now irrelevant. I even tried to create a DWORD entry and gave it the appropriate value but still no go.

That was it. I guess I'm an idiot. Mine doesn't seem to show "abc" as the password. Instead, it shows only the MD5 hash so I assumed I had to use it (which did seem weird to me). So I had been using u:abc p:md5hash Thanks!

Thanks for responding so quickly. So far, I have tried: -Clearing all browser data -Delete and re-install container -Separate browser -Blank username/password (instead of the ones that appear in the default config) None of the above has worked so far.

After installing the container, I end up stuck at the Apache Guacamole login prompt. I've tried the listed username/password in the config and they don't work - neither does changing them.