NVX: paths for the shares listed below could[Case #19821175]
I upgraded one of the drives, every thing was fine, expanded fine and I was accessing all files fine till today when:
Mon Nov 5 20:33:55 PST 2012 System is up. Mon Nov 5 20:33:55 PST 2012 The paths for the shares listed below could not be found. Typically, this occurs when the ReadyNAS is unable to access the data volume. media squid backup pub Mon Nov 5 20:33:39 PST 2012 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. Mon Nov 5 20:32:42 PST 2012 Rebooting device... Mon Nov 5 20:32:42 PST 2012 Please close this browser session and use RAIDar to reconnect to the device. System rebooting... Mon Nov 5 19:06:51 PST 2012 System is up. Mon Nov 5 19:06:51 PST 2012 The paths for the shares listed below could not be found. Typically, this occurs when the ReadyNAS is unable to access the data volume. media squid backup pub Mon Nov 5 19:06:30 PST 2012 Volume scan failed to run properly. Mon Nov 5 00:32:47 PST 2012 Powering off device Mon Nov 5 00:32:47 PST 2012 Please close this browser session and use RAIDar to reconnect to the device after it is powered back on. System powering off... Sun Nov 4 18:36:55 PST 2012 Fan will be recalibrated over the next few minutes. Sun Nov 4 18:29:56 PST 2012 ReadyDLNA media file rescan started. Sun Nov 4 18:21:42 PST 2012 System is up. Sun Nov 4 18:21:33 PST 2012 Your ReadyNAS device has been updated with a new firmware image. (RAIDiator-x86 4.2.21) Sun Nov 4 18:18:54 PST 2012 Rebooting device... Sun Nov 4 18:18:53 PST 2012 Please close this browser session and use RAIDar to reconnect to the device. System rebooting... Sat Nov 3 12:15:42 PDT 2012 Fan will be recalibrated over the next few minutes. Sat Nov 3 09:42:46 PDT 2012 Data volume has been successfully expanded to 4624 GB. Sat Nov 3 08:51:06 PDT 2012 System is up. Sat Nov 3 08:50:51 PDT 2012 Incompleted file system expansion detected. Resuming... Sat Nov 3 08:49:45 PDT 2012 Rebooting device... Sat Nov 3 08:49:45 PDT 2012 Please close this browser session and use RAIDar to reconnect to the device. System rebooting... Sat Nov 3 08:30:33 PDT 2012 Newly added drive has more space to expand the volume, will start volume expansion. Sat Nov 3 08:30:26 PDT 2012 RAID sync finished on volume C. Fri Nov 2 19:17:02 PDT 2012 RAID sync started on volume C. Fri Nov 2 19:16:42 PDT 2012 Data volume will be rebuilt with disk 2.
Re: NVX: paths for the shares listed below could[Case #19821
I sent the logs. btw at the end of dmesg.log I see: EXT4-fs (dm-0): ext4_check_descriptors: Block bitmap for group 11136 not in group (block 0)! EXT4-fs (dm-0): group descriptors corrupted!
at the end of the fs_check.log I see: Error storing directory block information (inode=60723475, block=0, num=1868706): Memory allocation failed e2fsck: aborted
***** File system check performed at Mon Nov 5 20:33:38 PST 2012 ***** fsck 1.41.14 (22-Dec-2010) /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 11136 is not in group. (block 0)
/dev/c/c: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. (i.e., without -a or -p options)
Re: NVX: paths for the shares listed below could[Case #19821
any one from good old team still works at netgear? I do not want port 23 to be open like this for a long time, specially if the password is the same password as other netgear products use.
why netgear doesn't use the same access path that ReadyNas remote uses? vs. telnet port?
btw, EXT4-fs was the buggy version 4.2.21 (Linux version 2.6.37.6.RNx86_32.1.4)? here is the reference to ext4 bug https://lkml.org/lkml/2012/10/23/690
I think my problem surface maybe because of selected "Volume Scan on boot" and fix quota option together (which seems to be fine on NV+ with no ext4 support ) but not good for the new ext4 support on NVX.
Re: NVX: paths for the shares listed below could[Case #19821
console wrote:
any one from good old team still works at netgear? I do not want port 23 to be open like this for a long time, specially if the password is the same password as other netgear products use.
If your router supports it you could have forwarded a different port to port 23 on the NAS.
console wrote:
why netgear doesn't use the same access path that ReadyNas remote uses? vs. telnet port?
NetGear does have a support tunnel that they can use. Provided that stays up they shouldn't need port forwarding setup. Though if for whatever reason that is not up if you haven't port forwarded to the NAS and give them your I.P. there would be delays.
Re: NVX: paths for the shares listed below could[Case #19821
the machine has been in "Tech support" mode for more than 10 hours, I don't think my case is in the hand of "Level 3 Engineers" yet. Is it safe to power down in "Tech support" mode? how? Level 2 support told me to follow this: http://www.readynas.com/kb/faq/boot/how ... _boot_menu and I did and update the case. but no information regarding when Level 3 folks will get to it.
Anyway, "Error storing directory block information (inode=60723475, block=0, num=1868706): Memory allocation failed" seems to imply that the solution might be to run fsck with local cache file. but where should the fsck local cache file go? can I just plug a USB flash drive and hope that the in "Tech Support" mode the USB gets mounted ? Is there a "Unofficial Tips" for running fsck on a large volume for NVX?
Re: NVX: paths for the shares listed below could[Case #19821
Leave it in tech support mode and wait for L3 support to take a look at it please. If they need you to connect an empty USB flash drive they would let you know.
Re: NVX: paths for the shares listed below could[Case #19821
11/11/2012 8:20:00 PM Case Number: 19821175 new level 2 says: "I have checked the serial number xxxxxxx and found that it is a ReadyNASRNDX4210 which is registered to John xxxxxx who is from Central Repair Service. "
still no level 3, level 2 can not figure out why the logs have a serial number that registers with support. when as a part of "NVX power supply failed [Case #16549165]" more than a year ago NETGEAR sent me this replacement! I even email them the picture from back of my NVX.
still waiting, the support really degraded vs. last year prompt service. missed the days that I just drove to infrant and gave them NV for repair.
Re: NVX: paths for the shares listed below could[Case #19821
I guess I am on my own. What causes all the superblocks copies to be corrupt? "According to our Level 3 Expert, all backup superblocks of your ReadyNAS had been destroyed. He tried all possible steps to recover the shares but he was unsuccessful. Data cannot be recovered anymore. I sincerely apologize for this inconvenience."
so I logged in to see if I can do some recovery after level 3 unsuccessful try. after search the forum inside and out: md* volume state are all clean. but: e2fsck: unable to set superblock flags on /dev/c/c
Any suggestion on what to try next?
Here is output of some of the commands: # mdadm -E -s ARRAY /dev/md/3 level=raid5 metadata=1.2 num-devices=3 UUID=1c397b13:3dcbf756:97044c5e:f32f1fad name=00223FAA11D8:3 ARRAY /dev/md/2 level=raid5 metadata=1.2 num-devices=4 UUID=eee7d234:6e0d5103:2ec686b0:a10a2e74 name=00223FAA11D8:2 ARRAY /dev/md/1 level=raid6 metadata=1.2 num-devices=4 UUID=62bc3ab8:b3b480c7:3fe0c84b:ed4e0bcd name=00223FAA11D8:1 ARRAY /dev/md/0 level=raid1 metadata=1.2 num-devices=4 UUID=7fd03cc1:2db7e12d:6803bd5d:8b7e5748 name=00223FAA11D8:0
# echo DEVICE partitions > /etc/mdadm.conf # ls /etc/mdadm.conf /etc/mdadm.conf # mdadm -E -s >> /etc/mdadm.conf # cat /etc/mdadm.conf DEVICE partitions ARRAY /dev/md/3 level=raid5 metadata=1.2 num-devices=3 UUID=1c397b13:3dcbf756:97044c5e:f32f1fad name=00223FAA11D8:3 ARRAY /dev/md/2 level=raid5 metadata=1.2 num-devices=4 UUID=eee7d234:6e0d5103:2ec686b0:a10a2e74 name=00223FAA11D8:2 ARRAY /dev/md/1 level=raid6 metadata=1.2 num-devices=4 UUID=62bc3ab8:b3b480c7:3fe0c84b:ed4e0bcd name=00223FAA11D8:1 ARRAY /dev/md/0 level=raid1 metadata=1.2 num-devices=4 UUID=7fd03cc1:2db7e12d:6803bd5d:8b7e5748 name=00223FAA11D8:0 # mdadm --assemble --scan mdadm: /dev/md/3 has been started with 3 drives. mdadm: /dev/md/2 has been started with 4 drives. mdadm: /dev/md/1 has been started with 4 drives. mdadm: /dev/md/0 has been started with 4 drives.
# mdadm -Q --detail /dev/md0 /dev/md0: Version : 1.02 Creation Time : Sat Feb 20 15:11:12 2010 Raid Level : raid1 Array Size : 4194292 (4.00 GiB 4.29 GB) Used Dev Size : 4194292 (4.00 GiB 4.29 GB) Raid Devices : 4 Total Devices : 4 Preferred Minor : 0 Persistence : Superblock is persistent
Update Time : Mon Nov 12 05:52:59 2012 State : clean Active Devices : 4 Working Devices : 4 Failed Devices : 0 Spare Devices : 0
Name : 00223FAA11D8:0 UUID : 7fd03cc1:2db7e12d:6803bd5d:8b7e5748 Events : 1024
Number Major Minor RaidDevice State 0 8 1 0 active sync /dev/sda1 6 8 17 1 active sync /dev/sdb1 5 8 33 2 active sync /dev/sdc1 4 8 49 3 active sync /dev/sdd1
# mdadm -Q --detail /dev/md1 /dev/md1: Version : 1.02 Creation Time : Sun Aug 29 06:20:51 2010 Raid Level : raid6 Array Size : 1048448 (1024.05 MiB 1073.61 MB) Used Dev Size : 524224 (512.02 MiB 536.81 MB) Raid Devices : 4 Total Devices : 4 Preferred Minor : 1 Persistence : Superblock is persistent
Update Time : Mon Nov 12 05:49:29 2012 State : clean Active Devices : 4 Working Devices : 4 Failed Devices : 0 Spare Devices : 0
Chunk Size : 64K
Name : 00223FAA11D8:1 UUID : 62bc3ab8:b3b480c7:3fe0c84b:ed4e0bcd Events : 76
Number Major Minor RaidDevice State 0 8 2 0 active sync /dev/sda2 5 8 18 1 active sync /dev/sdb2 4 8 34 2 active sync /dev/sdc2 3 8 50 3 active sync /dev/sdd2
dm -Q --detail /dev/md2 /dev/md2: Version : 1.02 Creation Time : Sat Feb 20 15:11:12 2010 Raid Level : raid5 Array Size : 2916123888 (2781.03 GiB 2986.11 GB) Used Dev Size : 972041296 (927.01 GiB 995.37 GB) Raid Devices : 4 Total Devices : 4 Preferred Minor : 2 Persistence : Superblock is persistent
Update Time : Mon Nov 12 05:49:33 2012 State : clean Active Devices : 4 Working Devices : 4 Failed Devices : 0 Spare Devices : 0
Layout : left-symmetric Chunk Size : 16K
Name : 00223FAA11D8:2 UUID : eee7d234:6e0d5103:2ec686b0:a10a2e74 Events : 23129
Number Major Minor RaidDevice State 0 8 5 0 active sync /dev/sda5 6 8 21 1 active sync /dev/sdb5 5 8 37 2 active sync /dev/sdc5 4 8 53 3 active sync /dev/sdd5
# mdadm -Q --detail /dev/md3 /dev/md3: Version : 1.02 Creation Time : Tue Aug 31 01:45:22 2010 Raid Level : raid5 Array Size : 1953501568 (1863.00 GiB 2000.39 GB) Used Dev Size : 976750784 (931.50 GiB 1000.19 GB) Raid Devices : 3 Total Devices : 3 Preferred Minor : 3 Persistence : Superblock is persistent
Update Time : Mon Nov 12 05:49:25 2012 State : clean Active Devices : 3 Working Devices : 3 Failed Devices : 0 Spare Devices : 0
Layout : left-symmetric Chunk Size : 64K
Name : 00223FAA11D8:3 UUID : 1c397b13:3dcbf756:97044c5e:f32f1fad Events : 4096
Number Major Minor RaidDevice State 2 8 38 0 active sync /dev/sdc6 1 8 54 1 active sync /dev/sdd6 3 8 22 2 active sync /dev/sdb6
Re: NVX: paths for the shares listed below could[Case #19821
I still like to know why this occurred, I think the last reboot when I choice to fix quota and scan at same time on a revert to (RAIDiator-x86 4.2.21) from 4.2.22 (because of broken DLNA issue) cause this. I have the important stuff on NV+ and that box is fine and it can rsync back to NVX, but there were bunch of stuff that probably take a month to recover and timemachine backup on NVX is not backedup but atleast non of the machines that where doing backup to NVX timemachine has failed.
On ext4 corrupted disks, some folks do force mount (ignore fsck) method, but I have not figure out how to force mount it. the hardest route is to write a C code to clear the superblock flags. and mount -o ro and see what is there. there is also the trick to rewrite the superblock by initing it and let the new e2fsk run find inodes and jam them in lost+found
Mon Nov 5 19:06:30 PST 2012 Volume scan failed to run properly. Mon Nov 5 00:32:47 PST 2012 Powering off device Mon Nov 5 00:32:47 PST 2012 Please close this browser session and use RAIDar to reconnect to the device after it is powered back on. System powering off... Sun Nov 4 18:36:55 PST 2012 Fan will be recalibrated over the next few minutes. Sun Nov 4 18:29:56 PST 2012 ReadyDLNA media file rescan started. Sun Nov 4 18:21:42 PST 2012 System is up. Sun Nov 4 18:21:33 PST 2012 Your ReadyNAS device has been updated with a new firmware image. (RAIDiator-x86 4.2.21) Sun Nov 4 18:18:54 PST 2012 Rebooting device... Sun Nov 4 18:18:53 PST 2012 Please close this browser session and use RAIDar to reconnect to the device. System rebooting... Sat Nov 3 09:42:46 PDT 2012 Data volume has been successfully expanded to 4624 GB.
