Das könnte das gleiche Problem sein, welches MichaelH, Angua und ich auch haben.
[](https://)https://community.grommunio.com/d/1415-an-unexpected-error-has-occurred-grommunio-web-search
Ist das bei Dir ein bestehendes System, welches geupdatet wurde, oder ein frisch aufgesetztes System?
Suchfunktion in WebAPP / DeskAPP mit Fehlermeldung
Da ich die Veränderungen in den Optionspaketen mitbekommen möchte, die sich nicht alle urch Updates effektiv bemerkbar machen, setze ich mit jeder neuen Appliance ein System neu auf und übertrage die Daten, was gut funktioniert. Von daher ist mein aktuelles System basierend auf der Appliance v2023.11.2, Build1.3 vom 28.12.2023.
Ich kann mich erinnern, dass die Suchfunktion schon funktionierte und ich meine auch, dass ads mit der vorherigen Appliance der Fall war.
Bei mir ist es ebenfalls eine frisch installierte Appliance v2023.11.2. Die Daten wurden mit dem Script kopano2grommunio.sh von Kopano importiert. Abgesehen von der Suchfunktion in der WebApp (die DeskApp kenne ich nicht) funktioniert das wunderbar.
Zum Fehler bei der Suche mit der WebApp meint die Firefox Debug-Konsole:
Uncaught TypeError: r is null
onException grommunio-debug.js:1456
fire ext-base-all.js:41
fireEvent ext-base-all.js:41
processResponse grommunio-debug.js:9752
receive grommunio-debug.js:9619
stateChange grommunio-debug.js:9271
createDelegate ext-base-all.js:21
sendHttpRequest grommunio-debug.js:9126
send grommunio-debug.js:9415
doRequests grommunio-debug.js:12943
readAction grommunio-debug.js:12877
readAction grommunio-debug.js:82950
request grommunio-debug.js:12790
execute ext-base-all.js:41
load ext-base-all.js:41
load grommunio-debug.js:137390
search grommunio-debug.js:137532
search grommunio-debug.js:161187
startSearch grommunio-debug.js:81703
onSearchStart grommunio-debug.js:28238
fire ext-base-all.js:41
fireEvent ext-base-all.js:41
onTriggerClick grommunio-debug.js:55327
onAfterRenderSearchToolBox grommunio-debug.js:28295
c ext-base-all.js:41
fire ext-base-all.js:41
fireEvent ext-base-all.js:41
layout ext-base-all.js:41
runLayout ext-base-all.js:41
onResize ext-base-all.js:41
fire ext-base-all.js:41
fireEvent ext-base-all.js:41
onBodyResize ext-base-all.js:41
onResize ext-base-all.js:41
setSize ext-base-all.js:41
applyLayout ext-base-all.js:41
onLayout ext-base-all.js:41
layout ext-base-all.js:41
runLayout ext-base-all.js:41
onResize ext-base-all.js:41
fire ext-base-all.js:41
fireEvent ext-base-all.js:41
onBodyResize ext-base-all.js:41
onResize ext-base-all.js:41
setSize ext-base-all.js:41
setItemSize ext-base-all.js:41
onLayout ext-base-all.js:41
layout ext-base-all.js:41
runLayout ext-base-all.js:41
onResize ext-base-all.js:41
fire ext-base-all.js:41
fireEvent ext-base-all.js:41
setSize ext-base-all.js:41
setItemSize ext-base-all.js:41
onLayout ext-base-all.js:41
layout ext-base-all.js:41
setActiveItem ext-base-all.js:41
setActiveTab ext-base-all.js:41
focus grommunio-debug.js:88108
initPlugin grommunio-debug.js:18673
onContainerAdd grommunio-debug.js:18707
fire ext-base-all.js:41
fireEvent ext-base-all.js:41
add ext-base-all.js:41
create grommunio-debug.js:84946
openLayerComponent grommunio-debug.js:17525
onTriggerClick grommunio-debug.js:55319
onTriggerSpecialKey grommunio-debug.js:55270
fire ext-base-all.js:41
fireEvent ext-base-all.js:41
fireKey ext-base-all.js:41
I ext-base-all.js:41
Joerg die DeskApp kenne ich nicht
Mit der Deskapp (Windows Variante) bekomme ich den Fehler ebenfalls. Der integrierte Debugger meint:
- Edited
Ich habe seit einigen Tagen den selben Fehler. Bei mir ist es ein Bestandssystem, dass aktualisiert wird.
Andy
Ich überlege auch schon seit längerem mal eine frische Appliance aufzusetzen. Wie überträgst du die Daten? Gibt es eine Anleitung dazu, bzw. empfohlene Vorgehensweise oder hast du ein best practice? Das würde mich sehr interessieren 
grommunio:~ # rpm -qi gromox | head -n 3 && echo "" && rpm -qa grom | sort
Name : gromox
Version : 2.21.29.g81a193a
Release : lp155.18.1
grommunio-admin-api-1.14.2.63c43b5-lp155.87.1.noarch
grommunio-admin-api-bash-completion-1.14.2.63c43b5-lp155.87.1.noarch
grommunio-admin-common-23.e396105-lp155.18.1.noarch
grommunio-admin-web-2.8.0.28.7ed9ad0-lp155.74.1.noarch
grommunio-antispam-3.7.4-lp155.5.1.x86_64
grommunio-archive-1.3.13.g137.d1b0df1b-lp155.6.17.x86_64
grommunio-auth-0.2.16.e187c26-lp155.30.1.noarch
grommunio-chat-7.8.0-lp155.8.1.x86_64
grommunio-common-24.0cedcbe-lp155.36.1.x86_64
grommunio-cui-1.0.257.aebaf9a-lp155.61.1.noarch
grommunio-dav-1.3.18.e16f8a2-lp155.1.1.noarch
grommunio-error-pages-1.0.10.bb2df37-lp155.10.1.noarch
grommunio-imapsync-2.264-lp155.1.1.noarch
grommunio-index-1.0.1.gd50c1fd-lp155.54.1.x86_64
grommunio-jicofo-2.0.5390-lp153.12.4.noarch
grommunio-keycloak-23.0.0-lp155.3.1.noarch
grommunio-setup-1.0.109.048c9c5-lp155.48.1.noarch
grommunio-sync-2.0.49.fe860ff-lp155.144.1.noarch
grommunio-videobridge-2.1.508-lp153.16.4.noarch
grommunio-web-3.6.18.12b5ccdd-lp155.16.1.noarch
gromox-2.21.29.g81a193a-lp155.18.1.x86_64
gromox-debuginfo-2.21.29.g81a193a-lp155.18.1.x86_64
gromox-debugsource-2.21.29.g81a193a-lp155.18.1.x86_64
grub2-theme-grommunio-1-lp155.17.1.noarch
patterns-grommunio-1-lp155.9.1.x86_64
plymouth-theme-grommunio-1-lp155.17.1.noarch
system-user-grommunio-3-lp155.10.6.noarch
system-user-gromox-2-lp155.15.1.noarch
tf91 I have successfully been using the following procedure to migrate the data (Org, Domain, Users and the emails etc) from one appliance build to 'the latest and greatest' since early summer last year, as exporting and importing via Outlook was getting tedious.
I always make a clone of the my live Grommunio Appliance VM first, and do a full test migration on that clone to catch any issues before migration of my live server. Good use of snapshots made here to save having to rebuild the appliance from the ISO if things don't go to plan.
And it goes without saying once you have completed the migration - TEST - TEST - TEST. If all goes well you can now migrate your actual live server/appliance, in the knowledge you have already successfully tested the process.
Migrate Users and Data from Old server to New server.
1. Build a new appliance as normal - up to the point where you would start adding the Organisation Name, Domain and Users - this will all be imported via the process below), call this ‘new server’ in the steps below. Check you can log into it and any certificates are applied. It should work like your live server but without any data.
- Update and reboot the source (old server) and target (new server) system: zypper refresh & & zypper update (or use the Update/Upgrade Options in the GUI if you have it).
- If you can, stop inbound Internet email and user access to the live server mailboxes to avoid missing emails during migration. This should not happen as point 5 below will stop all services on old and new servers, but always a good option if you have it.
- Jus incase you missed this above - If you are using Grommunio in a Virtual Machine then optionally clone live server to avoid any damage/corruption to current live server during migration (call this ‘old server’ in steps below), just in case you need to revert to what was your current live server.
- Stop services on both systems: systemctl --all --output json list-units| jq '.[]|select(.unit|test("(grom.|nginx|.fpm).service")).unit' |xargs systemctl stop
- Export of the MariaDB database on old server: mysql --execute="SHOW DATABASES" --skip-column-names --batch |grep -Ev '^(mysql|(performance|information)_schema)$' |while read -r DB; do mysqldump --single-transaction --routines --triggers --events --add-drop-database $DB > /usr/local/share/$DB.sql ; done
- User Data - transfer old server to new server: rsync -aH -essh --delete --numeric-ids -P --stats --inplace /var/lib/gromox/ root@192.168.xxx.xxx:/var/lib/gromox/
- Move MariaDB backup (from step 6) from old system to new system. Run this on old server: rsync -aH -essh --delete --numeric-ids -P --stats --inplace /usr/local/share/ root@192.168.xxx.xxx:/usr/local/share/
- Set folder permissions for Grommunio Core on new server: chown -Rf grommunio:gromox /var/lib/gromox
- If you use Grommunio Files - Set folder permissions for Grommunio Files on new server: chown -Rf grofiles:grofiles path-to-your-grommuniuo-files-data-directory
- Import of the MariaDB Grommunio database on new server: mysql grommunio < /usr/local/share/grommunio.sql
- If you use Grommunio Files - Import of the MariaDB Grommunio Files database on new server: mysql grofiles < /usr/local/share/grofiles.sql
- Import of the MariaDB system database on new server: mysql sys < /usr/local/share/sys.sql
- Check import user /var/lib/gromox/user/x/y/: run grommunio-admin user query username maildir on both systems - make sure they match.
- Reboot
The text in bold above can be copied and pasted into an SSH terminal to save you typing the commands.
If you are using any other options of the Grommunio Groupware, then you will need to add the relevant migrations to the above plane as I only use Grommunio Mail and Files at this time.
Hope the above is of use to you.
Thanks to @Andy, @WalterH and others who through their various posts during spring/summer last year helped me derive the above process. Hope it will assist many others, old and new, in the community with an easier upgrade path when a new appliance in made available.
I am always welcome to to suggestions for tweaks/improvements to the process as they may well make the process of migrating a little less of the challenge I found when I first started using Grommunio in August 2022.
Mark
Also bei mir tritt der Fehler in der Suchfunktion nicht auf!
Community Version mit Update von gerade eben auf Basis einer seit Januar 2022 gepflegten VM Appliance.
Ich habe den Fehler auch nicht, aktuelle Community Edition auf ca. 9 Systemen. Alles Appliances, unterschiedlich alt.
Mit der letzten oder vorletzten Appliance ging das bei mir auch. Die spannende Frage ist wohl, von was das abhängt.
Hallo Walter
Das freut mich für Dich und alle, die das Problem nicht haben. Allerdings bin ich "glücklicherweise" nicht der Einzige mit dem Problem. Hier im Forum zähle ich nun mit @Andy, @Angua, @MichaelH, @externa1 und mir selber schon fünf Anwender mit dem Problem. Ich habe die Appliance nun dreimal komplett frisch aufgesetzt. Beim ersten Versuch hast Du mir verschiedene Tipps gegeben, dich ich alle auf meinem eigenen Mailkonto probiert habe. Leider hat alles nichts gebracht. Beim zweiten Versuch gings dann auf meinem Account (Daten wurden auf die gleiche Weise von Kopano importiert. Daraufhin habe ich weitere 4 Nutzer angelegt und deren Daten importiert. Bei denen funktioniert die Suche in der WebApp nicht. Jetzt habe ich heute wieder eine neue Maschine angelegt bei der nur ein Nutzer angelegt wurde. Es wurden keine Daten importiert, lediglich testhalber einige Mails versendet/empfangen. Auch bei diesem Konto geht die Suche mit der WebApp nicht. Ich suche noch immer nach dem Unterschied zu dem einzigen Mailkonto wo es funktioniert. Bis jetzt konnte ich keinen Unterschied finden :-(
Die spannende Frage von was das wohl abhängt:
Das hört sich nach "FRICKLER-ARBEIT" an!
Um hier weiter zu kommen müssen zuerst folgende Fragen beantwortet werden:
Problem nur in der WEP-App, oder auch auf anderen Clients (Windows Outlook nativ, SmartClients wie iphones, androids etc via EAS) oder nur in der WEB-APP.
Problem unter welchem Browser, ggf unter welchen Betriebssystem
Problem unter welchem Zugriff (also über die FQND oder per nativer IP)
Problem welcher Installationstiefe (also lediglich Core oder mit welchen optionalen Plug-Ins)
und natürlich immer: Das Gromunio ist meldungs-aktuell in der richtigen/aktuellsten und funktionsgecheckten Version (Community / Suported) und es wurde danach auch prinzipiell rebooted.
Wenn diese Infos fließen kann ich ggf. versuchen mittels FRICKELEI Abhängigkeiten zu finden.
Ansonsten wird das Müßig da zwar einige aber nicht alle das Problem haben, 5 Meldungen sind bei meinem ansonsten funktionierenden System ehrlich mal gesagt nicht viele. Vielleicht 5 zuviel aber ansonsten scheinbar kein "großes Problem". ---- Ich beschwere mich auch nicht das dies und das in meiner Appliance primär nicht funktioniert weil ich sie um fail2ban erweitert habe, bei installationen ausserhalb der CoRE-Inhalte (also mit Files, Office oder sonstigem) empfehle ich grundsätzlich eine Supportet Version. Hier kann der Gro-Support besser helfen als diese Forum und er wird ja auch entsprechend finanziert!
F@H
Bei mir zeigt sich das Bild nur bei der WebAPP / DeskAPP.
In Outlook unter Windows und mit der Nine APP auf den Android-Smartphones gibt es keine Probleme mit der Suche, allerdings arbeite ich da jeweils und überall im Full-Cached-Modus. Im Non-Cached-Modus geht das bei Outlook bekanntlich generell nicht und auf meinen Smartdevices habe ich Non-Cached noch nie betrieben.
Im weiteren, in den von mir verwendeten Browsern Firefox, Chrome, Edge ist das Fehlerbild genau gleich und meine Erfahrung ist auch, wenn in der DeskAPP solche Effekte auftreten, macht der verwendete Browser keinen Unterschied. Ebenfalls keinen Unterschied macht die Verwendung der FQND oder IP. Bezüglich der Installation habe ich Core und alle Optionsmodule installiert. Allerdings war jene Installation, mit welcher diese Suche funktionierte, in gleicher Weise ausgestattet. Schliesslich, aktueller Updatestand und Reboots sind bei mir ohnehin schon Gewohnheit.
Ja, bei mir auch nur WebApp und DeskApp. Getestet mit Windows und Linux, Firefox und Chrome, mit IP und FQDN. Installiert ist nur Core ohne weitere Plugins in der Community-Version:
rpm -qi gromox | head -n 3 && echo "" && rpm -qa grom | sort
Name : gromox
Version : 2.21.29.g81a193a
Release : lp155.20.1
irgend etwas ist bei euch anders als bei mir!
Ich war heute mittag auf einen Kaffee bei der betreuten Nachbarschaft. Habe dort eine GRO-Community_Appliance geprüft und mit einem Update versehen. Also auch Suse 15.4 auf 15.5.
In der primären Version funktioniert die Suche. Nach allen Updates funktioniert die Suche in der WebApp nun auch unter der Version Suse 15.5. Die Basis war eine wirklich alte Kiste, niemals wurde auf dieser Kiste ein UPGRADE angestossen. Alle UPDATES erfolgten per ssh befehl oder über die WEB Admin GUI.
Aus dieser Erfahrung kann ich weiter keine grundlegende problematik bei Grommunio finden. Die Frickler Frage bleibt also was macht ihr anders als der Standart?
Ich habe jede Appliance seit Ende 2022 installiert und meine Daten entsprechend transferiert. Dadurch bestätigt sich für mich immer wieder, dass es ein Unterschied ist, ob ich eine Basis-Appliance betreibe, die bereits seit einiger Zeit installiert ist und laufend auf den neusten Stand gebracht wird, oder ich die gerade aktuelle Appliance installiere und mit dieser weiter arbeite. Wenn also in einer fortlaufend aktualisierten Appliance bei deren Installation irgendwelche Fehler oder fehlerhafte Konfigurationen eingeschlichen haben, werden diese nicht in allen Fällen durch Updates beseitigt, wohingegen mit einer neuen Appliance eine bereinigte Installation eingerichtet wird.
Ich konnte diesen Effekt bei Jitsi beobachten, was zwar wegen der Reverse-Proxy-Geschichte noch immer nicht läuft, aber dafür auf andere Weise nicht läuft. Oder nun die Geschichte mit der Suche. Ich kann mich erinnern, dass mit der vorherigen Appliance v2023.11.1, Build 14.2 vom 4.12.23 die Suche bei mir noch funktioniert hat. Hätte ich diese bis heute geupdatet, würde die Suche wohl noch gehen.
Ich kann mir das nur so erklären, dass die Konfliktbereinigung noch nicht richtig funktioniert, denn mit jeder Appliance-Installation bleiben am Ende bei einem Check mit zypper dub irgendwelche Ungereimtheiten mit installierten Paketversionen.
- Edited
@Mister2
Thank you very much for your How-to. I made a first try But wasnt able to login to my Accounts on the new system. I had some warning when exporting the data from the old to the new system. You also had this? I also use ldap to Import the user accounts, maybe thats a problem.
I will try it again.
Check the permissions in the directories and subdirectories to which you are transferring data (e.g. /var/lib/gromox/...), as these may no longer be correct after the transfer and it will then no longer be possible to log in.
tf91 I don't use LDAP for my accounts, however, in point 1 of my process I mentioned that you should NOT creathttps://community.grommunio.com/d/1444-suchfunktion-in-webapp-deskapp-mit-fehlermeldunge the Organisation, Domain or Users, as the database imports to your new server (items 11-13 - only use 12 if you are using Grommunio Files) will do all this as per your existing (old) server.
Looking back at my post and just to make sure this is not misinterpreted, I should have mentioned that the bold text in the various points, should be considered as a single line, not as 1 or more as it displays. ie in Item 6 you should highlight all the text from 'mysql' right through to (and including) 'done' as this is just one command sequence, it is a long command, hence my suggestion to copy and paste it. Also the 'root@192.168.xxx.xxx' bits in item 7 & 8 should be replaced with the account and IP address of your 'root' user on the new server.
Hope your second/third test go a little better. The whole above process should be performed while logged in as the default 'root' user (on both servers) otherwise you might come across permissions errors during the export process.
In item 9 I originally had chown -Rf grommunio:gromox /var/lib/gromox/user, but found that following the 11/23 new appliance ISO's that Grommunnio couldn't find my user directories after I had migrated the data. It seems there had been a slight change to the permissions in the appliance ISO and I had to set the permissions one directory higher. I built a fresh VM to check this, from the same appliance ISO, and using WinSCP found the permissions were different to my previous versions, so modified item 9 to its current form. Once I had made this change I have not had any other issues in the roughly 10 migrations I have done since with the above process.
Hope the above helps.