ReadyNAS Ultra 4 "Volume scan found errors that it could not easily correct."

Question

Hi all!&nbsp; First time poster, long time lurker.&nbsp;After years of happy use of the Ultra 4, I have my first (major) issue.&nbsp; None of the shares are mounting, presumably due to the missing volumes.&nbsp; Further inspection indicates that the disk space is full "3940 GB (100%) of 3940 GB used".&nbsp; While I suspect this is a red herring, it's possible a runaway process filled it up.&nbsp;Following is a snippet of the most recent logs:&nbsp;	Tue Feb 7 12:30:59 EST 2017	System is up.
	Tue Feb 7 12:29:59 EST 2017	The paths for the shares listed below could not be found. Typically, this occurs when the ReadyNAS is unable to access the data volume. share1 share2 share3
	Tue Feb 7 12:28:40 EST 2017	Volume scan found errors that it could not easily correct. Please ensure that you have current backups of all valuable data before performing a full volume scan by rebooting the NAS through Frontview with the volume scan option enabled.
	Sun Feb 5 06:41:28 EST 2017	RAID scrubbing finished on volume C.
	Sun Feb 5 03:03:28 EST 2017	The on-line filesystem consistency check completed without errors for Volume C.
	Sun Feb 5 03:00:03 EST 2017	The on-line filesystem consistency check has started for Volume C.
	Sun Feb 5 00:00:24 EST 2017	RAID scrubbing started on volume C.
	Sun Jan 29 06:43:35 EST 2017	RAID scrubbing finished on volume C.
	Sun Jan 29 03:03:29 EST 2017	The on-line filesystem consistency check completed without errors for Volume C.
	Sun Jan 29 03:00:03 EST 2017	The on-line filesystem consistency check has started for Volume C.
	Sun Jan 29 00:00:18 EST 2017	RAID scrubbing started on volume C.
	Sun Jan 22 06:43:26 EST 2017	RAID scrubbing finished on volume C.
	Sun Jan 22 03:03:35 EST 2017	The on-line filesystem consistency check completed without errors for Volume C.I do not have a current backup, and only have around 40GB on the NAS that is worth saving.&nbsp; Any way to mount these up temporarily to see if I can delete a gigantic file or save the vitals before a rebuild?&nbsp; Is Skip Volume Check the way to go?&nbsp;I'm on Ubuntu for debugging, but can also use Windows tools.&nbsp;Thanks for any help!

StephenB · Answer

One option is to contact support, and ask about data recovery. &nbsp;It is expensive (starts at $200).
&nbsp;
Is ssh enabled? &nbsp;if not, you can try installing the enable root ssh add-on from here: &nbsp;https://kb.netgear.com/24551/ReadyNAS-Add-ons-for-RAIDiator-4-2-x86?cid=wmt_netgear_organic
&nbsp;
You can then ssh into the NAS &nbsp;- the logon is "root", the password is the NAS admin password.

ManiacMike · Answer

Excellent, I'm in as root and have been investigating.&nbsp; It seems that I keep circling around the following error:&nbsp;&nbsp;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.&nbsp; Looks like I can pursue a few options&nbsp;&nbsp;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) ???&nbsp;More info&nbsp;# 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: &lt;none&gt; &nbsp;&nbsp;

StephenB · Answer

mke2fs creates a new file system, so I am puzzled why you'd want to do that. &nbsp;If you are ok with the data loss, a factory reset would be the next thing to try.
&nbsp;
I'd probably try booting w/o the volume check next myself.

ManiacMike · Answer

StephenB wrote:mke2fs creates a new file system, so I am puzzled why you'd want to do that. &nbsp;If you are ok with the data loss, a factory reset would be the next thing to try.&nbsp;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.&nbsp; Data loss is not okay in this case.&nbsp; Over the years, my backup discipline atrophied and there is a lot of information I need to rescue.&nbsp;Specifically, my focus is around mke2fs as my errors leads me to believe that I have a corrupt superblock on /dev/c/c.&nbsp; My reasons for believing this are:dmesg | grep EXT4EXT4-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 /cmount: 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 sofrom 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)                                                                                
   Runningfsck.ext4 -v -n /dev/c/cspews out uncountable inode conflicts.&nbsp;My understanding is thatmke2fs -n /dev/c/c -b 4096would display any superblock backups and that I could then try something likemount -t ext4 -o ro,noload,sb=BLOCK# /dev/c/c /cand be able to squirrel away any data before a rebuild.&nbsp;Right now I'm runningsmartctl --test=long /dev/sd[abcd]to get some sanity about the state of the drives.&nbsp;Thanks for any insight or ideas!

ManiacMike · Answer

Guess I'll just post here for posterity as there aren't any clear examples around on how to debug these issues or determine severity.&nbsp;&nbsp; Right now I'm still stuck in the information gathering phase to ensure any future actions do not corrupt what is there.&nbsp;mke2fs has a sister command dumpe2fs which seems safer and also finds any backup superblocks.&nbsp; In my case, it's not so clean and spews out messages like...
  32768 free blocks, 2048 free inodes, 0 directories
Group 31383: (Blocks 1028358144-1028390911) [INODE_UNINIT, ITABLE_ZEROED]
  Checksum 0x43bc, unused inodes 0
  Block bitmap at 1028128775 (bg #31376 + 7), Inode bitmap at 1028128791 (bg #31376 + 23)
  Inode table at 1028129696-1028129823 (bg #31376 + 928)
  32768 free blocks, 2048 free inodes, 0 directories
Group 31384: (Blocks 1028390912-1028423679) [INODE_UNINIT, ITABLE_ZEROED]
  Checksum 0x9999, unused inodes 0
...I didn't let it finish as I believe I read somewhere that ReadyNAS has a non-default block size and am trying to determine if this is why fsck wants to relocate all inode block bitmaps.&nbsp;# 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]
      All disks check out fine after the smartctl tests, sdd showed some signs of wear and should be replaced, but nothing at critical levels.

Forum Discussion

ReadyNAS Ultra 4 "Volume scan found errors that it could not easily correct."

6 Replies

Related Content

ReadyNAS Duo v1 boot fail into "Volume scan found and corrected errors"

ReadyNAS 214 "Remove inactive volumes to use the disk. Disk #1,2,3,4."

Help! -Readynas Pro Business Edition - "Volume scan found errors that it could not easily correct. "

ReadyNAS Ultra 4 "Volume data is degraded"

"Remove inactive volumes to use the disk. Disk #1,2,3,4", ReadyNAS 204

NETGEAR Academy

ProSupport for Business