Desde la última actualización de cPanel/WHM si un usuario tiene la cuota excedida recibe el siguiente error al acceder a webmail:

Internal Server Error
>
> User 'xxxxxx' is over quota.
>
> ------------------------------------------------------------------------
> cpsrvd/11.25 Server at xxxxx

Pese a aumentar la cuota, el error sigue apareciendo, y es necesario eliminar el siguiente fichero:

rm /var/cpanel/overquota/usuario

Otra opción si no queréis borrar el fichero es reiniciar cPanel:

/etc/init.d/cpanel restart

¡Gracias tureceta!

Al parecer en algunas versiones del nuevo cPanel 11.25.0-RELEASE se están detectando errores en la instalación del módulo de perl Mail::SPF. Si ejecutamos /scripts/checkperlmodules encontramos los siguientes errores:

CPAN.pm: Going to build J/JM/JMEHNLE/mail-spf/Mail-SPF-v2.007.tar.gz

perl-64bit-hack: enabled
# running Build.PL --otherldflags -L/usr/lib64 --config ldflags=-L/usr/lib64 --extralibdir /usr/lib64
Creating new 'MYMETA.yml' with configuration results
Creating new 'Build' script for 'Mail-SPF' version 'v2.7.0'
Prereq 'v5.6' for 'perl' is not supported by Module::Build::Compat
make: *** No targets.  Stop.
 JMEHNLE/mail-spf/Mail-SPF-v2.007.tar.gz
 /usr/bin/make OTHERLDFLAGS=-L/usr/lib64 LDFLAGS=-L/usr/lib64 EXTRALIBDIR=/usr/lib64 OTHERLDFLAGS=-L/usr/lib64 LDFLAGS=-L/usr/lib64 EXTRALIBDIR=/usr/lib64 -- NOT OK
Running make install
 Make had returned bad status, install seems impossible
perlmod--Install done

Para efectuar la instalación de un modo correcto ejecutad el siguiente comando:

 perl -MCPAN -e "get('Mail::SPF')" && cd /home/.cpan/sources/authors/id/J/JM/JMEHNLE/mail-spf && tar -xzvf Mail-SPF-v2.007.tar.gz && cd Mail-SPF-v2.007 && perl Build.PL && ./Build && ./Build test && ./Build install && /scripts/checkperlmodules --full

Fuente | Foros cPanel

El error que nos hemos encontrado hoy al acceder a un webmail IMAP Squirrelmail ha sido el siguiente:

ERROR: solicitud errónea o con formato erróneo.
Consulta: SORT (SUBJECT) ISO-8859-1 ALL
El servidor respondió: UID invalid arguments

O también:

ERROR : Could not complete request.
Query: SORT (ARRIVAL) ISO-8859-1 ALL
Reason Given: ISO-8859-1 character set is not supported.

El problema se origina en una incompatibilidad en el servidor IMAP y  la opción de Squirrelmail “server-side sorting”. El error aparece al intentar ordenar los mensajes de la bandeja por Asunto, Fecha, Nombre, etc. Lo que hay que hacer es desactivar la opción “server-side sorting”, ya que genera errores de compatibilidad con ciertos charset.

Para arreglarlo podemos ejecutar el script de configuración conf.pl y acceder a:

4. General Options
12. Allow server-side sorting -> FALSE

También podemos editar directamente el fichero config.php y cambiar:

allow_server_sort = true

por

allow_server_sort = false

Una vez modificado esto debería funcionar todo correctamente, aseguraos de salir y entrar de nuevo en la sesión y eliminar cualquier referencia a “sort” en el fichero de preferencias de la cuenta de correo.

En caso de recibir el siguiente error al acceder all servicio de webmail Roundcube en un servidor con cPanel:

SERVICE CURRENTLY NOT AVAILABLE!
Error No. [0x01F4]

Debéis revisar en primera instancia si habéis desactivado en el servicio MySQL el motor de base de datos INNODB, si aparece lo siguiente en el fichero de configuración my.cnf es que lo habéis desactivado:

skip-innodb

En ese caso, la solución pasa por volver a activar INNODB, o forzar a Roundcube a usar MyISAM, para ello, simplemente forzad la reinstalación del webmail con el siguiente comando:

/usr/local/cpanel/bin/update-roundcube --force

Últimamente encuentro bastante a menudo este error en servidores bajo cPanel. Este error se recibe en la cuenta de correo configurada para recibir todas las alertas de backups, creación de cuentas, etc.

En la mayor parte de casos, el error era provocado por una asignación incorrecta a los permisos de la carpeta public_ftp, por algún motivo tenían permisos 000, siendo los adecuados 750. El error entonces se soluciona reasignando los permisos correctos:

chmod 0750 public_ftp/

Si recibís el error pese a tener bien los permisos de la carpeta public_ftp, revisad los de las demás carpetas de la cuenta con problemas. Desde una actualización reciente, los backups se ejecutan con el usuario de la cuenta en vez de como root, lo que provoca que si una de las carpetas no tiene los permisos suficientes, salte el error.

Es común encontrar este error al tratar de arrancar Snort en una instalación nueva, es debido a que en el fichero de arranque (/etc/init.d/snort) por defecto tiene configurado para esnifar en la interfaz eth0, si utilizamos otra interfaz de red para ello encontraremos el error.

Para solucionarlo, acceded al script de configuración y cambiar el parámetro que indico a continuación especificando la interfaz de red que esnifará:

vi /etc/init.d/snort

----------------------------------------------------------
# Specify your network interface here
INTERFACE=eth0
----------------------------------------------------------

Una vez cambiado reiniciamos snort:

/etc/init.d/snort restart

En caso de recibir este error al salir de la edición de un fichero con vim, has de revisar dos puntos. Por una parte que no haya ficheros temporales tipo ~/.viminf*, es decir, si tu usuario se llama test revisa que no haya estos ficheros en /home/test/.viminf*

Por otra parte revisa que tu usuario puede escribir en dicho fichero.

¿El error es bastante claro no? No obstante, puede llegar a ser difícil darse cuenta de que este es el fallo. Este error salta al ajecutar el parser que se configura en kayako a través de un cron para que “parsee” todas las cuentas de correo asociadas a los tickets y así ponga cada email en su departamento. Yendo al grano, si al ejecutar el cron sitio.com/cron/index.php?_t=parser por ejemplo de este modo:

GET "http://mikayako.com/cron/index.php?_t=parser" > /var/log/log_cron_kayako.txt

Nos encontramos con que devuelve el siguiente error:

ERROR: Your PHP is not compiled with IMAP Support.

Asegurate de compilar php habilitando soporte imap con la flag –with-imap o si lo has instalado por paquetería (yum, apt) simplemente instala el módulo:

yum install php-imap

Reinicia apache y ejecuta de nuevo el cron, ya deberían procesarse correctamente todas las colas de correo de apache. Recuerda ampliar el max execution time de PHP si usas muchos departamentos, volumen de correos, etc.

Si este cron no funciona, nos damos cuenta porque los correos llegan correctamente al MTA (PostFix, Exim, qMail) pero ahí termina todo, no pasan a la interfaz web de Kayako.