I would have thought it possible. Manually following the instructions on this site leaves SoGo doing that. I had to change the ldap configuration settings from "MailFieldNames = (clearMailAliases,mail);" to "MailFieldNames = (mail);". Without the change it used the e-mail alias in the User setup.

Perhaps you'll find something similar in the Zarafa configuration (which I don't use)

A config backup is only a couple of MB. It should not overwrite your data at all. Was it a recent backup? Could it have got rid of storage mounts made after the backup or made manually? Do you have a more recent config backup you could restore over the top?

Just thought about doing some research on SATA cards before going to bed (it's currently 2.20 am
Came across this... https://www.jethrocarr.com/2013/11/24/adventures-in-io-hell/ - bit different to your problems but some of the comments at the bottom are telling...

Seems like the Marvell SATA chipsets/drivers might not be the best if this is anything to go by... Have a Silicon Image 3114 (and still use in a backup Server that's only powered up once a week for backup updates) so your PCI card is probably OK (provided the manufacturer was careful laying out the PC board traces to minimise cross-talk - mine is a different brand to yours) Just make sure the SATA cable is good quality with a nice tight fit. Mine has no notches for the clips... However, based on the URL above there are suspicions about PCIe Marvell based cards - perhaps change yours for a decent one - with no Marvell chipset!. Never used Marvell myself so no first hand experience there.

My SI 3114 card has 1 drive attached, the motherboard has 4 SATA ports with 4 drives. The 5 drives are combined in a software raid 5 array. The OS resides on 2x IDE drives that are mirrored in Raid 1. All my drives support TLER (ERC) set to 7 seconds timeout.

Hi Peter,
When flex-443.conf picks up the certificates, is there any reason for using the fullchain.pem file as the chain file and not chain.pem? The fullchain.pem is a combined cert.pem and chain.pem and you are already picking up cert.pem as the SSLCertificateFile.

Hi Leon, Once a UUID is assigned to each array during raid creation it doesn't matter what the /dev/sdx order is if you specify by UUID in mdadm.conf... madadm scans all drives looking for the UUIDs and uses that to ascertain which drive is which
Did you create the script to change the disk time-out and place it, for example, /etc/rc.d/rc.local so it runs when booting? Those drives of yours are not suitable for use in Raid 5/6 without doing that.

No idea how you are setting the drives up - never watch a "How-To" on YouTube or anything else similar - can read far faster than any narrator can speak and thus lean a lot more in the same period of time... and you can always refer to any written part instantly. Lot better than having to replay something to make sure you heard and understood a certain passage correctly... Initially several years ago downloaded and used the Redhat Administration Manuals and went from there... Studied the complete set, beginning to end, while going to//from work on the train.

If you continue to have problems - then it might be time to look at the hardware... would be inclined to ditch the two budget PCI/PCIe controllers and get a decent 8-port one with correct Linux support, eg a modern LSI, assuming one of your 8x or 16x PCIe slots is vacant... are you using good quality SATA cables with clips? The old original ones with no clips are notorious for creating intermittent connections as are cheap controllers that don't have the little notch for the clip to latch onto. Wouldn't be surprised if your two add-on controllers fall into that category. No clips means you are relying on friction - you might get away with it - but the number of drives you have provides more opportunity for vibrations and connector movement...

Hi Tony

Thank you for all the help, but i am at the point where, so my data is gone... deal with it...
I am prepared to start from scratch, about 4TB will be lost, i think i can get most of it back over time from other sources, it might just take some time.

I still have the issue where on every reboot, the raid - /var/sd[abcefgijkl] is not the same as the next.
This is what seems to be the issue - we got side tracked trying to recover the data after the reboot and i loaded data on the drive.

Any idea how i resolve my original issue?

Thank you so much Fredrik; you saved my day!

Your config file works flawlessly with cups in clearOS 7.3. You presented this fix a year and half ago and I'm wondering why it hasn't taken its place in the new versions of clearOS?!

Nit "systemctl status firewall.service" not "systemctl firewall.service status"
service and systemctl have their parameters in opposite orders - catches me out too

Create is dangerous in that you need to specify the disks, in the create command, in the same order that they had become in the raid when it broke. Since you did a grow they may not be in strict alphabetical order any more - do not write anything to the drive - mount it read-only until you have verified the data in large files is OK. Since you have 10 drives the number of possible combinations is enormous, See the Section "File system check" https://raid.wiki.kernel.org/index.php/Recovering_a_damaged_RAID - you really should have done this with overlays - I pointed to this procedure before. For all you know the correct order may be /dev/sdc /dev/sdf /dev/sdd.... etc. On the other hand you may have been very lucky...

Comment out the entry in fstab - (assume you put it back) and do not add it back until you are sure the array will always assemble on a boot. in the mean time do a manual mount if and when the array is assembled, then reboot. Can you stop /dev/md127 and /dev/md0 and will it now assemble with a --detail --scan ?

Hi Tony

I created a mdadm.conf file, this is the content

ARRAY /dev/md/0 metadata=1.2 name=Zodiac.lan:0 UUID=785c89de:1d355c46:9b116951:21d6c4b3