kiwininja

Members
  • Posts

    21
  • Joined

  • Last visited

Converted

  • Gender
    Undisclosed

kiwininja's Achievements

Noob

Noob (1/14)

0

Reputation

  1. So the last couple days I've been getting a "500 Internal Server Error" message from the web GUI. I've tried restarting nginx but that didn't resolve the issue. The only way I can get it come back up is rebooting the sever, and then it works normally for about a day and then the error comes back. Today I finally had some time to look into it. When I logged in after rebooting I noticed a pop about some errors, went into Fix Common Problems and found a warning that clear-me.cfg, lost+found.cfg, and appdatabackup.cfg are all corrupted. Followed the link to this post so I grabbed the diagnostic file and now i'm here wondering if I need to replace my flash drive. Am I running on borrowed time here? Should I replace the flash drive asap? harrier-diagnostics-20231027-1259.zip
  2. Well, I had left in maintence mode and forgot that my monthly parity check is scheduled for the evening of the first. It's now in the process of rebuilding the drive, so I guess i'm just going to wait and see what happens.
  3. Ok, I mounted it in maintence mode, ran a check on it, found a bunch of errors, and went ahead and did a repair. The repair log is huge, +300k lines, but the bulk of it looks like this 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... Metadata CRC error detected at 0x43c89d, xfs_bnobt block 0x3c09dc188/0x1000 Metadata CRC error detected at 0x43c89d, xfs_bnobt block 0x311f56fd8/0x1000Metadata CRC error detected at 0x43c89d, xfs_bnobt block 0x417f1ea60/0x1000 btree block 11/8 is suspect, error -74 btree block 12/8 is suspect, error -74 bad magic # 0x7b50eae6 in btbno block 11/8 btree block 9/8 is suspect, error -74 bad magic # 0xc45ced5e in btbno block 9/8 bad magic # 0x96306338 in btbno block 12/8 Metadata CRC error detected at 0x43c89d, xfs_cntbt block 0x417f1ea50/0x1000 btree block 12/6 is suspect, error -74 bad magic # 0xf6500f3f in btcnt block 12/6 agf_freeblks 137168192, counted 0 in ag 12 agf_longest 136980482, counted 0 in ag 12 agf_btreeblks 10, counted 0 in ag 12 Metadata CRC error detected at 0x43c89d, xfs_cntbt block 0x311f56fc8/0x1000 btree block 9/6 is suspect, error -74 bad magic # 0xc45ceddd in btcnt block 9/6 agf_freeblks 153991353, counted 0 in ag 9 agf_longest 153690905, counted 0 in ag 9 agf_btreeblks 10, counted 0 in ag 9 Metadata CRC error detected at 0x46ad5d, xfs_inobt block 0x311f704b8/0x1000 btree block 9/12964 is suspect, error -74 bad magic # 0xe3a7d737 in inobt block 9/12964 inode chunk claims untracked block, finobt block - agno 9, bno 8300, inopb 8 inode chunk claims untracked block, finobt block - agno 9, bno 8301, inopb 8 inode chunk claims untracked block, finobt block - agno 9, bno 8302, inopb 8 inode chunk claims untracked block, finobt block - agno 9, bno 8303, inopb 8 inode chunk claims untracked block, finobt block - agno 9, bno 8304, inopb 8 inode chunk claims untracked block, finobt block - agno 9, bno 8305, inopb 8 inode chunk claims untracked block, finobt block - agno 9, bno 8306, inopb 8 inode chunk claims untracked block, finobt block - agno 9, bno 8307, inopb 8 undiscovered finobt record, ino 19327419232 (9/66400) undiscovered finobt record, ino 19327419296 (9/66464) undiscovered finobt record, ino 19327421536 (9/68704 Phase 3 - for each AG... - scan and clear agi unlinked lists... found inodes not in the inode allocation tree found inodes not in the inode allocation tree - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 Metadata CRC error detected at 0x4598a9, xfs_dir3_block block 0x3697b5500/0x1000 bad directory block magic # 0x94ddd42c in block 0 for directory inode 4299986059 corrupt block 0 in directory inode 4299986059 will junk block no . entry for directory 4299986059 no .. entry for directory 4299986059 problem with directory contents in inode 4299986059 cleared inode 4299986059 - agno = 3 - agno = 4 - agno = 5 - agno = 6 Metadata CRC error detected at 0x4598a9, xfs_dir3_block block 0x3c49f5eb0/0x1000 bad directory block magic # 0xf651cca3 in block 0 for directory inode 12888387655 corrupt block 0 in directory inode 12888387655 will junk block no . entry for directory 12888387655 no .. entry for directory 12888387655 problem with directory contents in inode 12888387655 cleared inode 12888387655 - agno = 7 - agno = 8 Metadata corruption detected at 0x435c33, xfs_inode block 0x2bab45be0/0x4000 Metadata corruption detected at 0x435c33, xfs_inode block 0x2bab45c00/0x4000 Metadata corruption detected at 0x435c33, xfs_inode block 0x2bab46440 bad CRC for inode 17181119776 bad magic number 0x566 on inode 17181119776 bad version number 0x24 on inode 17181119776 inode identifier 11108147623858496690 mismatch on inode 17181119776 bad CRC for inode 17181119777 bad magic number 0x6ad8 on inode 17181119777 bad version number 0x64 on inode 17181119777 inode identifier 13067490434406963586 mismatch on inode 17181119777 The bad CRC for inode, versino number, and magic number lines repeat forever, with some metadata corrouption detected errors every so often. Eventually it gets to phase 4 and I start seeing entries like these. Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 2 - agno = 4 - agno = 5 - agno = 1 - agno = 3 - agno = 0 entry "Prancer (1989).mp4" at block 0 offset 1824 in directory inode 4297828966 references non-existent inode 25773790676 entry "temp" in shortform directory 6442451040 references non-existent inode 19328899583 entry "Data" in shortform directory 10737418336 references non-existent inode 19327352928 clearing inode number in entry at offset 1824... junking entry "Data" in directory inode 10737418336 entry "Planet Terror (2007).mp4" at block 0 offset 2000 in directory inode 4297828966 references non-existent inode 23623319597 entry "64" at block 0 offset 144 in directory inode 8589934691 references non-existent inode 19327352929 corrected i8 count in directory 10737418336, was 5, now 4 clearing inode number in entry at offset 144... Phase 5 & 6 look like this. Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... entry "Wrestling" in dir ino 102 doesn't have a .. entry, will set it in ino 6658268659. entry "MMA" in dir ino 102 doesn't have a .. entry, will set it in ino 4522158591. entry ".." in directory inode 255489 points to non-existent inode 27984402686 bad hash table for directory inode 255489 (no data entry): rebuilding Phase 7 - verify and correct link counts... resetting inode 4297829346 nlinks from 6 to 5 resetting inode 4297829360 nlinks from 6 to 5 resetting inode 4297829376 nlinks from 8 to 7 resetting inode 6442451040 nlinks from 8 to 7 resetting inode 10737418336 nlinks from 7 to 6 resetting inode 17179869285 nlinks from 3 to 2 resetting inode 17179869286 nlinks from 3 to 2 resetting inode 23622320240 nlinks from 5 to 4 resetting inode 17179869303 nlinks from 4 to 2 resetting inode 23622320252 nlinks from 46 to 34 Once it completed I tried to bring the array online, but I now get a warring that all existing data on the device will be overwritten, so i'm not exactly sure where to go from here. I grabbed the SMART report for the drive as well. harrier-smart-20210301-1942.zip
  4. So I was replacing an old failing drive in my array and everything was going fine. When the process completed I was surprised to see a different drive in the array was now disabled. I have no idea how or why, there has been no issues with the drive previously, it had been working without issues for months. I stopped the array, rebooted the server, and now I'm getting the message that this drive is "Unmountable: No file system". I did some searching on the forums already and found this thread from a couple years ago: https://forums.unraid.net/topic/69765-solved-unmountable-no-file-system/page/2/ Not sure if I should follow the steps in that thread or not. Any help would be greatly appreicated. harrier-diagnostics-20210301-1359.zip
  5. Check finished late last night. 7321 errors, damn. I guess I better start looking though all the SMART reports.
  6. Well I started it and it's back! Thank you so much for all the help. I was really afraid I had lost everything for a while there. My new UPS is on the way and it looks like I need to do some preventative maintenance on some of my drives. Thanks again.
  7. If I don't know the correct slot for every data drive will this still work? Part of the problem is I don't have an up to date drive array configuration. From what I read so far it should work in theory as long as the parity drive is correct and the rest of the data drives can be in any order. I've got it up right now and I've got all the drives assigned and the "Parity is already valid" box checked. I haven't brought it online yet. Just double checking everything before I start it. Noted. Those damn Toshiba drives haven't had a good track record with me so far. I should probably look into replacing the other one after this is back up and running.
  8. It won't actually let me bring the array back online with all the disks in their respective slots. When I brought the array online before to determine which disk is the parity disk it ended up being in slot 4. When I move it from slot 4 to the parity slot I get the message "Too many wrong and/or missing disks!" I'm assuming it still thinks the parity drive is supposed to be in slot 4. I'm not seeing a trust parity option anywhere either. Edit: Enabled SMART on all the drives and pulled a new diagnostic file harrier-diagnostics-20160614-2124.zip
  9. Doing some more reading here. Now that I've got the parity drive in the correct slot and the rest of disks are in the array but not in the original order, do I have to delete the corrupt super.dat file and have unraid rebuild it?
  10. Success, all the drives show up in the UI. I went though and ran the blkid command and on all the drives and confirmed which one is the parity drive. Now when I assign all the drives to their proper locations I get a blue square infront of the parity drive and the slot I had the parity drive in earlier now says that the wrong disk is in there after adding the original disk back. I'm not exactly sure what the procedure should be from here.
  11. Alright, I'm an idiot, the supposedly bad drive is working fine. I got it to show up in windows after I double checked all the connectors on my HD dock. I'm going to put it back in the server and re-seat all the sata connectors. Hopefully then all the drives will show up. If that all works then is it safe to assign all the disks once I've confirmed which one is the parity disk? I'm assuming I'm in for a full parity rebuild unless there's a faster way to get it back up and running, since in theory all the data should be intact; I hope.
  12. Pulled the missing 2tb drive out of the server and put it in dock to see if I could run any diagnostics on it and I can't even get it to mount. So I guess I'll be installing my replacement spare that I have on hand. The one question I still have is if I'm 99% positive that I know which drive is the parity drive can I just assign it, bring the array back up, and then start rebuilding the drive that died?
  13. Here's the screenshot. I pulled all the drives and checked the serial numbers. The unmountable drive is in bay #1 on my server, which would make sense with how I built the server. I'm guessing it's probably the parity drive. I also figured out which drive is the missing one. There should be a 2tb western digital drive in the array that is currently missing. I double checked all the connectors, and re-seated it when I pulled them all out. I'm guessing that it might just have died during the power failure. So now the big question is, can I just reassign the drive that I believe to be the parity drive and bring it back online to verify that it works, then take the sever back offline to replace the dead 2tb drive? Or is there a better way to go about this?
  14. After doing a little more reading I went ahead and assigned the drives an started it up. One drive appeared as unmountable. Is it safe to assume this is my parity drive? If not, I'm going to start pulling drives and looking up serial numbers to see if I can figure out when they were purchased.
  15. Upon further inspection it would appear that one of the drives is not listed either. I have 15 drives in my array and it's only listing 14 plus my parity drive in the logs.