If these two disks are a part of the raid don't forget to set them as failed and remove them before you wipe.
mdadm --manage /dev/md0 --fail /dev/sdi
mdadm --manage /dev/md0 --remove /dev/sdi
and so on...otherwise the whole raid can break.
Afterwards try to re-add them again.
Hmm....looks like we have breaked the champagne too early...
Is the raid visible in the web-ui? What is the result of blkid? Any reasons in the logs why mdadm has stopped the rebuild?
Hey good news, mdadm seems to have enough informations to start the rebuild. But I see a faulty spare, was there one before?
I would let it rebuild without further action, then make a backup of all your data and start from scratch with a fresh installation of the whole box. And check all the hardware for other problems, such a thunderstorm can do a lot of not so funny things. That's why I have a UPS for all my boxes.
Even if the raid is rebuilding you should see your shared folders from a windows box. Do you?
@Wabun :
sorry - same as before ;-/
i will reinstall OMV agaian an check if there is any difference ...
That may lead to the same situation. Now we have to check why these two disks cannot be added to the raid.
Give the result of blkid. After all these actions to get the raid back they possibly belong to another raid definition (Like disk 8 to md126...). blkid will tell if this is the case.
Until these two disks are not a part of the raid you can restart the box as long as you want, that won't bring it back.
These two disks have "lost the race" while the raid was assembled, udev can avoid the completion. I would start over building the raid from scratch.
At first check if these two disks responds:
smartctl -a /dev/sdi and smartctl -a /dev/sdj
to make sure that they are well-connected.
Then start over:
mdadm --stop /dev/md127 (This raid definition should now be removed from mdadm.conf)
udevadm control --stop-exec-queue
mdadm --assemble /dev/md127 /dev/sd[bcdefghijklm] --verbose --force
(If these two disks are still missing try to add them manually as stated above.
mdadm --manage /dev/md127 --add /dev/sdi
mdadm --manage /dev/md127 --add /dev/sdj)
If the raid is complete start udev:
udevadm control --start-exec-queue
Now check if the raid was build correctly:
cat /proc/mdstat
mdadm --detail --scan
If mdadm starts to rebuild, run initramfs and look for errors. If the raid was named correctly in mdadm.conf then it shouldn't spit out any error.
Just fought the same battle last weekend when I moved a raid from an old machine to a new installation, udevadm did the trick.
No need to start initramfs before the raid is complete. When mdadm sees all the disks and the raid is complete, it automatically starts a rebuild. The initramfs command adds it to the boot image.
@ahab: Stop that raid 126 with mdadm --stop /dev/md126, that kills the raid126 and frees the disk 8. Then add it manually to the raid 127 with mdadm --manage /dev/md127 --add /dev/sdi (Correct /dev/sd<letter> is important!).
Then do the same with disk No. 7: mdadm --manage /dev/md127 --add /dev/sdj - when I read your posts right this shoud be sdj.
If mdadm can read the disk correctly and it is ok then mdadm will start rebuilding, have a look at the web-ui.
Then you can run the initramfs command as wabun suggested. If initramfs finds an error it will tell that.
I always prefer testing programs made by the manufacturer of the disks at the first line, they are tailored for their products.
After reading all the postings I believe that only one disk may have problems.
./edit: This thread should be moved to the /Storage/Raid subforum.
Take care that nothing fiddles around with the superblocks while testing. As long as they are untouched the raid informations (And your data) written on the disks by mdadm when the raid was build can be discovered.
...... My wife begs me to stop tinkering and ask me to buy new stuff. ....
What a lucky man.... 
A NAS without a NIC is useless, that's right. But I believe the TO has a NAS running on this laptop and due to a defective NIC he is not able to access it anymore. Is that right, littleliner?
If so, there's not that much you can do. You can't open the web-gui from the NAS itself. You need another network adapter to connect it to your network. At Amazon they offer USB to LAN adaptors but I just don't know if they work with OMV.
If there's no other way to connect it to a network via an USB or PCMCIA adaptor you can only rip off the disk and copy your data to another installation.
Yes you can use different brands as long as they have the same size. I wouldn't mix up drives with very different capabilities, i.e. standard SATA drives with 7200rpm and drives with higher (Or lower) speeds.
In a corporate environment I always use the same brand and type of drives with the same firmware for better performance and stability.
That's right, but with only two drives your possibilities are very limited. Raid 0 or JBOD and Raid 1 are possible, for Raid 10 you need a minimum of four drives. Raid 10 is something I use in corporate environments for the sake of resilience, but not at home because the useable space is only half of the overall capacity of the drives.
I would take my hands on another 2 TB drive and build a Raid 5 which is expansible up to the end of your money. If that's not possible then do it like KM suggested but in that case you have to move your data away if Raid comes into game.
Well, thank you! My long time use of microsoft products has alienated me.
But now you are on the right way, son. May the force be with you. 
(Sorry, couldn't resist)
It _might_ be possible that you run into driver issues if the hardware is brandnew or somehow very special. I would choose a hardware which is supported by Debian Wheezy and you should be on the safe side.
The mentioned ISO is the right one to start with (If your system is x64-capable). The current version is 1.9, that's right - but the developers do not frequently update the basic ISO and you can easily update to the current version via the web-gui clicking on update manager after the system is up and running.
The guest on which you installed the guest additions, it should be rebooted after installation to load the drivers. Do you need a command to do that?
But i need to restart the server to make it work.
Yes of course, sorry I forgot to mention.
At the directory /usr/share/openmediavault/mkconf/proftpd
....
Am i doing something wrong ?
Yes. This path is wrong, you are one step too deep. /usr/share/openmediavault/mkconf is the right path and there you will find the proftpd config file for omv-mkconf proftpd.
The anonymous block starts at line 169 and according to subzero's suggestion you should change the standard value Denyall at line 181 to AllowAll. After saving the file run omv-mkconf proftpd from the CLI and try again.
If that doesn't work I can submit a version of how I managed it to allow uploads for anonymous users.
Raids created by mdadm will be recognized. You should see the raid in the raid management tab in the web-gui and the file system, but no shared folders.
You have to create them in the web-gui using the same names like they had before, set permissions and link them in the smb/cifs tab. The content should be there like on the former machine. I've done that before several times and it worked every time.
Na prima. Wenn das mit Kodi und Port 8080 auch funktioniert, dann würde ich einen anderen Port für die Kommunikation auswählen, irgendeinen unbelegten in höheren Bereichen ab 40000. Port 8080 gehört zum Standardrepertoire eines Portscans und ist bereits belegt. Jeder Scan von außen auf diesen Port würde die Kiste aufwecken.
Falls Du das nicht kennst, hier gibts eine ganz gute Übersicht über die Belegung der TCP Ports:
http://de.wikipedia.org/wiki/L…er_standardisierten_Ports
If I understand that correctly your problem only exists when the SAT box is connected via NFS?
