July 13, 20241 yr Hi I’m not sure if it was after rebooting unRaid, or if the problem was already there, but one of the disks in the array is showing the error “Unmountable: Unsupported or no file system.” According to S.M.A.R.T, the disk seems to be fine. I would really appreciate the help; I’ve been dealing with this all day and I’m desperate. I understand that, as a last resort, I can buy a new disk, replace it, and rebuild the data from the parity disk, right? I’m attaching the diagnostic file. Thank you for your help microserver-diagnostics-20240713-1046.zip
July 13, 20241 yr That's a filesystem problem, not disk problem, you need to check filesystem and repair if needed. Replacing the disk and rebuilding would likely rebuild the same broken filesystem. Edited July 13, 20241 yr by Kilrah
July 13, 20241 yr 41 minutes ago, Diego Tr said: I can buy a new disk, replace it, and rebuild the data from the parity disk, right? No. If a disk shows unmountable before the rebuild then it you should expect it will show as unmountable after the rebuild. Handling of unmountable disks is covered here in the online documentation accessible via the Manual link at the bottom of the Unraid GUI. In addition every forum page has a DOCS link at the top and a Documentation link at the bottom.
July 13, 20241 yr Author Thank you very much for your help I have run the check and this is the result: Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... Log inconsistent (didn't find previous header) failed to find log head zero_log: cannot find log head/tail (xlog_find_tail=5) - scan filesystem freespace and inode maps... sb_fdblocks 2076704, counted 5488271 - found root inode chunk Phase 3 - for each AG... - scan (but don't clear) agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - 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 = 3 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem ... - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify link counts... Maximum metadata LSN (17:1514943) is ahead of log (0:0). Would format log to cycle 20. No modify flag set, skipping filesystem flush and exiting. I suppose I will have to run the check again, removing the -n option, right?
July 13, 20241 yr 8 minutes ago, Diego Tr said: I suppose I will have to run the check again, removing the -n option, right? Yes (and if it ask for it add -L). After doing that the drive should now mount when the array is restarted in normal mode.
July 13, 20241 yr Author Finally, the disk has mounted :). Unfortunately, all the Docker containers and VMs have disappeared. I am reinstalling the containers from Previous Apps, which seems to be going smoothly. As for the VMs, I understand that there is no easy solution; in any case, I don't care about them as much as the docker containers...
July 13, 20241 yr 34 minutes ago, Diego Tr said: mounted :). Unfortunately, all the Docker containers and VMs have disappeared. This seems a bit strange. Where were the files for these located? It might be worth posting new diagnostics to see if there is something else going on. 36 minutes ago, Diego Tr said: As for the VMs, I understand that there is no easy solution If the vdisks are intact you can always recreate these and assign the disks to them.
July 13, 20241 yr Author Yes, I see that the VMs are on another disk, in /mnt/disk3/domains. Before recreating them, I’m attaching the diagnostic file, in case you can think of a way to recover them microserver-diagnostics-20240713-1641.zip
July 13, 20241 yr I see the system share is on multiple drives system shareUseCache="yes" # Share exists on cache, disk1, disk2 Normally you want this all on the cache for performance reasons. Typically there are only 2 files in this share: docker.img which holds all the binaries for docker containers libvirt.img which holds all VM definitions It might be worth checking if you have duplicates of any of these files. This can happen if you have a drive problem and the system creates a new blank copy of either of these files. It might also explain your containers and/or VMs disappearing.
July 13, 20241 yr Author Indeed, I see that I have the docker.img and libvirt.img files duplicated: in cache and in disk1, which was the one with the corrupted file system. The size of the docker.img file is different in each location. What should I do now, then? Should I change the settings of the system share to indicate secondary storage: None, and delete the system directory on disk1? Sorry for asking so many details, but I’m afraid of making things worse.
July 13, 20241 yr Solution The versions on the cache would take precedence over those on the array. It is quite possible the array versions would have your docker and BM settings. my suggestion would be: stop docker and VM services under Settings. Rename the docker.img file and libvirt.img file to something else (so you can revert later if needed) move the copies on the array to the ‘system’ folder on the cache drive and then delete the ‘system’ folder from there. set secondary storage for the ‘system’ share to none so they stay on the cache drive. re-enable the docker and VM services and see if you have things back as they were. If they are you can delete the renamed copies from earlier.
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.