Anmeldung bei Owncloud nach Update nicht mehr möglich

Hallo zusammen,

meinen UCS-Server (DC-Master) habe ich heute auf Version 4.0-3 errata330 upgedatet. Anschliessend habe ich das verfügbare Update von owncloud 7.0.2 auf 7.0.10 eingespielt. Kurz vor Abschluss der Installation kam ein Hinweis ähnlich: “Das System kann nicht gesperrt werden”. Den genauen Wortlaut kann ich leider nicht mehr erinnern.

Für Owncloud wird nun die Version 7.0.10 als installiert angezeigt. Ich konnte mich auch einmalig als Administrator über den Browser einloggen. Nach dem ersten Abmelden funktioniert ein weiters Anmelden bei Owncloud im Browser weder als Benutzer noch als Administrator. Auch über die vorher lauffähigen Desktop- und Mobileclients bekomme ich keine Verbindung mehr. Im Browser wird die Fehlermeldung “Connection to LDAP server could not be established” angezeigt.

/var/www/owncloud/occ status
ergibt:

PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/lib/php5/20100525/imap.so' - /usr/lib/php5/20100525/imap.so: cannot open shared object file: No such file or directory in Unknown on line 0
Array
(
    [installed] => true
    [version] => 7.0.10.0
    [versionstring] => 7.0.10
    [edition] => enterprise
)

Wo kann ich bei der Fehlersuche ansetzen?

Gruß
Uwe

Hallo,

mich wundert der Verweis auf die IMAP-Bibliothek.
Haben Sie auf dem System evtl. Horde oder irgendetwas anderes, z.B. ein ownCloud-Plugin, welches einen PHP-basierten Webmailer bereitstellt, installiert?

Im ownCloud-Log unter /var/lib/owncloud könnten evtl. weitere Hinweise stehen.

Viele Grüße,
Dirk Ahrnke

Hallo Herr Ahrnke,

vermutlich ja: Zarafa in Version 7.1.11-R1 ist aus dem Appcenter installiert. Ist dort der Webmailer PHP-basiert?
Owncloud und Zarafa haben auf dem Server bislang mehr oder weniger friedlich koexistiert. Bei Updates gab es in der Vergangenheit kleinere Schwierigkeiten bei der Installation, die aber mit Hilfe eines Beitrags dieses Forums umgangen werden konnten.

In /var/lib/owncloud/owncloud.log finden sich nach dem Update u.a.:

{"app":"remote","message":"Connection to LDAP server could not be established","level":4,"time":"2015-09-24T15:27:14+00:00"}
{"app":"PHP","message":"PHP Startup: Unable to load dynamic library '\/usr\/lib\/php5\/20100525\/imap.so' - \/usr\/lib\/php5\/20100525\/imap.so: cannot open shared object file: No such file or directory at Unknown#0","level":3,"time":"2015-09-24T15:27:46+00:00"}
{"app":"user_ldap","message":"No LDAP Connection to server server1.xxx.de","level":3,"time":"2015-09-24T15:27:46+00:00"}
{"app":"hook","message":"error while running hook (\\OC\\Files\\Storage\\Shared::setup): Connection to LDAP server could not be established","level":3,"time":"2015-09-24T15:27:46+00:00"}

und

{"app":"remote","message":"Connection to LDAP server could not be established","level":4,"time":"2015-09-24T15:28:50+00:00"}
{"app":"user_ldap","message":"Bind failed: 49: Invalid credentials","level":3,"time":"2015-09-24T15:29:22+00:00"}
{"app":"user_ldap","message":"Bind failed: 49: Invalid credentials","level":3,"time":"2015-09-24T15:29:22+00:00"}
{"app":"user_ldap","message":"No LDAP Connection to server server1.xxx.de","level":3,"time":"2015-09-24T15:29:22+00:00"}
{"app":"hook","message":"error while running hook (\\OC\\Files\\Storage\\Shared::setup): Connection to LDAP server could not be established","level":3,"time":"2015-09-24T15:29:22+00:00"}

aber auch vor dem Update bereits in großer Anzahl:

{"app":"user_ldap","message":"Connection could not be established","level":3,"time":"2015-09-21T17:56:27+00:00"}
{"app":"PHP","message":"PHP Startup: Unable to load dynamic library '\/usr\/lib\/php5\/20100525\/imap.so' - \/usr\/lib\/php5\/20100525\/imap.so: cannot open shared object file: No such file or directory at Unknown#0","level":3,"time":"2015-09-21T18:01:01+00:00"}
{"app":"user_ldap","message":"Bind failed: 49: Invalid credentials","level":3,"time":"2015-09-21T18:06:31+00:00"}

Trotz der Fehlermeldungen hat der Zugriff auf Owncloud von mehreren Geräten im Netzwerk sowie mobil von aussen lange Zeit gut funktioniert.

Gruß
Uwe

Hallo,

Zarafa macht zwar viel mit PHP, nutzt aber kein IMAP. Das würd ich erstmal außer Acht lassen.

