In the linked thread Cyprus125 reached speeds of 16813K/sec which is about 10 times faster than mine
Yes but he's using Enterprise drives, big difference, have you looked at the site he links too
Do you have any ideas what could be the problem
Adding 4 drives at once to an existing array, however I did find this in my watched threads which at the time I found interesting, look on page 2 around post 26, for that OP that could have gone either way
Yes there was a recent thread about using that particular image, as the RPi imager can be installed on Linux you could try that and see if there is an option/way to select that downloaded image, or install Balena Etcher and use that to write the image, but to do that you may have to create an ssh file
You should be able to use the RPi imager on Linux, this downloads and deploys the RPi OS onto the SD card you just have to ensure you select the correct RPi OS (Raspberry Pi OS Lite)
I plugged the second hard drive into the USB2 port and the same issue still happened,
could be a faulty Pi, but afaik they use a different bus, we need the input from Soma
and what now? do I have to start over
I would say so and read through the official Pi installation you could install the 64bit RPi OS rather than the 32bit
As soon as I connect the second disk to the second USB3 port on the Pi both drives start making a clicking / beeping sound in a tick-tock way
That alone points to lack of power for both drives accessing the same USB Bus, I bet if one was plugged into a USB2 port they would be OK.
I thinks it is totally broken
Judging by the output you have posted on pastebin I would agree
if i loose data it's a disaster
That's what a backup's for
remove all disks from OMV (write the disks order)
- remove all disks from LaCie (write the disks order)
- mount the LaCie disks on my OMV and create a new raid 5 with the disks in same order
Yes and no, if the raid was created on the LaCie you have no idea if OMV will actually see the array signatures on those drives and recreate it in the GUI, if it does then it should only be necessary to mount the array, not create one
This scenario could cause more issues than what it's worth especially if you intend to use your current OMV boot drive.
Your first two steps are OK, but I would strongly suggest to use/deploy a fresh/clean install of OMV on perhaps a usb flash drive, update, set time etc as if this was a new setup. Then shut down install the LaCie drives and see if OMV detects the LaCie array during the boot process, which hopefully it should.
Maybe geaves can help you
Nope, I've read this twice and if I'm reading this correctly there are 3x3TB in a existing Raid5, to grow the array 1x3TB and 3x4TB have been added, nothing like putting an existing array under stress and to cap it off there probably isn't a backup.
But to answer the OP's question take a look at this thread so in a nutshell can this be speeded up -> No!!
but it seems all of a sudden, everyone reads everything
Are you suggesting we now have literate users with carpal tunnel syndrome 
Question: how does it work
I'm sorry I am at a total loss as to what is happening or why, whilst that array appears to be intact if the array is mounted then the share on the array should still be there
He only recognizes it as Raid0 not as Raid 5
That's because it's inactive and you have the same issue with that mdadm --detail as your first post
I have just run up an OMV6 VM created a raid5 from three virtual disks and ran the cat /sys/block that I requested you run, this is the output;
the above is what I would expect as the system is doing nothing and the command works!! this would also show output if this was OMV5
Yours returned -> file or directory not found, to confirm the raid reference has not changed you would have check cat /proc/mdstat, if it's still md127 then there could be some corruption. I am assuming at this point your array was created using the GUI
If you installed OMV6 on a spare drive or usb flash drive (OMV5 and Debian 10 is EOL) once the system is up and running updates installed, date and time set etc, shut down connect your drives and during the reboot process OMV should detect the raid signatures and present the array to OMV.
Another option might be to try systsemrescuecd in omc extras, this installs the software and should allow for the array to be assembled from the cli, exit out and reboot should bring the array back to omv. This is just a possibility, your error is quite unique, one that I have never seen nor experienced before.
what if i put the disks in a fresh system
could i do a rebuild then
If you redeployed then you would do it without data drives connected, once the system was up running and working then connect the drives
Right 3 of the drives are registering as spares so the array is never going to rebuild, I was sceptical about the /sys/block command as this is an Ubuntu option but work a shot.
One more output
cat /etc/mdadm/mdadm.conf
OK;
mdadm --examine /dev/sdc
mdadm --examine /dev/sdd
This one I'm not sure about but;
cat /sys/block/md127/md/sync_action
Not sure if I can help never seen anything like this before, either there is something corrupted or there is a hardware issue, as both point to the output of mdadm --detail.
That output is missing information in relation to the array, if you look at the output from this problem;
Version : 1.2
Creation Time : Sat Nov 11 17:45:46 2017
Raid Level : raid1
Array Size : 1953383512 (1862.89 GiB 2000.26 GB)
Used Dev Size : 1953383512 (1862.89 GiB 2000.26 GB)
Raid Devices : 2
Total Devices : 1
Persistence : Superblock is persistent
Intent Bitmap : Internal
Update Time : Tue Jul 30 20:16:52 2019
State : clean, degraded
Active Devices : 1
Working Devices : 1
Failed Devices : 0
Spare Devices : 0
Name : Zangs-NAS:Zangs
UUID : 3ca82093:31bdaba6:e3fc2da7:8924c663
Events : 14734
Number Major Minor RaidDevice State
- 0 0 0 removed
1 8 16 1 active sync /dev/sdbyou can compare it to yours.
Post the output of the following;
blkid
mdadm --examine /dev/sdb
mdadm --examine /dev/sda
The issue here is, no one knows anything about your "SMART TV"
Surely the issue here is that our crystal balls haven't been updated 
I am not really concerned about DLNA as I prefer to use network share access - it works better
How
In this case software has not moved forward, it has moved backwards
Solely based on the fact that your TV cannot locate the shares on the network
There is a fundamental change between OMV5 and OMV6 which has blocked my previous happy system
You are basing that on what, you are failing to understand just because your 'happy system' in V5 doesn't function the same in V6 it's down to OMV when in fact your problem is Samba (SMS/CIFS) something that omv has no control over.
If nobody can offer a solution or at least some ideas to try I will revert to OMV5 with which I had no problems
V5 is EOL as is Debian 10 which it is based upon.
________________________________________________________________________
Suggestion, not a solution, have a look in the SMB/CIFS section on here, there is possibly an option that can be added to extra options in OMV's SMB settings, as the probability is that your TV cannot communicate with the current Samba version being used on OMV.
Can someone give me a hint how to do it
Long time since I've done this -> Gateway, port forwarding will just make the port accessible
1. Raid md127 remove sdd-old,
How, I am using OMV6 but I'm not using Raid and could spin up a VM but that would have to wait until tomorrow, but from memory in V5 there was an option on the Raid menu to delete/remove, that's the way a drive has to be, must be removed from an array. When done that way the array is in a clean/degraded state, so the shares and files are accessible.
a1b1c1d1 instead of abcd
no a1b1 etc are drive partitions, OMV does not use partitions when creating an array it uses the full drive.
-------------------------------------------------------------------------------------------------------------------------------------------
This output -> mdadm: Cannot get exclusive access to /dev/md127:Perhaps a running process, mounted filesystem or active volume group
suggests that something/someone still has access to the array that's why it cannot be stopped.
If you have the kernel plugin installed you could try using the SystemRescue option, this installs systemrescuecd and boots to that once, you can then run cli commands to assemble the array without omv running, exit and reboot will get back to omv. But, you need to check again options such as blkid.
