September 17, 201312 yr After upgrading from v4.7 to v5.0 (thank you for the new stable release!), of eight disks, all work fine, except for the last one. My biggest share can't be accessed through Explorer, and neither can that particular drive. However, I can browse the contents of the drive (and share) from within the WebGUI, and partially through Explorer via other shares. All files appear to be there. Reiserfsck says it can't find the superblock and recommends --rebuild-sb. Per the instructions here I decided to ask before running it. Is it safe to do so? Thanks. syslog.txt
September 18, 201312 yr Author Nevermind; I'm an idiot. I was running the reiserfsck on /dev/sdX instead of /dev/sdX1. Running it correctly shows no errors. It looks like the problem was Windows-related. After restarting my XP machine I can see all disks and shares fine, though copying to the array is a bit slower. Thanks, anyway!
September 18, 201312 yr Nevermind; I'm an idiot. I was running the reiserfsck on /dev/sdX instead of /dev/sdX1. Running it correctly shows no errors. It looks like the problem was Windows-related. After restarting my XP machine I can see all disks and shares fine, though copying to the array is a bit slower. Thanks, anyway! Not sure if this applies to you, but note that if the drive was part of the array doing this will have invalidated any parity (without unRAID necessarily realising it)so if you are using a parity drive you will need to rebuild it ASAP to get your array protected. A better approach for array drives is to start the array in Maintenance mode and then running reiserfsck against the /dev/md?? device (where ?? corresponds to the disk number). This will leave the parity correct. It also has the advantage that it can be run against a failed/missing drive where unRAID is using the other drives to emulate the problem drive.
Archived
This topic is now archived and is closed to further replies.