Nomar1245

Thank you. Testing now. I'll report back when I know more. Update: I cheated and did a classic full RAM reseating instead of trying stick by stick. So far so good. 17% done with consistent speeds. Thanks again. I'll follow up once more if there's another failure and I will test RAM stick by stick. Promise. Update 2: I'm at 91% and everything is still moving along nicely. Thank you again. I'm comfortable say it's solved even if that means jinxing it. Thanks again.

Hello, I took a drive out of my array and can't get Partiy Check to complete. I used unbalanced to scatter my data across the rest of my drives. I then did a new config and set all of my array drives back to the correct configuration. I disabled Mover (by scheduling it for a month from the day before I made the change) set my Parity Drive back where it should be, and restarted the array. It got to .5% complete after several hours over night. I then removed the parity drive from the UI, not physically, and unassigned that drive to parity. Then started it up. Then stopped and put it back to force it again. Then my server began crashing. No UI, no SSH access. I updated to the latest version of Unraid, and tried again. This time I was able to get to 1.6% in about 15 minutes. Then it stopped again. The server is more stable and its not crashing, but it isn't progessing. It's just sitting at an estimate speed of 5.2 MB/s, and the ETA is climbing , now up to 35 days. If I look above, the parity drive does not show any rights, and the array drives don't show any reads. I tried to cancel parity, but that function is not working. Attached are my diagnostic logs. Here are some other notes: 1. All my shares are back without issue 2. When a parity disk isn't assigned I can access those shares from my computers without issue. Initially, I had the shares mapped as shared drives on my Windows computers, and just by having them mapped, they were locking up 2 of my windows computer. The second I shutdown the server, my computers work perfectly again. No more Explorer hangs 3.I have 2 cache drives and both were assigned back correctly too 4. I have docker containers, but I turned off docker to allow the parity check to complete 5. I did the same with my VMs for the same reason. 6. This is the same parity drive that I have been using for quite some time.kong-diagnostics-20260120-0825.zip Thanks for the help.

Everything has been fine for about 3 hours now which is longest it has working in about 2 weeks. I think this has been solved. Thank you.

Running now with -L instead Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... ALERT: The filesystem has valuable metadata changes in a log which is being destroyed because the -L option was used. - scan filesystem freespace and inode maps... clearing needsrepair flag and regenerating metadata agi_freecount 285, counted 286 in ag 3 agi_freecount 285, counted 287 in ag 3 finobt sb_ifree 2988, counted 2989 sb_fdblocks 2269434669, counted 2296675626 - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 5 - agno = 2 - agno = 11 - agno = 4 - agno = 6 - agno = 8 - agno = 7 - agno = 10 - agno = 9 - agno = 3 - agno = 1 - agno = 12 - agno = 13 - agno = 14 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... Maximum metadata LSN (1:2155061) is ahead of log (1:2). Format log to cycle 4. done It's been ~30 minutes and everything looks to be good. I'll follow up later this evening to confirm all is well. Thanks.

This is the result, almost immediately: Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... ERROR: The filesystem has valuable metadata changes in a log which needs to be replayed. Mount the filesystem to replay the log, and unmount it before re-running xfs_repair. If you are unable to mount the filesystem, then use the -L option to destroy the log and attempt a repair. Note that destroying the log may cause corruption -- please attempt a mount of the filesystem before doing this. Smart Erro Log Shows: No Errors Logged Smart Short Test returned: Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Short offline Completed without error 00% 213 - # 2 Short offline Completed without error 00% 158 -

Running now.

I keep having shares disappear within about an hour of starting the array. Same thing happens after reboot. After a period of time my disk10 shows the following instead of shares. Its the only disk that does this which was replaced about a month ago, but this has only started happening in the last few weeks: My troubleshooting: I've disabled all of my docker containers except 2 that I've literally been using for years. I've removed priviledge access where it was enabled from dockers. I've run a check disk via Maintenance Mode. I've run multiple parity checks. The first fixed ~3300 errors, and the subsequent ones have not found any. Reboot solves it temporarily Stopping and starting the array solves it temporarily. I'm getting a replacement drive just in case, but I thought it would be silly to not explore all problem points while I wait for it to arrive. kong-diagnostics-20240905-1215.zip

Well there we are on the same page. I’ve been running the test for a bit more than an hour now.

While I understand what your saying, the odds of the same exact problem happening before and after replacing the RAM has to be astronomical.

Thanks. It makes me feel a bit better to find out I was on the right path. At this point it seems the board or CPU are failing. The memory that is installed is less than a week old.

Over the last few weeks I've been having increasing problems with my server. First it would lock up entirely and require a hard shutdown and reboot. It happened a few times and initial testing had me believe the memory was starting to fail. I replaced it but then my docker containers would start to freeze. I mostly use Emby and was starting to see read-only permissions errors, so I deleted and recreated my docker image. The problem is persisting though, and I have no idea why. The only thing I think I'm noticing is that it freezes while parity check is running, which I know shouldn't be a real problem as I've run it on the monthly schedule for years now without any interruption other than mild performance issues. I was in tstark-diagnostics-20230810-1645.ziphe process of preparing it to a move into a new system, but can't seem to nail down the problem. My diagnostic logs are attached, and my system is currently completing a parity check again. So far 0 errors, @ ~45% with another 12 hours or so to go. Any help would be appreciated. I'm very tempted to reset the entire environment and start from scratch, but I'd really prefer to avoid that.

Awesome. It's working perfectly now. Thank you.

It looks like the last Variable is labeled as custom, but is actually for choosing Subtitle Language. I've tried adding the -non-strict argument after creating the AMC_CUSTOM_OPTIONS key, but it doesn't seem to be working for me. I'm doing so in response to this error without -non-strict: [amc] CmdlineException: Multiple options: Advanced auto-selection requires -non-strict matching

Thanks for the help.I was under the impression that only_subdomains was needed because I was using duckdns.org. However, after I removed my existing container, recreated it with the same settings, except for changing only_subdomains to false, I am having the same problem. Update: It's working So, I setup my docker using a guide that took me 90% of the way, but the last 10% is what I needed. After replying to aptalca, I stepped back and looked at everything I was doing and decided to work through on my own, one step at a time, and the culprit ended up being a bad default file. I should have known better. Thank you for the help.

I was able to get LetsEncrypt to work with DuckDNS but it only works when I enter www.[myduckdnsdomain].duckdns.org, or https://www.[myduckdnsdomain].duckdns.org. If I enter just [myduckdnsdomain].duckdns.org it loads but says Your Connection is not valid. If I try https://[myduckdnsdomain].duckdns.org it loads a page that says my connection is not private. I've searched but can't find any answers. If I'm honest I'm not even sure what I should be searching for.