nicosemp

Hi, I'm posting about the recent warning in the changelog. This sentence caught my eye in particular: Are breaking changes being introduced without being mentioned in the changelog, or is it just like "random mistakes happen, so if it works now don't update"? I always keep plugins up to date because there might be new features, in this case a UI improvement for example. Updating might also be necessary to support newer UNRAID versions. Not sure what the best course of action is, should I really stop updating? Either way thank you for your work 🙏

Thank you for the quick response and the effort @zspearmint Much appreciated! Of course the solution is to change the server description to abba: lowercase letters a and b only to avoid problems /s

Hi! Thanks for the quick reply @zspearmint I tried reinstalling but the issue persists unfortunately. I don't have a huge amount of plugins, but you can see for yourself in the attached Diagnostics. unraid-home-diagnostics-20230907-2208.zip These are the console errors I see. Please let me know if there's private information I should have hidden, the server url is partial so it should be fine. Thanks a lot! Nico

Today I updated the plugin to version 2023.09.06.1307 The menu on the top right completely disappeared (no UNRAID logo, nothing at all), I had to navigate to /Connect manually. Each page was painfully slow. I saw errors in console by the thousands: about 20k errors every 5 seconds. I couldn't even close the inspector because it froze. The /Connect page showed the server as connected, and going to https://connect.myunraid.net/ I could see my server with all its info. So this seems like a frontend issue only. However the /Connect page also showed "status: Stale server" or something like that in red. Not sure if this helps. I was finally able to uninstall the plugin despite the super slow screens. I hope this is already being fixed and I will reinstall as soon as it is!

I moved the data from the cache to the array before upgrading the 256GB SSDs to 1TB ones. I might have just replaced them without "resetting". So by "resetting the pool" you mean - unassign both old SSDs - start the array - stop the array - assign the new SSDs - start the array correct?

Why is this necessary? It just happened to me too, and I nearly panicked before finding this solution. What happens to the cache configuration that resets it to the old state (before the SSD were swapped)?

I installed the patch a few weeks ago and it worked well initially. Now I'm getting "not available" on 3 separate dockers again.

0 errors again in October and November: it was the Asmedia controller indeed. Thank you @JorgeB!

I replaced the Asmedia controller with a Startech 8P6G-PCIE-SATA-CARD and the September parity check gave 0 errors! I've had 0 errors with the Asmedia a few times too, so I'll wait for 3 consecutive months with no errors to call it a victory. Thank you so much!

I ran a correcting parity check right after the July 1st one, which was non-correcting, to fix those 2 errors. Today's check was also a non-correcting one: it's scheduled for the 1st of the month, and the errors came back. I will try a different controller asap and report back, thank you!

Hi @JorgeB, here's the new Diagnostics as promised. It seems like the 2 errors are on the same sectors. July 1st: Jul 1 05:50:44 unraid-home kernel: md: recovery thread: P incorrect, sector=3519069768 Jul 1 05:50:44 unraid-home kernel: md: recovery thread: P incorrect, sector=3519069800 August 1st: Aug 1 05:49:49 unraid-home kernel: md: recovery thread: P incorrect, sector=3519069768 Aug 1 05:49:49 unraid-home kernel: md: recovery thread: P incorrect, sector=3519069800 Am I looking at the right data? What does this mean and how can I solve this? Thank you! unraid-home-diagnostics-20220801-1120.zip

Thanks for the reply. It would make sense to find them in the same sectors again. So diagnostics show the sectors where the errors are found? I didn't know this, where should I look inside the zip file? but I just found them. I will correct parity right now and report back next month, when I expect the 2 errors to come back. Thank you! EDIT: found the sectors near the end of ./logs/syslog.txt

Hello, so I have read through tens of posts from people having errors but it was always their problem only, found by looking at their diagnostics. My server has three 4TB disks of which one is parity. I have a non-correcting parity check scheduled every first of the month, it lasts about 8 hours and (almost) always finishes with 2 errors (see attached screenshot). Mind you it's exactly 2! Either no errors (rare) or 2. As I read on the forum, what I usually do in case of 2 errors is run a correcting parity check, which finds those 2 errors and corrects them. Then I run another non-correcting parity check and I get no errors (they were just corrected). The problem is that the 2 errors come back the next month. If I'm lucky I get one error-free month but I have never had two months without errors, even if they're just 2 errors. I should mention that I never had any problems with files or anything. I also ran a SMART short self-test on all three drives, which finished with no errors. I attached my diagnostics, downloaded right after a parity check finished with 2 errors. I'll be keeping the server on for additional information if needed. Any help is greatly appreciated! It would be great to understand why this happens, even if there is no solution. unraid-home-diagnostics-20220701-1037.zip

So apparently this was caused by having directories, subdirectories and files in the appdata/<plex appdata> directory owned by root:root. Everything should be owned by nobody:users (as long as the container is running as nobody:users). I managed to solve this by running: sudo chown -R nobody:users /mnt/user/appdata/<plex appdata> I suggest you first stop Plex. Copy the "appdata/<plex appdata>" to a "appdata/<plex appdata>_BKP" backup folder. Rename the old one as <plex appdata>_ORIGINAL and remove "_BKP" from the copied one. -> The switcheroo is because by copying from root the new files will be owned by root:root. This makes it possible to revert everything in case it doesn't work: the original folder is renamed but untouched otherwise. Run the command above on the copied one, which is now called just <plex appdata>. This is the gentleman who explained everything. NOTE: <plex appdata> is the name of your Plex Media Server appdata directory.

Just tried and the exact same problem persists. Reverting until this gets fixed. Not for me unfortunately, I just re-upgraded and it showed the correct 'nobody'.