driller3000 Posted August 1, 2015 Share Posted August 1, 2015 Hi There, I replaced a failed disk (Disk 9) overnight and unRAID rebuilt the data successfully. I can see the unRAID server - stream content - I can copy files from it to my desktop (running vista) - and I can write to all of the "original" disks. But - I cannot write to my Shares (all share permissions are unchanged) - or to the the replaced Disk 9. And I cannot change permissions in windows for the replaced disk. It shows no access permissions - other than Special Permissions - but I cannot amend these - as it says "Access Denied to Disk 9." So - I have checked and reset the disk permissions for the replaced disk in unRAID - to Public (toggled back and forth) but I still cannot change access permissions in windows. I have amended disk shares from ALL - to actually listing the individual risks - Incl Disk 9 - and yay I briefly get wriote access to Disk 9 - but then I don't. I have stopped the array several times - I have rebooted and I have powered down twice - all to no avail. So: Is this an UnRAID problem or a Windows problem? (I think it's an UnRAID problem - due to the only change being the replaced Disk 9?) And most importantly do any of you (please) have any solutions??? Thanks in advance. Ed tower-diagnostics-20150802-1047.zip Link to comment
driller3000 Posted August 1, 2015 Author Share Posted August 1, 2015 Update - Discovered a corrupt file on Disk 9 - cant delete it - I presume it was created at the time of the disk failure - I understand this may corrupt the file structure and lead to "Read Only" status for the disk. So ran reiserfsck - found 1 corruption - says to do --rebuild-tree ugggh - down the rabbit hole i go.... Link to comment
driller3000 Posted August 2, 2015 Author Share Posted August 2, 2015 As best as I can tell based on the FAQ and prompts I have received in the reiserfsck - I need to run this string: reiserfsck --rebuild-tree /dev/md9 However - I did and seemingly nothing happened? Any advice? Any advice? Link to comment
driller3000 Posted August 3, 2015 Author Share Posted August 3, 2015 advice please re reisefcsk -- rebuild tree? When I type "Yes" - nothing happens??? Thanks in advance. Edit: Tried just via putty - and still nothing? Help! Link to comment
Squid Posted August 3, 2015 Share Posted August 3, 2015 What do you mean nothing happens? Can you try it again from putty and post a screen shot Link to comment
driller3000 Posted August 4, 2015 Author Share Posted August 4, 2015 Thanks for the reply - putty screenshot/text below as requested: login as: root Last login: Tue Aug 4 21:18:25 2015 from 192.168.1.17 Linux 4.0.4-unRAID. root@Tower:~# reiserfsck --check /dev/md9 reiserfsck 3.6.24 Will read-only check consistency of the filesystem on /dev/md9 Will put log info to 'stdout' Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes ########### reiserfsck --check started at Tue Aug 4 21:23:43 2015 ########### Replaying journal: Done. Reiserfs journal '/dev/md9' in blocks [18..8211]: 0 transactions replayed Checking internal tree.. / 12 (of 31)/ 48 (of 104)/122 (of 169)block 309852239 : The level of the node (60685) is not correct, (1) expected the problem in the internal node occured finished Comparing bitmaps..vpf-10640: The on-disk and the correct bitmaps differs. Bad nodes were found, Semantic pass skipped 1 found corruptions can be fixed only when running with --rebuild-tree ########### reiserfsck finished at Tue Aug 4 21:30:26 2015 ########### root@Tower:~# reiserfsck --rebuild-tree /dev/md9 reiserfsck 3.6.24 ************************************************************* ** Do not run the program with --rebuild-tree unless ** ** something is broken and MAKE A BACKUP before using it. ** ** If you have bad sectors on a drive it is usually a bad ** ** idea to continue using it. Then you probably should get ** ** a working hard drive, copy the file system from the bad ** ** drive to the good one -- dd_rescue is a good tool for ** ** that -- and only then run this program. ** ************************************************************* Will rebuild the filesystem (/dev/md9) tree Will put log info to 'stdout' Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes Replaying journal: Done. Reiserfs journal '/dev/md9' in blocks [18..8211]: 0 transactions replayed -------- And that's it ?? PS: I am a complete noob so it is entirely possible I am doing something daft .... Link to comment
itimpi Posted August 4, 2015 Share Posted August 4, 2015 That is really strange! Note that there can be a significant delay before you start getting further messages - but it should still be only of the order of minutes rather than hours. You might want to check if the disk is still online by issuing a command like gdisk /dev/sd? where the sd? corresponds to the device name shown in the unRAID GUI. If that starts up without an error it will show the disk is still there (you should immediately use the 'q' command to quit gdisk as you do not want to make any changes). Link to comment
driller3000 Posted August 4, 2015 Author Share Posted August 4, 2015 thanks for the reply have instead run rebuild tree with the - S switch and it has been running now for 7 hrs - so looks like progress!! : ) --------------------------- root@Tower:~# reiserfsck --rebuild-tree -S /dev/md9 reiserfsck 3.6.24 ************************************************************* ** Do not run the program with --rebuild-tree unless ** ** something is broken and MAKE A BACKUP before using it. ** ** If you have bad sectors on a drive it is usually a bad ** ** idea to continue using it. Then you probably should get ** ** a working hard drive, copy the file system from the bad ** ** drive to the good one -- dd_rescue is a good tool for ** ** that -- and only then run this program. ** ************************************************************* Will rebuild the filesystem (/dev/md9) tree Will put log info to 'stdout' Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes Replaying journal: Trans replayed: mountid 52, transid 28851, desc 2658, len 1, commit 2660, next trans offset 2643 Trans replayed: mountid 52, transid 28852, desc 2661, len 1, commit 2663, next trans offset 2646 Trans replayed: mountid 52, transid 28853, desc 2664, len 1, commit 2666, next trans offset 2649 Trans replayed: mountid 52, transid 28854, desc 2667, len 1, commit 2669, next trans offset 2652 Trans replayed: mountid 52, transid 28855, desc 2670, len 1, commit 2672, next trans offset 2655 Trans replayed: mountid 52, transid 28856, desc 2673, len 1, commit 2675, next trans offset 2658 Replaying journal: Done. Reiserfs journal '/dev/md9' in blocks [18..8211]: 6 transactions replayed ########### reiserfsck --rebuild-tree started at Wed Aug 5 00:19:15 2015 ########### Pass 0: ####### Pass 0 ####### The whole partition (976754633 blocks) is to be scanned Skipping 38019 blocks (super block, journal, bitmaps) 976716614 blocks will be read 0%....20%..block 278576853: The number of items (1) is incorrect, should be (0) - corrected block 278576853: The free space (0) is incorrect, should be (4072) - corrected ..40%.block 455547314: The number of items (61192) is incorrect, should be (1) - corrected block 455547314: The free space (54966) is incorrect, should be (4024) - corrected pass0: vpf-10110: block 455547314, item (0): Unknown item type found [2381811980 2150634423 0x549b7280 (12)] - deleted ...60%....80%. left 126428204, 37028 /sec ------------------------------------ Link to comment
itimpi Posted August 4, 2015 Share Posted August 4, 2015 It is good to see that it is running, but I cannot think why the -S option was needed. You will almost certainly end up with a lot of files/fragments in the lost+found folder as the -S option can find deleted files and partial files. If you want to manipulate these via the network then you will need to run the 'newperms' command against that folder to have permission to do so as the owner will have been set to root by reiserfsck. Link to comment
driller3000 Posted August 4, 2015 Author Share Posted August 4, 2015 yeah i have no clue either - and it's entirely possibly that "-S" was not required that said I am pretty sure that via the gui "rebild-tree" ran and stopped within seconds - so it effectively didn't run whereas with putty - it did seem to stop initially - but perhaps i didn't wait long enough? (memo to self - have more patience) truth be known i have tried so many things over the last few days - reboots/disk rebuilds/turn off parity to delete corrupted file/parity rebuilds/checks etc etc so much so that i can't be sure what made the difference - not great in terms of solution id and repeatability i know but at least i know it will run via putty - eventually thanks for the feedback - and i will run 'newperms' as suggested cheers ed Link to comment
driller3000 Posted August 4, 2015 Author Share Posted August 4, 2015 SOLVED 10 hrs later - "reiserfsck --rebuild-tree -S /dev/md9" - via putty, did the trick 1. Filesystem corruptions fixed. 2. Drive no longer corrupt - so permissions could be changed on my windows machine - to read/write etc. 3. Found corrupt file - tried to play it (mkv) - wouldn't play - deleted it. 3. Numerous files in "Lost and Found" as advised above - most junk - so deleted these. (Note: Turns out newperms wasn't required to do so.) My observations: 1. reiserfsck is a pretty handy tool. 2. However if the "reiserfsck --rebuild-tree" etc doesn't work via the gui - definitely give putty a go. 3. I do also wonder whether having the server in Maintenance Mode via the gui and then trying to run rebuild-tree from putty led to it failing to run? Dunno. Perhaps someone smarter than me can comment. Anyway ..... All in ALL one happy camper and thank you to those who replied. Link to comment
itimpi Posted August 4, 2015 Share Posted August 4, 2015 SOLVED 10 hrs later - "reiserfsck --rebuild-tree -S /dev/md9" - via putty, did the trick 1. Filesystem corruptions fixed. 2. Drive no longer corrupt - so permissions could be changed on my windows machine - to read/write etc. 3. Numerous files in "Lost and Found" as advised above - most junk - so deleted these. (Note: Turns out newperms wasn't required to do so.) Are you sure you did not delete these via the CLI (in which case you are root so can do anything). My observations: 1. reiserfsck is a pretty handy tool. That is one of the best things of Reiserfs - its ability to be recovered even when extreme levels of corruption exist. 2. However if the "reiserfsck --rebuild-tree" etc doesn't work via the gui - definitely give putty a go. Trying to run reiserfsck via the GUI is new - it has traditionally been run via a telnet/console session. 3. I do also wonder whether having the server in Maintenance Mode via the gui and then trying to run rebuild-tree from putty led to it failing to run? Dunno. Perhaps someone smarter than me can comment. That is the way it is normally run. I had not realised you were trying to do it any other way. Link to comment
driller3000 Posted August 4, 2015 Author Share Posted August 4, 2015 Q1: Are you sure you did not delete these via the CLI (in which case you are root so can do anything). Did it via windows machine / network share / disk 9 Q2: Re Maintenance Mode and Putty. Yeah I think the server wasn't in Maintenance Mode - when I finally got rebuild-tree to work via putty? Or maybe I have this back the front? Link to comment
Recommended Posts
Archived
This topic is now archived and is closed to further replies.