Boy Kai

This is super helpful! Thank you so much. I'll give it a try.

Thanks! If I stop the array and remove parity disk then start the array Will the 2 disabled disks become available as-is with their existing data on them? I'd assume, if I add parity drives back later - it will rebuild the array to update the parity sync?

I totally get USB is not recommended. I just don't have the money to buy a 4U setup right now to run them through SATA. I am a bit confused why the rebuild runs for ~8TB but fails at 30-40% for a 20TB rebuild. Also confused why the USB setup has been working for the past 2 years but is now facing issues. Is there something I can do without buying completely new hardware to address the disabled disk issues I'm facing currently?

Unfortunately this failed again. It always fails around 35 - 40%. Not sure why or what to do to resolve. diagnostics-20260113-2112.zip

Thanks! I'll give it a try. Rebuilding 1 disk at a time and swapping USB ports.

I've had this setup for a couple years. Not sure how this is related to the new issues I've been having. Would appreciate some guidance. I plan on upgrading my server but right now prices are insane. Would like to resolve without having to get a 4U setup.

14 of the drives are on these: https://www.amazon.com/dp/B07Y4F5SCK 9 drives https://www.amazon.com/dp/B09TV1XPDD 5 drives The rests are in the actual PC case. Which are powered with a 850W PSU. 8 drives

Hey everyone! Would appreciate some guidance here, as I'm at a loss. I was out of town for a few weeks and came back to 2 drives 'Device is Disabled, Content Emulated'. Luckily I have 2 parity drives. I ran SMART tests on the drives, everything seems fine. I shutdown my server, I took them out and put them back into their drive bays, booted the server, then stop the server, removed the drives from the array, started the server in maintenance mode, then shutdown the server again, added the drives back into the array, and booted up the server again. The data rebuild started - great. About 40% of the way through - the data rebuild stops/fails. It also kicks out multiple drives into Unassigned Devices. They now show with a * temperature, and throw disk errors during data rebuild. This is for both the drives being rebuilt, parity, and other random drives. Also, my 'appdata' and 'system' shares disappeared. This whole process has happened 3 times now - and I'm at a loss of what to do to properly rebuild the data disk. What's worse is it takes days to hit the issue due to rebuilding 20TB at 60MB/s. Please help! diagnostics-20260111-1235.zip

Perfect! I knew I must have been missing something. Thank you!

There are a ton of threads on Docker VDisk, and how to resize and increase the size. A lot of guidance says to check docker paths in configs to resolve issues. I have yet to come across guidance on how to determine which dockers are utilizing what size on the Docker VDisk. Is there a simple way to check which Dockers are the offenders before deep diving into config settings for a fix? Would be great if this was added into the UI natively, maybe it is and would love an assist to point me to it's location. Thanks in advance!

Thanks @Squid ! Do I need to attempt to move/merge the files into cache or just delete the shares manually and reboot? Should I backup the shares or anything like that?

@alturismo - do you know if there's a way for me to check what created the shares? The only real changes to my setup has been https://github.com/plexguide/Huntarr.io But I also don't know if this has something to do with Unraid +7.X and depreciating plugins or something like that.

Any chance anyone knows if this is related? Noticed I have +20 shares that have appeared out of no where. Not sure where they came from or how to update/handle them. Any suggestions? (images) My Unraid system keeps crashing after 10 minutes of being powered on. Not sure what's happening. If I disable all Dockers, it runs fine. I am slowly turning on Dockers 1 by 1 to see if I can identify the problem. Unraid OS version: 7.0.1

Noticed I have +20 shares that have appeared out of no where. Not sure where they came from or how to update/handle them. Any suggestions? (images) My Unraid system keeps crashing after 10 minutes of being powered on. Not sure what's happening. If I disable all Dockers, it runs fine. I am slowly turning on Dockers 1 by 1 to see if I can identify the problem. Unraid OS version: 7.0.1 Thanks for the help! laughingman-diagnostics-20250524-1024.zip

Frigate is not an issue for me either, not using it. I did the following....went from 100% CPU to 80% - 90% CPU usage. So not fixed but usable.... - Deleted docker.img - Re-installed each docker 1 by 1 There is something seriously wrong with Unraid. Definitely not performing normally. Would love if someone could take a look at diagnostic logs and help point these folks in the right direction for resolution.

Seems like this might be a more general issue users are experiencing. Anyone have any suggestions on resolution?

