madburg

OK, lets try this first, can you shutdown unRAID and remove the key and insert it into another device to access it? if so rename share.cfg to something else, copy the share.cfg from the unRAID source, put the stick back into your unRAID server and boot it back up. default share.cfg should contain only: (from the source) # Share options shareFlash=e shareDisk=e shareUser=- Once you boot back up, paste in your post what the share.cfg contains and check your /config/shares directory as well and report back.

Yeah not good. All files are fine except for share.cfg. Here is mine, as far as I recall they are structure fairly identical (for a lack of better words) # Generated settings: shareUser="e" shareUserInclude="" shareUserExclude="" shareSMBEnabled="yes" shareNFSEnabled="no" shareNFSFsid="100" shareAFPEnabled="yes" shareInitialOwner="Administrator" shareInitialGroup="Domain Users" shareCacheEnabled="yes" shareCacheFloor="2000000" shareMoverSchedule="40 3 * * *" shareMoverLogging="yes" At first I wanted to say, add a few lines and remove a few (but hold on, may have a better idea). Question, do you have NFS enabled (and are you using NFS)?

I know about swap/disable, I have never done it myself and personally question it and until I understand how that works (not just a click, do this, click do this) I am hesitant about it, but thats just me. I want to be sure (for me or anyone else reading who might not be sure as well) the steps the individual took exactly. So I am asking him/her not you, once again. Right now, from what we see is with a drive failed, a swap/disable was utilized (not on a health system but one with a fail drive) and a parity check generated tons of errors. So do we ask what steps he took exactly (to be sure) or do we blame swap disable immediately? People make statements and do things wrong (not stating he did anything wrong) or they misunderstand what is to be done, it happens, it human.

===>Thats what your saying<=== I am posting to the individual not you ==> HELLO <== Is this what retired old folk with PH. D's and MVP's with 50 years experience do, and lets not forget you just added 'MOD' to your old belt recently.

Download "HP USB Disk Storage Format Tool 2.18", too large to post here, using that tool to format your original licensed usb stick and restart the process of creating it as a unRAID stick. Good luck.

Nice, that should be in final

The goal is to take ANY usb stick large enough to copy unRAID source to, you will not be placing any (license) key file or altering it in any way, besides following the procedure on how to create an unRAID usb stick (which you know how to do) and see if your system boots it (place the stick in the same usb port your original license unRAID usb stick was in). Do NOT start the array, basically don't do anything and shut it down; based on if it even boots. A quick test to weed out if its your original usb stick is OK or not.

Thats the part i don't understand. Are you stating you removed the failed drive (disk3) AND the parity drive (basically) at the same time, added the (new never been used) 4TB drive as parity and moved your old parity drive and assigned it as Disk3?

+1 on the syslog, and can you post the steps you took to replace the failed drive and rebuild the data to its replacement drive.

Grab another USB stick, drop a copy of unRAID on it (basic) and see if it boots,dont anything, if it boots just shut it back down, you will at least know if it the stick or not.

Just when over your syslog, its a pretty old board. Somethings improved some did not with the bios update (your at the latest revision, thats all you can do with that). Still states: (really weird...) Jul 15 23:41:47 Tower kernel: 90MB HIGHMEM available. I didn't express to clearly about the user shares yesterday. You will not have an option (duh, brain fart on my part) to delete a share thats not empty (contains data). Your user share .cfg's don't exist and are not getting created for your existing user shares. When you created a new user share (to test) yesterday a .cfg for the new share was created, the procedure does not seem to be working for the existing user shares. Can you post your share.cfg file/passwd/shadow/go files from the config directory, when u get a moment. I want to see a few things before having you try something.

Ok, true, and understood. Its just I was thrown off as we all know unMenu has been run from 'go' for the longest and thus no way to truly have safe mode if the stock 'go' file is loaded. I guess thats why we all felt the same way "right a go-safe file, makes sense".

Ok, but the go-safe file is included in the RC16c source so What procedure runs the go-safe file?

Hang tight on working with data, you need to delete does shares somehow I think, dont qoute me on that just yet. Fixing the issue should have you squared away quickly after that. You may want to screenshot your share configurations for when you solve this and want to recreate them (something to do for now, as well as the bios setting verification).

Yeah, thats why I was not in a rush to tell you, as I am not sure how you got to this point where u are seeing shares in the WebGui but the files dont exist.... so didnt want to question "What do you mean you cant delete them". AS the option may not exist as I have not come across this nor recall anyone posting about it. You will need to PM Tom and send him a link to this thread or wait for someone who has been here a long time and ran into this with someone before and how it was handled. This is the root of your problem, but updating the bios was necessary for stability/support, etc.. if you ask me, for you. I will still check the new syslog, when I get back.

I'll speak for myself, I am good with jonathanm and graywolf high level explanation and example, and appreciated. I'm not looking to redo anything for unRAID parity (or any complaints about it) nor was anyone faking a drive, it was a good example should someone make an attempt, what the end state would be. Thanks again. And thanks to the OP for bearing with this side tracking.

Yeah that didnt look to fun, from the brief look i took, you should go over the bios settings, in case any where changed and/or new ones added, when you get a chance. No it should be reflected there, I will look in your updated syslog after the bios update. Thats great, Im sure they fixed one or more things with ACPI with your board in one of the revisions of the bios. I always start here. That is not good, you should have a .cfg for each share there. Do this, create a new share right now and then check that directory and see if a .cfg is created or not Thanks, I stepped out at the moment and will review it as soon as I get back.

Sorry, hope I got this right, you had a failed disk and REMOVED your parity drive and assigned it in place for the failed data drive? (hang on to your failed drive, and don't do anything to it)

Wasn't totally sure I got it, until you posted this.

Thank you for updating the post (hence very clear now why why JoeL. states he doesn't wish to publish how to apply just the signature, "it's to dangerous" ) Thanks guys!

Which is the drive that is fake? in "Drives (faked precleared drive added)"

All array member drives are fully used to simulate the failed drive. That is why it's so crucial for a new drive to be all zeros, or for parity to be recalced using the existing values. Quick parity tutorial. So quick it's missing crucial technical detail, but here goes. Say you have 3 drives, so 2 data and 1 parity. At location address 1 on all the drives, the 2 data drives have 0, so the parity is set to 1, to make the total = 1. Location 2, 1st data is 0 second is 1, so parity is set to 0 so the total = 1. Location 3, D1=1, D2=1, so parity is set to 1 for a total of 1. Using the other two drives, any location can be calculated. Adding a 4th drive, you either need to do all the math again, or you can make sure all the locations are 0, so parity is still the same as it was before you added the drive. Once again, if you remove one of the other drives, you can use the other drives to calculate the value that should be there. If a location that is assumed to be 0 is actually 1, then the simulated data is going to be wrong at that location. SO its because this fake drives location address 1 = 1 instead of 0 (because it was not cleared) some how messes things up for data that is on another drive? (Don't mean to drive anyone crazy, appreciate all the postings)

Understood Something is missing here, 1) Let go with the drive was cleared and not used, all 0's right, how do all these zero help simulate a failed drive. 2) Let go with the drive was faked thus has 0/1, how are the 0/1's to this particular drive helpfully to simulate a failed drive?

That sound pretty cool.

I understand your scenario, thats cool we could go with that as well, we'll call it scenario#2. I don't get why it would use anything (0/1) from this new drive to "simulate" the other failed drive? I will explain my thoughts, garycase stated no computations are done (not disputing I don't know), and nothing has been written to the new faked added drive, so how more like why would this faked drive be utilized to help simulate any drive that was to fail?