===== Solución a problemas en Zimbra =====
==== No envía correos ====
Si el servidor no envía correo y al mirar el fichero ** /opt/zimbra/log/zmmailboxd.out**  aparece un mensaje de error 2018-07-04 12:58:16.566:WARN:oejs.HttpChannel:qtp509886383-24433: Could not send response error 500: java.io.IOException: Connection reset by peer

=== Solución ===
Se supone que deberíamos aumentar la memoria heap pasamos de mailboxd_java_heap_size = 1920  a 4096
<sxh>zmlocalconfig -e mailboxd_java_heap_size=4096</sxh>

==== Error unexpected blob ====
<note>Cada elemento de zimbra se compone de dos partes: la "información", que es el contenido real, y el "metadato" formado por un conjunto de informaciones adicionales inherentes al propio elemento. Un BLOB es un archivo que contiene la "información" de un elemento, almacenado en el volumen de mensajes.</note>
Si al hacer un chequeo de los blob <sxh>/opt/zimbra/bin/zmblobchk start</sxh> nos aparecen mensajes del tipo <sxh>Mailbox 150, volume 1, /opt/zimbra/store/0/150/msg/0/361-1901.msg: unexpected blob.  File size is 13425.</sxh>

Muchos de los problemas se solucionaran ejecutando como root el siguiente comando para fijar problemas con los permisos de los ficheros. 
<sxh>/opt/zimbra/libexec/zmfixperms --verbose --extended</sxh> 

Si aún después de ejecutar zmfixperms, persisten los errores con los blob,podemos ejecutar :
<sxh>zmblobchk --missing-blob-delete-item --export-dir /temp/blob start </sxh> para exportar y eliminar los blob perdidos.

En el caso de que aún tengamos errores del tipo unexpected blob, podemos ejecutar el siguiente script para mover los mensaje con problemas a una carpeta para poder revisarlos. (https://forums.zimbra.org/viewtopic.php?t=13512)
<sxh>
#!/bin/bash

#Fichero con un listado de los buzones con problemas
blobfile="/opt/tmp/unexp-blobs.lst"

#path donde recreamos la estructura de los ficheros que vamos a mover
savedir="/opt/tmp/unexpected-blobs"

#path donde tenemos los buzones
storepath="/opt/zimbra/store/0/"

#Si no existe creamos el directorio donde vamos a recrear la estructura
if [ ! -d "$savedir" ]; then
    mkdir -p $savedir
    fi
    
    #Si ya existe un fichero de listado blobfile lo eliminamos 
       if [ -f $blobfile ]; then
        rm -f $blobfile
        fi
          zmblobchk --unexpected-blob-list $blobfile  start;
          for i in $(cat $blobfile); do
             tmpvar1="";mbxdir="";filename="";
              tmpvar1="$(dirname $i)"
              mbxdir=${tmpvar1#$storepath}

               #filename=$(basename $i)
                echo $savedir/$mbxdir/$filename
                
                #Creamos la estructura si no existe
                    if [ ! -d "$savedir/$mbxdir" ]; then
                        mkdir -p $savedir/$mbxdir
                             fi
                             
                             #Movemos los mensajes con problemas 
                              mv -v $i $savedir/$mbxdir/;
                             done</sxh>



Seguidamente revisamos la integridad de la base de datos
<sxh>/opt/zimbra/libexec/zmdbintegrityreport -v</sxh>

==== Servidor lento ====
  *   * https://blog.itlinux.cl/blog/2015/06/24/zimbra-how-to-debug-a-rogue-server/

==== Error mta no arranca ===
Por si es un problema de permisos ejecutar como root
<sxh>/opt/zimbra/libexec/zmfixperms</sxh>
Si queremos que además revise los directorios  /opt/zimbra/store y /opt/zimbra/index le tenemos que añadir la opción **-extended**
<sxh>/opt/zimbra/libexec/zmfixperms -extended</sxh>

<notewarning>ojo que dependiento de nuestra configuración puede llegar a tardar bastante</note>
También podemos hacer: <sxh>chown -R zimbra:zimbra /opt/zimbra</sxh>


Si el error se mantiene revisar si hay algún proceso que está usando el puerto 25
<sxh>netstat -tulpn </sxh>

Una vez que sabemos el PID del proceso lo matamos con <sxh>kill -p <PID></sxh> y ejecutamos <sxh>zmcontrol start </sxh>

==== Problemas con la Base de Datos ====
Si al ejecutar <sxh>/opt/zimbra/libexec/zmdbintegrityreport -v</sxh> vemos que tenemos problemas con los indices de algunos buzones la solución sería ejecutar zmdbintegrityreport con la opción de reparación <sxh>/opt/zimbra/libexec/zmdbintegrityreport -r</sxh>.

Si no se soluciona tendremos que realizar la solución a mano. Para ello tomamos nota de los buzones con problemas que nos indica el comando zmdbintegrityreport y realizamos los siguientes pasos desde la consola: 
  - Una vez validados pasamos al usuario zimbra<sxh>su - zimbra </sxh>
  - Nos conectamos con la BDD <sxh>mysql -u zimbra</sxh>
  - Accedemos al buzón con problemas . En mi caso <sxh>use mboxgroup47;</sxh>
  - Comprobamos la tabla mail_item<sxh>check table mail_item;</sxh>
  - Comprobamos los indexes <sxh>show indexes;</sxh>
  - Si es sólo un indice el que da error . Lo mejor es borrar el indice y volver a crearlo -> [[https://wiki.zimbra.com/wiki/How_to_recreate_corrupted_index_(mysql)]]
  - Si son varios como era mi caso ejecuto <sxh>optimize table mail_item;</sxh> 
  - El comando anterior borra los indices corruptos y el siguiente paso sería volver a reindexar el buzon para que los vuelva a crear <sxh>zmprov rim usuario@dominiocorreo start</sxh>

  * [[https://wiki.zimbra.com/wiki/How_to_recreate_corrupted_index_(mysql)]]
  * https://wiki.zimbra.com/wiki/Zmdbintegrityreport
  * https://aubreykloppers.wordpress.com/2019/02/18/zimbra-recover-broken-mariadb/
  * https://wiki.zimbra.com/wiki/Harley77-Mysqld
  * https://wiki.zimbra.com/wiki/Mysql_Crash_Recovery
  * [[https://wiki.zimbra.com/wiki/Mysql_Crash_Recovery_(alternate_method)]]
  * https://wiki.zimbra.com/wiki/Issues_with_database_integrity_check
  * https://blog.christosoft.de/2017/03/zimbra-corrupt-index-open_conversation-mysql/

===== Referencias ====
  * https://wiki.zextras.com/wiki/ZxPowerstore:_Checking_the_message_BLOBs_health/es
  * https://wiki.zimbra.com/wiki/Ajcody-Notes-No-Such-Blob
  * http://martinlugo.networksolutions-peru.com/arreglando-un-bd-en-zimbra-table-mboxgroup33-appointment-doesnt-exist/