This started happening a couple days ago. I can no longer run Docker without it maxing out my CPU. Not sure what's going on. As soon as I reboot or start/restart Docker in Unraid, my CPU usage goes from <10% to 100%. Looking at htop it seems to be: /user/bin/dockred -p /vasr/run/dockerd.pid --log-opt max-size=500m max-file=1 --log-level=fatal --storage-driver=btrfs I have tired turning 1 docker on at a time, with mixed results. Sometimes it will be fine, then hours later decide to kick off. Other times, every docker startup will cause this. I have also tried restarting docker in settings and increasing the image disk size limit to 200GB. Looking for some guidance on what might be causing the issue. Thanks in advance! Unraid 6.12.14 (was also happening with 6.12.6) BK-diagnostics-20250105-1333.zip

Awesome! The array seems to be rebuilding now. THanks @trurl for that doc link and lost+found confirmation. Saved me a lot of time searching. Wish I could mark 2 posts as Solution. Thanks again!! QQ. Is it clear why this happened? Is there a way I can avoid in the future?

Ran another Diagnostics after running -L on Disk 8 and Disk 12 and then booting in Normal Mode. Wanted to share - if it's helpful. kai-diagnostics-20240509-0902.zip

Unfortunately, the Disk 8 and Disk 12 are still showing red Xs. Ran -L for Disk 12 as well (before starting in Normal Mode): Phase 1 - find and verify superblock... sb root inode value 18446744073709551615 (NULLFSINO) inconsistent with calculated value 128 resetting superblock root inode pointer to 128 sb realtime bitmap inode value 18446744073709551615 (NULLFSINO) inconsistent with calculated value 129 resetting superblock realtime bitmap inode pointer to 129 sb realtime summary inode value 18446744073709551615 (NULLFSINO) inconsistent with calculated value 130 resetting superblock realtime summary inode pointer to 130 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 sb_icount 0, counted 57504 sb_ifree 0, counted 11834 sb_fdblocks 4882434433, counted 1257858882 - 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 out-of-order bmap key (file offset) in inode 19381809594, data fork, fsbno 2427919491 bad data fork in inode 19381809594 cleared inode 19381809594 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 - agno = 16 - agno = 17 - agno = 18 - 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 = 1 - agno = 3 - agno = 9 - agno = 11 - agno = 12 - agno = 13 - agno = 4 - agno = 6 - agno = 14 - agno = 15 - agno = 7 - agno = 8 - agno = 10 - agno = 2 entry "Preacher.S02E01.2160p.WEB.H265-PETRiFiED.mkv" in shortform directory 19381809593 references free inode 19381809594 junking entry "Preacher.S02E01.2160p.WEB.H265-PETRiFiED.mkv" in directory inode 19381809593 corrected i8 count in directory 19381809593, was 4, now 3 - agno = 16 - agno = 17 - agno = 18 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 (9:2219024) is ahead of log (1:2). Format log to cycle 12. done

Apologies for the delayed post. Was traveling. Here are the results from running: -L Phase 1 - find and verify superblock... sb root inode value 18446744073709551615 (NULLFSINO) inconsistent with calculated value 128 resetting superblock root inode pointer to 128 sb realtime bitmap inode value 18446744073709551615 (NULLFSINO) inconsistent with calculated value 129 resetting superblock realtime bitmap inode pointer to 129 sb realtime summary inode value 18446744073709551615 (NULLFSINO) inconsistent with calculated value 130 resetting superblock realtime summary inode pointer to 130 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 sb_icount 0, counted 74368 sb_ifree 0, counted 20780 sb_fdblocks 4394060173, counted 1298698275 - 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 - agno = 15 - agno = 16 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 2 - agno = 1 - agno = 4 - agno = 5 - agno = 10 - agno = 7 - agno = 3 - agno = 12 - agno = 14 - agno = 9 - agno = 15 - agno = 6 - agno = 11 - agno = 13 - agno = 8 - agno = 16 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 (16:410369) is ahead of log (1:2). Format log to cycle 19. done

Here is the filecheck output. Phase 1 - find and verify superblock... bad primary superblock - bad CRC in superblock !!! attempting to find secondary superblock... .found candidate secondary superblock... verified secondary superblock... would write modified primary superblock Primary superblock would have been modified. Cannot proceed further in no_modify mode. Exiting now.

Hey everyone. Would really appreciate some help here. I went out of town for 3-4 days, and returned to drives having a bunch of errors. I did a safe restart via Unraid UI. When my server rebooted - 2 of 17 (19 with parities) drives are labeled as 'Disabled' and 'Unmountable:Unsupported or no file system'. Please help! Thanks in advance. kai-diagnostics-20240506-1726.zip

Hey JorgeB. I appreciate the responses here but it's also kinda frustrating. I took the time to outline what I've tired and the issues I'm facing, included screenshots and logs. And the responses I'm getting are single sentences with no path to resolution or troubleshooting. Then what? lol

Alright. Is there an action I can take to reduce the spam?