Archive:Http://userbase.kde.org/Akonadi 4.4/Troubleshooting/gl
Introdución
Esta páxina trata de como solucionar os posibles problemas con Akonadi, xa que nas primeiras fases da migración é normal que aparezan algúns. Moita xente reparará en Akonadi por vez primeira na versión 4.4 da compilación de software de KDE, e sentirase algo confusa. No glosario hai unha entrada na que se explica un pouco por riba para que serve Akonadi. Tamén contén ligazóns de interese de cara a ampliar os seus coñecementos sobre o tema. Unha vez se lles poña fin aos inconvenientes inevitables, Akonadi será un potente recurso do que se aproveitarán moitos aplicativos.
Comprensión da estrutura
Por suposto, pode limitarse a usar Kontact para xestionar todos os seus cadernos de enderezos, pero se por exemplo ten un sistema de copias de seguridade, interesaralle saber onde están almacenados os datos, e como se manexan. En tal caso, a páxina sobre Akonadi e os cadernos de enderezos resultaralle de utilidade.
Consellos para a solución de problemas
- Ao informar de problemas co servidor Akonadi inclúa sempre un informe de auto-análise comprensible. Dito informe pode obterse mediante o diálogo de auto-análise, que aparece cada vez que o servidor Akonadi non consigue iniciarse correctamente. Pode atopar dito diálogo no módulo kcmmodule, ao que se accede mediante:
kcmshell4 kcm_akonadi
- Iniciar o servidor Akonadi manualmente dende a liña de ordes pode dar lugar a información adicional de gran utilidade. Para facelo, execute a seguinte orde nunha consola:
akonadictl start
Dun xeito similar, a seguinte orde permite deter de novo o servidor Akonadi:
akonadictl stop
A seguinte orde fornece información de maior utilidade:
akonadictl status
Problemas habituais
Kontact non se inicia nin dá sinais de vida
Se Kontact non se inicia, e non aparece ningunha mensaxe de erro, asegúrese de que Akonadi está executándose. Akonadi debería iniciarse en canto algún aplicativo precise del. Se o seu non fai tal, terá que inicialo antes que Kontact en caso de que migrase xa algún recurso (probablemente KAddressBook). Utilice a icona de Akonadi na bandexa do sistema (que aparece tras executar “akonadi” en KRunner) ou execute as ordes en Konsole para inicialo.
Kontact non se inicia (versión 2)
Polo que se sabe, algunhas actualizacións poden afectar negativamente a Kontact. En tal caso, probe a inicial KMail, KOrganizer ou calquera outro dos seus aplicativos dende KRunner (ou Konsole). É probable que funcionen cada unha de xeito individual mentres descubre cal é o seu problema. Isto afecta principalmente á versión 4.4.0.
Non se atopou o cartafol: "/Local"
Algunhas persoas informaron deste erro, que aparecía en situacións en que Kontact non daba iniciado. Nalgunhas das primeiras versións da póla 4.4 seica había un erro na migración que facía que KMail buscase o correo electrónico local en ~/.local/share/Local, un directorio que non fora configurado. A solución non consiste en intentar corrixilo senón, co KMail e o Kontact pechados, abrir a consola de Akonadi:
- mediante KRunner, Alt+F2, ou
- executando "akonadiconsole" nunha consola.
Logo borre o recurso que di que é para o correo electrónico local. Agora debería poder iniciar Kontact ou KMail, e creouse un novo recurso que apunta a ~/.local/share/local-mail
Si. Se o seu caderno de enderezos se migrou correctamente, entón crearíase un novo recurso coma ~/.local/share/contacts/
Que son /usr/bin/akonadi_maildir_resource e /usr/bin/akonadi_maildispatcher_agent?
O recurso akonadi_maildir_resource créao automaticamente o axente akonadi_maildispatcher_agent, mentres que este último iníciase sempre xunta o servidor de Akonadi, xa que fornece funcionalidades básicas (coma enviar correos electrónicos) que utilizan todos os aplicativos de correo electrónico (actuais e futuros) baseados en Akonadi. Así que é normal que estean executándose, como usuario pode limitarse a ignoralos. Este recurso akonadi_maildir_resource, xerado de maneira automática, sempre vai apuntar a ~/.local/share/local-mail/, que é a súa conta de "Cartafoles locais" onde se almacenarán os seus cartafoles e correos electrónicos locais.
Nestes momentos, na versión 4.5 da compilación de software de KDE, o correo electrónico aínda non se migrou.
Desactiváronse os axentes da indexación de Nepomuk
Aínda que Kontact funciona, a seguinte mensaxe non deixa de aparecer:
A causa máis habitual é que Nepomuk estea desactivado na Configuración do sistema. Intente activalo na Configuración do sistema en activando o "escritorio semántico Nepomuk" e premendo en "Aplicar".
Se o problema non se soluciona (ou se a opción xa estaba activada cando se recibiu o erro) e se estivo utilizando versións de proba previas ao lanzamento final da versión 4.4 da compilación de software de KDE, pode que lle afectase un cambio na estrutura da base de datos (por mor dunha actualización do servidor de bases de datos Virtuoso da versión 5 á 6; os lanzamentos estables da versión 4.4 da compilación de software de KDE deben incluír a versión 6 de Virtuoso). As seguintes ordes deberían volver facelo funcionar:
qdbus org.kde.NepomukServer /nepomukserver org.kde.NepomukServer.quit rm -r ~/.kde/share/apps/nepomuk rm -r ~/.kde4/share/apps/nepomuk nepomukserver
Teña en conta que estas ordes non resultarán na activación permanente de Nepomuk, salvo que este xa estea activado de maneira permanente. Pode activalo mediante o aplicativo de Configuración do sistema.
Para ter un Kontact funcional fai falla un Akonadi funcional, e para este fai falla un Nepomuk funcional. Porén, pode desactivar o indexador de ficheiros Strigi, pois Kontact non o necesita. O indexador de ficheiros Strigi só se utiliza para as procuras no escritorio, o cal non ten nada que ver co Kontact. Simplemente asegúrese de que Nepomuk en si está a funcionar correctamente para Kontact.
En Kontact, Nepomuk utilízase para moitas cousas distintas, dende amosar os vindeiros aniversarios, pasando por xestionar as listas de libres e ocupados, ata amosar a fotografía dun contacto no visor de mensaxes. Se Nepomuk non está funcionando, moitas cousas de Kontact deixarán de funcionar. A mensaxe está para avisarlle da redución da súa funcionalidade. Activar Nepomuk tal e como se describiu previamente soluciona o problema.
Pode comprobar se Nepomuk está funcionando correctamente mediante a seguinte orde:
akonadictl status
Quero usar o meu caderno de enderezos actual e KOrganizer. Podo?
Pode. Ao utilizares a consola de Akonadi para engadir un recurso permítelle escoller como caderno de enderezos estándar. Apunte iso ao seu std.vcf e todo debería funcionar correctamente. A migración non destrúe o seu antigo caderno de enderezos. Pode seguir utilizándoo, se ben perderá todos os beneficios que Akonadi pode ofrecerlle. Tamén pode utilizar ambos os dous cadernos de enderezos, o de Akonadi e mailo orixinal, se así se sente máis seguro.
Non podo ver detalle ningún no meu caderno de enderezos
A día de hoxe descoñécese a causa deste problema, pero a solución é doada. Peche Kontact e inicie KAddressBook por separado. Despois de pechalo poderá volver usalo dende Kontact. Parece que se trata dalgún disparador que non se executa al iniciar o Kontact, e espérase solucionalo en pouco tempo. Seica isto afecta principalmente á versión 4.4.0.
Os meus contactos non aparecer ao utilizar o botón de escoller en KMail
Vaia a . Asegúrese de que os seus cadernos de enderezos xestionados por Akonadi estean listados, e engádaos se é preciso. Tamén é unha boa idea aproveitar para configurar o caderno de enderezos principal de Akonadi o predeterminado. Atopará máis información ao respecto aquí.
Como recupero o meu caderno de enderezos de software colaborativo?
Existen dúas solucións: mediante a infraestrutura vella ou mediante a nova.
Mediante a infraestrutura vella: en akonadiconsole, engada un "caderno de enderezos de KDE (tradicional)". O caderno de enderezos de KDE significa que podes configurar o antigo kresources para Akonadi. Na configuración do "caderno de enderezos de KDE (tradicional)", apúntalo a un recurso KResource "IMAP sobre KMail" e en KMail, as opcións de software colaborativo deberían estar activadas. Isto debería funcionar con Kolab, eGroupware, e cadernos de enderezos similares. Deberá marcar as opcións para asegurarse de que escolle o tipo correcto.
Mediante a nova infraestrutura (só se probou con Kolab): no módulo de configuración de Akonadi engada un recurso "servidor de correo electrónico IMAP", e estableza o nome do seu servidor de correo, nome de usuario e contrasinal, e a continuación prema en detectar automaticamente. Para velo execute a seguinte orde:
kcmshell4 kcm_akonadi
Logo engade un recurso Kolab. A continuación agarde a que o recurso IMAP se sincronice, que pode levar algún tempo. O seu estado aparecerá no módulo de configuración de Akonadi. Se non pasa nada, probe a reiniciar akonadiserver. Despois dun tempo os cadernos de enderezos Kolab deberían aparecer en KAddressbook.
Os correos electrónicos tardan moito en enviarse
Isto adoita darse cando ademais KMail queda conxelado ata que se envía o correo.
Descubriuse un erro na maneira en que Nepomuk comproba os enderezos, o que pode atrasar moito as cousas. O erro reparouse na versión 4.4.1 da compilación de software de KDE. Para os que sigan nunha versión anterior, existe un remedio:
Peche Kontact, ou KMail e KAddressbook se os está a executar por separado. Desactive Strigi na configuración do sistema. Deteña Nepomuk, borre a base de datos e reinicie nepomukserver. Para iso necesitará executar como usuario as seguintes ordes:
qdbus org.kde.NepomukServer /nepomukserver org.kde.NepomukServer.quit rm -r ~/.kde/share/apps/nepomuk rm -r ~/.kde4/share/apps/nepomuk nepomukserver
Isto borrará completamente a súa base de datos, incluíndo calquera etiqueta que engadise. En teoría é posible realizar un borrado máis selectivo da base de datos. Se lle resulta moi importante conservar algúns dos datos, siga as instrucións descritas this page nesta páxina (en inglés).
O recurso IMAP sempre está desconectado
Aínda que o sistema está conectado á Internet, o recurso IMAP non se dá conectado.
Aínda que o sistema está conectado á internet, o recurso de IMAP continúa en estado de desconexión.
Este erro débese a unha mala configuración da instalación de NetworkManager no seu sistema. Comprobe a saída de
qdbus --system org.freedesktop.NetworkManager /org/freedesktop/NetworkManager org.freedesktop.NetworkManager.state
Se é “4” (desconectado) pero pode acceder á Internet, o seu NetworkManager está mal configurado. Se é “3” (conectado) o problema debe ser outro. En Debian isto pode deberse ás interfaces definidas en «/etc/network/interfaces», que non están controladas por NetworkManager. Para arranxalo borre as entradas de «/etc/network/interfaces» e deixe que as xestione NetworkManager.
qdbus --system org.freedesktop.NetworkManager /org/freedesktop/NetworkManager org.freedesktop.NetworkManager.state
You can get any of the following values:
- 20 (formerly 4), disconnected. If you have access to the internet, your NetworkManager configuration must be wrong.
- 70 (formerly 3), connected. The problem must be somewhere else.
- It might be that one or more network interfaces are not controlled by NetworkManager. If that is your case, give the control of those interfaces to NetworkManager. It might be as simple as removing the entries for the interfaces from a text file (for example, /etc/network/interfaces). Check the help resources provided by your software distribution for more information.
Can't read any details of some messages or big delays to read it
if you aren't able to read some emails and see a message with " please wait ... ", you may logout and login KDE session to reinitialize all processes, might help.
Algunhas cuestións técnicas
Nepomuk
Dende a versión 4.4 da compilación de software de KDE, Akonadi precisa de Nepomuk para funcionar correctamente. Akonadi comprobará se está a funcionar, e en caso contrario amosará un diálogo de erro ao iniciarse.
Nepomuk só funciona coa infraestrutura Virtuoso. Pode comprobar se Nepomuk se está a executar coa infraestrutura correcta mediante o diálogo de auto-análise de Akonadi, tal e como se describe a continuación.
Aínda que Nepomuk ten que estar funcionando, pode desactivar a indexación de ficheiros Strigi, que adoita ser a parte da infraestrutura Nepomuk que máis recursos consume.
Apparmor
Algunhas distribucións que utilizan AppArmor téñeno configurado de xeito que impide que Akonadi execute o seu servidor de bases de datos interno. Isto pode dar lugar a unha serie de mensaxes de erro pouco claros, incluído entre outros o seguinte:
unknown error 255 when running akonadictl "DB error: 'Could not open required defaults file: /home/$username/.local/share/akonadi/mysql.conf"
Pode solucionalo executando a seguinte orde coma superusuario e recargando logo o AppArmor:
aa-complain mysqld
En Kubuntu:
sudo aa-complain mysqld sudo /etc/init.d/apparmor reload
Teña en conta que pode que estea a utilizar o AppArmor mesmo se este non aparece na bandexa do sistema.
Asemade, algunhas distribucións fornecen un binario mysqld adicional chamado mysqld-akonadi que ten o AppArmor configurado correctamente. Se é ese o caso do seu sistema e aínda así ten este problema, pode haber dúas posibles causas:
- Akonadi segue a usar mysqld en vez de mysqld-akonadi. Pode cambiar iso en .
- AppArmor tampouco está configurado correctamente para mysqld-akonadi. Probe a executar a orde "aa-complain" con mysqld-akonadi en vez de con mysqld.
---
Tamén sufrirá este problema se o seu cartafol persoal está encriptado mediante encryptfs combinado con AppArmor xa que o perfil de AppArmor de Akonadi non conta nestes momentos cun cartafol persoal encriptado (habitual entre os usuario de Ubuntu Jaunty). Entre as mensaxes de erro están as seguintes:
ecryptfs_do_create: Failure to create dentry in lower fs; rc = [-13] ecryptfs_create: Failed to create file inlower filesystem
- Akonadi listará os seguintes erros:
Akonadi server process not registered at D-Bus
A solución consiste en editar o ficheiro "/etc/apparmor.d/usr.sbin.mysqld-akonadi". Despois da liña que di:
@{HOME}/.local/share/akonadi/** rwk,
Engada unha nova liña:
@{HOME}/.Private/** rwk,
Reinicie tanto AppArmor como Akonadi.
Requisitos non cumpridos
Para utilizar Akonadi necesita ter instalados os seguintes paquetes (pode que os nomes sexan distintos na súa distribución):
- O servidor MySQL (mysql en openSUSE)
- O complemento de MySQL para Qt4 (libqt4-sql-mysql en openSUSE)
Se compila Qt4 manualmente, asegúrese de que se compila o soporte para MySQL engadíndolle a seguinte opción:
-plugin-sql-mysql
Se «configure» non dá atopado o código do cliente MySQL necesario (por exemplo, di que «O soporte para MySQL non pode activarse por mor das probas de funcionalidade»), asegúrese de que o paquete correspondente está instalado (adoita chamarse «[lib]mysql[client]-dev[el]»). Ademais, segundo onde se instalasen os ficheiros de cabeceira de MySQL, pode que necesite fornecerlle parámetros adicionais a «configure» (coma «-l /usr/include/mysql» en openSUSE).
Se obtén o Qt4 directamente de Nokia, coma unha descarga de qt-sdk-linux-x86_64-opensource-2009.05.bin, obterá o seguinte erro na primeira proba (por medio da orde "akonadictl start"):
Database driver not found. Details: The QtSQL driver 'QMYSQL' is required by your current Akonadi server configuration. The following drivers are installed: QSQLITE. Make sure the required driver is installed.
O controlador que necesita é libqsqlmysql.so
Por desgraza dito controlador non formou parte da distribución ata xaneiro do 2010. Se ten unha versión anterior, terá que compilalo a partires do código fonte. Descargue o seguinte ficheiro:
qt-everywhere-opensource-src-4.6.0.tar.bz
Entón execute configure e make como se indicou previamente. Pero a orde make install non copia o controlador, polo que terá que copialo manualmente:
cp <qt-src-dir>/qt-everywhere-opensource-src-4.6.0/plugins/sqldrivers/libqsqlmysql.so /usr/local/bin/sqldrivers/
Pero a revisión 4.6.1, coma qt-sdk-linux-x86_64-opensource-2010.xx.bin, contén o controlador que necesita. 'Pero pode que sexa preciso ligar de novo o ficheiro libqsqlmysql.so se o libmysqlclient.so cambiou de versión.
Configuración do ambiente
O servidor Akonadi busca axentes e recursos de Akonadi nas rutas definidas na variable de ambiente XDG_DATA_DIRS. Se Akonadi se queixa de non atopar axentes ou recursos, comprobe que a variable estea definida correctamente. Teña en conta tamén que aínda que o estea na sesión de consola actual, pode que non estivese igual cando se iniciou o servidor. Iniciar o servidor manualmente na sesión de consola actual exclúe esta causa.
mysqld: unknown variable 'innodb_file_per_table=1'
Se o rexistro do servidor MySQL contén o seguinte erro, entón é que o seu servidor MySQL compilouse sen soporte para InnoDB, que é necesario para Akonadi, ou que InnoDB non está cargado no ficheiro mysql.conf:
[ERROR] /usr/libexec/mysqld: unknown variable 'innodb_file_per_table=1' [ERROR] Aborting
Probe a engadir:
#sql_mode=strict_trans_tables <- Add underneath this line #plugins plugin_dir=usr/lib/mysql/plugin < - This may be a different path plugin-load=ha_innodb.so
A táboa “mysql. servers” non existe
Se o rexistro do servidor MySQL contén o seguinte erro, entón o máis probable sexa que non ten o ficheiro de configuración de MySQL onde debería:
[ERROR] Can't open and lock privilege tables: Table 'mysql.servers' doesn't exist [ERROR] Cannot open mysql.db [ERROR] Cannot open mysql.user [ERROR] Cannot open mysql.event
Cópiea de /usr/share/config/akonadi/mysql-global.conf a ~/.config/akonadi/mysql-local.conf. (En Debian e openSuSE o ficheiro está en /etc/akonadi/mysql-global.conf). Logo ábrao e descomente a liña sql_mode=strict_trans_tables. Despois pode que reciba os seguintes erros:
[ERROR] Plugin 'InnoDB' init function returned error. [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed. [ERROR] Unknown/unsupported table type: innodb [ERROR] Aborting
En tal caso, no mesmo ficheiro busque a liña que comeza igual que a anterior (a que descomentou), pero ten parámetros adicionais, separados por comas (algo coma sql_mode=strict_trans_tables,strict_all_tables, etc.). Volva comentar a liña máis curta, sql_mode=..., e descomente a máis longa.
En openSUSE 11.2, executar a seguinte orde soluciona o problema:
mysql_install_db --datadir=$HOME/.local/share/akonadi/db_data/
Para Arch Linux:
mysql_install_db --datadir=$HOME/.local/share/akonadi/db_data/ --basedir=/usr
Actualización de Kubuntu 10.04 (Lucid Lynx)
Este é o resumo doutras entradas aquí presentes para aqueles que actualicen de Kubuntu 9.10 á versión 10.04, e que pode que estivesen a utilizar un arquivo persoal de paquetes (PPA polas súas siglas en inglés) para contar con correccións de erros da versión 4.3 da compilación de software de KDE.
Instale os requisitos necesarios. Borre a caché anterior de Akonadi. Inicie o servizo de Akonadi. Instale a base de datos. Actualice a base de datos. Deteña e reinicie o servizo Akonadi.
sudo apt-get install virtuoso-server mysql-server-5.1 rm -r $HOME/.local/share/akonadi akonadictl start mysql_install_db --datadir=$HOME/.local/share/akonadi/db_data/ mysql_upgrade --socket=$HOME/.local/share/akonadi/db_misc/mysql.socket akonadictl stop akonadictl start
A orde mysql_install_db anterior emitirá un informe coma o seguinte, que pode ser ignorado:
Installing MySQL system tables... 100501 18:04:30 [Warning] Can't create test file /home/[userid]/.local/share/akonadi/db_data/[hostname].lower-test
Fonte: Foros de KDE: «Akonadi 1.2.1 - some issues» (en inglés).
Actualización de KAddressBook
Ademais do remedio anterior para Kubuntu 10.4, os problemas ao engadir un directorio Vcard poden solucionarse executando a seguinte orde mentres Akonadi non estea executándose:
rm -rf $HOME/.config/akonadi
Non se pode inicializar a codificación de caracteres latin1
Se recibe o seguinte erro ao iniciar Akonadi, o máis probable é que estea a usar unha versión do servidor MySQL superior á 5.1.42:
Character set 'latin1' is not a compiled character set and is not specified in the '/usr/share/mysql/charsets/Index.xml' file Nepomuk QueryServer interface not available! Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString) DataStore::unhideAllPimItems() Character set 'latin1' is not a compiled character set and is not specified in the '/usr/share/mysql/charsets/Index.xml' file Database error: Cannot open database. Last driver error: "QMYSQL: Unable to connect" Last database error: "Can't initialize character set latin1 (path: /usr/share/mysql/charsets/)" Database error: Cannot open database. Last driver error: "QMYSQL: Unable to connect" Last database error: "Can't initialize character set latin1 (path: /usr/share/mysql/charsets/)"
Hai unha regresión coñecida en MySQL 5.1.43 e 5.1.44 que non lle deixa iniciarse a MySQL.
Vexa o informe do erro (en inglés) para máis información.
Reiniciar despois dun erro anterior
Se tivo problemas para iniciar Akonadi e os solucionou (como a falta dun paquete ou o problema con AppArmor) asegúrese de que o servidor Akonadi se apaga completamente antes de intentar inicialo de novo, executando a seguinte orde:
akonadictl stop
Pode comprobar que se apagou correctamente executando:
akonadictl status
Nalgunhas circunstancias o servidor Akonadi pode quedarse nun estado de execución parcial tras un erro que provocará que calquera intento de volver inicial falle tamén. Informe do erro se sofre este problema incluíndo o informa da auto-análise do problema inicial.
O "Gentoo-Assert"
Trátase dun problema peculiar que de momento só afecta aos usuarios de distribucións baseadas no código fonte, especialmente Gentoo. O seu nome provén das asercións (assertions) de MySQL coma as do seguinte exemplo e adoita causalo unha incompatibilidade de protocolo entre as bibliotecas de servidor e cliente de MySQL ou o controlador para MySQL de Qt.
akonadiserver: libmysql.c:4301: setup_one_fetch_function: Assertion `param->buffer_length != 0' failed.
Resulta extremadamente difícil de diagnosticar dado que a aserción antes mencionada só ocorre ás veces. Pero recibirá unha gran variedade de síntomas estraños:
- Os rexistros do protocolo ASAP amosan a creación correcta de obxectos que non deberían estar dispoñibles cando as seguintes ordes volven acceder a eles.
- Os rexistros do protocolo SQL amosan ordes INSERT ou UPDATE con valores que non se corresponden cos tipos das columnas pero que aínda así se efectúan correctamente.
- Os rexistros do protocolo SQL amosan unha gran gravación de identificacións aparentemente aleatorias que aínda así se consideran válidas.
Fontes:
- Foros de KDE: «Akonadi refuses to start due to some libmysql.c error?» (en inglés).
- Sistema Bugzilla de Gentoo: «app-office/akonadi-server-1.1.1 crash» (en inglés).
- KDE Bugs: «In standard configuration: "Unable to add collection attribute", "Unable to append mimetype for collection"» (en inglés, contén unha posible solución).
- Foros de Arch Linux: «Akonadi: MySQL errors» (en inglés).
Posible solución: recompilar o controlador de MySQL para Qt tras actualizar MySQL (o que probablemente foi a causa do problema).
Restablecer Nepomuk e Akonadi en KMail 2
Recoméndase encarecidamente que faga unha copia de seguranza dos seus datos antes de seguir estas instrucións.
Desde a introdución de KMail 2 na versión 4.6 da colección de software de KDE, para poder buscar correos ou acceder a cadernos de enderezos é necesario ir a e marcas as opcións e .
Se virtuoso-t fai uso de case o 100% dos núcleos do procesador e o sistema está case conxelado, non sería mala idea restablecelo todo.
Para restablecelo todo siga estes pasos:
Warning
akonadictl stop rm -rf ~/.local/share/akonadi/db_data/* akonadictl start # Tamén debería limpar os cartafoles temporais de KDE antes de iniciar KMail rm -rf /var/tmp/kdecache-$USER /tmp/ksocket-$USER /tmp/kde-$USER
Vaia a para comprobar se o cartafol de correos enviados é correcto. Pode que para algunhas das identidades non o sexa.
Vaia a e comprobe que o cartafol de entrada sexa correcto. Déronse casos non que non o era.
Comprobe todos os filtros, e fágao antes de obter correo. Recoméndase desactivar todos os filtros xa que poderían haber cartafoles incorrectos ou non inexistentes.
Tamén é importante, en caso de que teña algún cartafol “caducado”, que comprobe que o cartafol de recepción do correo estea correctamente configurado. Se ten marcada a opción , podería perder correos importantes se a caducidade se aplicase ao cartafol equivocado.
Acceda ás do menú contextual de cada un dos cartafoles para comprobar que as identidades non cambiaron ou se perderon en ningún dos cartafoles.
Chegados a este punto, pode proceder a limpar os datos de Nepomuk e a continuación activar o escritorio semántico.
Unha vez teña todo limpo, se non pode ler ningún correo, probe a pechar a sesión de escritorio e volver acceder para permitir que se reinicien todos os procesos.