Das Log sagt “No LDAP Connection to server…”, während des Setups wird dort der passende Server (m.E. aus ldap/server/*) eingetragen. Der Rest der Konfiguration wird aus den UCRV owncloud/ldap genommen.

Es wäre erstmal zu prüfen, ob der angegebene LDAP-Server korrekt (in Ihrem Fall wahrscheinlich dieser eine Server) ist und der LDAP-Dienst läuft (Test mit univention-ldapsearch).
Die LDAP-Konfiguration kann man prüfen/ändern, wenn man sich als owncloudadmin anmeldet. An den Filtern sollte man aber nur drehen, wenn man sich über die Tragweite im Klaren ist.
Das Passwort vom owncloudsystemuser könnte man allerdings, falls man es im UCS ändern musste, durchaus eintragen.

Viele Grüße,
Dirk Ahrnke

Hallo,

univention-ldapsearch liefert eine sehr lange Ausgabe. Auf welche EInzelheiten wäre denn dabei zu achten?

Eine Anmeldung als owncloudadmin im Browser hat soeben wieder einmalig funktioniert, nach dem Abmelden ergab eine versuchte Anmeldung als User direkt wieder einen internen Fehler. Ab diesem Zeitpunkt bekomme ich im Browser nur noch die Anzeige “Connection to LDAP server could not be established”, die Anmeldemaske fehlt bereits, daher ist zur Zeit keine weitere Anmeldung als owncloudadmin mehr möglich.

Das Ergebnis von univention-ldapsearch sieht nach wie vor genauso aus, das Ende der Ausgabe so:

# search result
search: 3
result: 0 Success

# numResponses: 480
# numEntries: 479

An der Konfiguration wurde wissentlich nichts verstellt. Ich werde morgen nochmals versuchen, ob eine Anmeldung wieder möglich ist, um die Konfiguration zu sehen.

Gruß
Uwe

Hallo,

wenn univention-ldapsearch Ergebnisse liefert, ist das schon mal ein gutes Zeichen. Es bedeutet für uns erstmal, dass der LDAP-Server funktioniert.
Wenn ownCloud anderer Meinung ist, könnte in der Konfiguration ein falscher Wert stehen. Das sollte man als owncloudadmin im Admin-Menü kontrollieren können.

Das Problem selbst kann ich in einer Testinstallation nicht nachstellen.

Es wäre ggf. sinnvoll, den “PHP Startup” Fehler zu eliminieren. Sie haben vermutlich in /etc/php5/conf.d noch ein PHP-Modul zu stehen, welches die nicht existierende imap.so als Extension einbinden will. Das Modul kann man mit php5-dismod deaktivieren.

Viele Grüße,
Dirk Ahrnke

Hallo,

in der Tat existiert in /etc/php5/conf.d eine Datei imap.ini mit folgendem Inhalt

; configuration for php IMAP module extension=imap.so
Leider weiß ich nicht, wie ich dieses Modul sauber entfernen kann. Mit php5dismod imap.so bekomme ich maximal

WARNING: imap.so module does not exist!
Wie lautet der genaue Befehl? Zu php5dismod habe ich bislang noch keine aussagekräftige Hilfe gefunden.

Zur evtl. fehlerhaften Konfiguration von owncloud mache ich mich einmal auf die Suche, die lauffähige Einrichtung wurde ja dank der Installation aus dem Appcenter ehemals automatisch eingetragen. Aus dem gleichen Grund ist mir aber auch nicht bekannt, wie denn die korrekte Konfiguration aussehen müsste.

Vielen Dank schon einmal bis hierher!

Gruß
Uwe

Hallo,

soweit mit bekannt, sollte es reichen, php5dismod mit dem Namen des Moduls, wie es in /etc/php5/mods-available steht, aber ohne Extension aufzurufen.
Also “php5dismod imap”.
Ich weiß allerdings nicht, wo das bei Ihnen herkommt. Im aktuellen Zarafa-Paket ist es nicht dabei, bei ownCloud selbst auch nicht.

Viele Grüße,
Dirk Ahrnke

Hallo,

“php5dismod imap” hat nicht funktioniert, evtl. da es nichts entsprechendes in mods-available gab. Das Modul habe ich nun deaktiviert indem ich es händisch von /etc/php5/conf.d nach /etc/php5/mods-available verschoben habe. Die Fehlermeldungen in /var/lib/owncloud/owncloud.log tauchen nun nicht mehr auf.

Der eigentliche Fehler lag jedoch noch woanders. Eingeloggt als owncloudadmin wurde die Server-Konfiguration als nicht korrekt bemängelt. Nachdem ich Owncloud in der gleichen Version auf einer weiteren UCS in einer virtuellen Maschine installiert hatte und alle Einträge verglichen hatte, aber alle identisch waren, blieb nur noch das nicht sichtbare Passwort übrig. Nach der erneuten Eingabe des Passworts wurde die Konfiguration als OK markiert und alle Geräte können wieder auf OC zugreifen. Warum das Passwort nicht korrekt war, entzieht sich jedoch meiner Kenntnis.

Vielen Dank nochmals für die Unterstützung!

Gruß
Uwe

Mastodon