NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
ReadyNAS Ultra 4 "Volume scan found errors that it could not easily correct."
Hi all! First time poster, long time lurker. After years of happy use of the Ultra 4, I have my first (major) issue. None of the shares are mounting, presumably due to the missing volumes. Fur...
One option is to contact support, and ask about data recovery. It is expensive (starts at $200).
Is ssh enabled? if not, you can try installing the enable root ssh add-on from here: https://kb.netgear.com/24551/ReadyNAS-Add-ons-for-RAIDiator-4-2-x86?cid=wmt_netgear_organic
You can then ssh into the NAS - the logon is "root", the password is the NAS admin password.
Excellent, I'm in as root and have been investigating. It seems that I keep circling around the following error:
EXT4-fs (dm-0): ext4_check_descriptors: Block bitmap for group 17216 not in group (block 623566614080)! EXT4-fs (dm-0): group descriptors corrupted!
I found a few descriptions of a similiar problem, each mildly horrifying and all fairly dated. Looks like I can pursue a few options
1) mke2fs - Seems the safest approach, any method to the madness?
2) Reboot without the volume check - Instructions say this is risky, but no reason given.
3) Mount with fuse and copy of the data to a new drive - All instructions point to use of ext2 which doesn't make sense to me.
4) Run fsck.ext4 - Seems I may lose data, but the disks didn't have any failures before....
5) ???
More info
# lvs LV VG Attr LSize Origin Snap% Move Log Copy% c c -wi-a- 3.85T # pvs PV VG Fmt Attr PSize PFree /dev/md2 c lvm2 a- 685.12G 0 /dev/md3 c lvm2 a- 3.18T 5.00G # mount /dev/c/c /c mount: wrong fs type, bad option, bad superblock on /dev/c/c, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so
# lvscan
ACTIVE '/dev/c/c' [3.85 TB] inherit
# cat /proc/mdstat
Personalities : [raid0] [raid1] [raid10] [raid6] [raid5] [raid4]
md3 : active raid5 sda6[0] sdc6[2] sdb6[1]
3418630528 blocks super 1.2 level 5, 64k chunk, algorithm 2 [3/3] [UUU]
md2 : active raid5 sda5[0] sdd5[3] sdc5[5] sdb5[4]
718431744 blocks super 1.2 level 5, 64k chunk, algorithm 2 [4/4] [UUUU]
md1 : active raid5 sda2[0] sdd2[3] sdc2[5] sdb2[4]
1572672 blocks super 1.2 level 5, 64k chunk, algorithm 2 [4/4] [UUUU]
md0 : active raid1 sdc1[5] sdb1[4] sda1[0] sdd1[3]
4194292 blocks super 1.2 [4/4] [UUUU]
unused devices: <none>
mke2fs creates a new file system, so I am puzzled why you'd want to do that. If you are ok with the data loss, a factory reset would be the next thing to try.
I'd probably try booting w/o the volume check next myself.
StephenB wrote:mke2fs creates a new file system, so I am puzzled why you'd want to do that. If you are ok with the data loss, a factory reset would be the next thing to try.
I'd probably try booting w/o the volume check next myself.
Thanks for taking the time to respond and sorry my explanation was poor as I've been reading article after article to beef up my understanding without doing any harm. Data loss is not okay in this case. Over the years, my backup discipline atrophied and there is a lot of information I need to rescue.
Specifically, my focus is around mke2fs as my errors leads me to believe that I have a corrupt superblock on /dev/c/c. My reasons for believing this are:
- dmesg | grep EXT4
EXT4-fs (dm-0): ext4_check_descriptors: Block bitmap for group 17216 not in group (block 623566614080)! EXT4-fs (dm-0): group descriptors corrupted!
- mount /dev/c/c /c
mount: wrong fs type, bad option, bad superblock on /dev/c/c, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so - from the fsck.log
***** File system check performed at Tue Feb 7 12:28:16 EST 2017 ***** fsck 1.42.12 (29-Aug-2014) /dev/c/c: recovering journal /dev/c/c: Note: if several inode or block bitmap blocks or part of the inode table require relocation, you may wish to try running e2fsck with the '-b 32768' option first. The problem may lie only with the primary block group descriptors, and the backup block group descriptors may be OK. /dev/c/c: Block bitmap for group 17216 is not in group. (block 623566614080) /dev/c/c: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. (i.e., without -a or -p options)
Running
fsck.ext4 -v -n /dev/c/c
spews out uncountable inode conflicts.
My understanding is that
mke2fs -n /dev/c/c -b 4096
would display any superblock backups and that I could then try something like
mount -t ext4 -o ro,noload,sb=BLOCK# /dev/c/c /c
and be able to squirrel away any data before a rebuild.
Right now I'm running
smartctl --test=long /dev/sd[abcd]
to get some sanity about the state of the drives.
Thanks for any insight or ideas!
- dmesg | grep EXT4
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
