Adminbackend nicht erreichbar

Server
,
1

Hallo lieber Forenleser,

Nach dem Login als Administrator ist es nicht möglich, auf das Adminbackend zu gelangen.
Nach einiger Wartezeit erscheint oben folgender Hinweis “Failed to perform request for notifications”.
Danach erschein eine Seite mit Fehler “504 Gateway Time-out nginx”.
siehe: https://gyazo.com/985e16ec7b1a4a67d5efe562595b0f8f

Jetzt befindet sich die Seite in einer Dauerschleife, die Syno ist fast zu 100% ausgelastet.

Die Konfiguration lief bereits nach Update von 9.0.3 auf 9.0.4 einige Tage problemlos, es erfolgte keine Änderung der Konfiguration. Das erstaunliche ist, dass vormittags das System noch perfekt lief, nachmittags dann die Störung auftrat.
Es wurde in dieser Zeit nur Kalender und Dateien von 3 Benutzern synchronisiert, keinerlei Änderungen an der Konfiguration an owncloud, apache oder nginx.

owncloud 9.0.4 läuft auf einer Synology DS214+. In der Web Station ist Apache als Webserver ausgewählt.
PHP5.6 läuft auf dem System.
Bis das zeitweise kein Adminbackend erreicht werden kann, läuft die owncloud zufriedenstellend.

Kann mir jemand einen Lösungvorschlag geben?

2

Wenn du Apache als Webserver nutzt, hast du dann noch einen nginx davorgeschaltet? Den Gateway-Timeout bekommst du ja von dem nginx.

Ich weiß nicht, wieviel Zugriff du auf die Webserverkonfiguration bei deiner NAS-Box hast. Aber prinzipiell ist es möglich, die Timeouts (wahrscheinlich nginx<->php) entsprechend anzuheben.

3

Hallo tflidd,

wenn es nach mir ginge, sollte man wählen können, ob man nginx oder apache nutzen möchte.
nginx läuft auf der Synology DS wohl permanent als Backendserver, egal was man nutzen möchte.
Dazu kommt noch, dass nach jedem Neustart die nginx-Konfiguration neu erstellt und geschrieben wird.

Vom Synology-Support erhielt ich bereits eine Info:

“Es hängt anscheinend mit dem Timeout für den jeweiligen backend server zusammen.
Wenn Sie Nginx nutzten möchten fügen Sie die folgende Zeile: fastcgi_read_timeout 300s; in /etc/nginx/fastcgi.conf ein.
Wenn Sie Apache nutzten möchten fügen Sie die folgende Zeile: proxy_read_timeout 300s; in /etc/nginx/proxy.conf ein.”

Habe die proxy.conf entsprechend editiert. Nach Neustart lief es auch erfreulicherweise, sogar noch nach einem getimten Neustart. Doch im Laufe des Nachmittags war das Adminbackend in owncloud wieder nicht erreichbar.

4

Im Admin-Backend kann es auch wegen unterschiedlichen, anderen Probleme in Deinem Setup zu timeouts kommen. Ich hatte hier in der Vergangenheit mal ein FAQ dazu zusammen gestellt:

5

Hallo RealRancor,

ja ich erinnere mich, das ich dein Artikel bereits gelesen habe. Die App sind uptodate. Ich durfte bisher den Kalender updaten, mehr nicht.
Die Kontrolle ob die .htaccess richtig arbeitet hat mich schon interessiert. Nur leider bringt mich ein Link auf php-Quellcode nicht weiter. Wäre ich Webentwickler hätte ich hier nicht um Hilfe gebeten.
Wie exakt muss ich denn vorgehen, damit ich die korrekte Funktion der .htaccess überprüfen kann.
Muss ich den markierten Quellcode in der config.php einfügen, oder sollte ich einen speziellen Url-Aufruf tätigen?

Ich habe ebenfalls mal in der config.php verschiedenes probiert:

‘overwrite.cli.url’ => ‘https://meineDomain.de/owncloud’, das /owncloud entfernt
und auch hier
‘htaccess.RewriteBase’ => ‘/owncloud’, das owncloud entfernt

in der .htaccess
RewriteBase /owncloud das owncloud entfernt

und diverse Neustarts getätigt. Erstaunlicherweise läuft owncloud mit diesen Änderungen genauso!
Alles funktioniert außer der Zugang zum Adminbackend als Admin.
Hinweis: Mein owncloud ist nur über Port443 https zu erreichen, keine Portweiterleitung im Router für Port80.
Toll wäre es, wenn Owncloud.org einen Link auf der Website anbieten würde, wo der Anwender seine owncloud-Installation zB. auf Sicherheit testen könnte.
Ich verstehe nicht, warum die Installation mal einwandfrei läuft, dann nur der Adminbereich versperrt bleibt!!!

6

Ich denke Du verwechselst da im Moment zwei FAQs. Der obgen verlinkte beschreibt nichts zum Thema RewriteBase oder ähnliches.

Schau Dir aber mal den “workaround” part in der FAQ an. Das ist der wichtige Teil und Du musst kein Webentwickler sein um einen Eintrag in der config.php zu ändern.

7

Ja, die automatischen Tests sind sinnvoll, aber benötigen relativ lange. Ich würde einfach nach und nach die Tests abschalten. Und dann eben nach Bedarf (App installieren etc.) bestimmte checks wieder aktivieren.
Nach dem Update würde ich dann wieder die Tests laufen lassen, gerade mit den Zugriffen.

Eines kannst du auch manuell prüfen, den direkten Zugriff auf das Data-Verzeichnis:
https://example.org/data/username/files
Das sollte dir eigentlich den Zutritt verwehren.

8

Habe in der config.php folgendes eingefügt:

‘appstoreenabled’ => true,
‘updatechecker’ => true,
‘has_internet_connection’ => true,
‘check_for_working_webdav’ => true,
‘check_for_working_htaccess’ => true,

zusätzlich die App: OwnNote deinstalliert.

Bezüglich des Adminbackends keine Änderung, leider kein hineinkommen.

9

Hi,

sollten:

'appstoreenabled' => false,
'updatechecker' => false,
'has_internet_connection' => false,
'check_for_working_webdav' => false,
'check_for_working_htaccess' => false,

sein. “true” bedeuted in dem Fall ja dass die checks nicht deaktiviert werden.

10

Hallo tflidd,

wenn ich dies eingebe https://meineDomain.de/data/username/files

wird mir meine Loginseite/Startseite angezeigt. Denke das dies mal was positives ist, oder?

11

Ja, das ist ok. Nur wenn man dann alle Dateien angezeigt bekommt, wäre das ein Problem.

12

Das freut mich, scheint der Zugang wenigstens abgesichert zu sein. :relaxed:

Habe die erwähnten Einträge auf false gesetzt, leider weiterhin kein Zugang zur Adminseite.

13

Dann lösche mal die komplette data/owncloud.log und öffne das Admin-Backend nochmals. Irgendwie muss man an entsprechende Logdatein kommen, sonst kann man hier schlecht weiter helfen.

14

jooo passiert. owncloud.log gelöscht und DS neu gestartet.
Ich komme jetzt auf die Adminseite!!! Zwar mit Fehlermeldung “…keine funktionierende Internetverbindung…”.
Warum geht es jetzt, Neustarts habe ich bereits jedsmal gemacht?
Das owncloud.log ist noch leer.

15

Du hast das loglevel noch ändern, damit er mehr ausgibt. Hier alles zu den Logfiles:

16

‘debug’ => true, in der config eingefügt und /var/log/php-errors.log erstellt

Habe folgende Werte nacheinander auf true gesetzt:
‘appstoreenabled’ => false,
‘updatechecker’ => false,
‘has_internet_connection’ => false,
‘check_for_working_webdav’ => false,
‘check_for_working_htaccess’ => false,
‘check_for_working_wellknown_setup’ => false,

Beim letzten Wert erhielt ich den Hinweis im Gelben Kasten oben mitte: “Failed to perform request for notifications”.
Er verschwand aber wieder und ich blieb auf der Adminseite.

Jetzt ein kurzer Ausschnitt aus dem owncloud.log:

{“reqId”:“CgwFzfBpDdlh74+n5z/6”,“remoteAddr”:“XXX.XXX.XXX.XXX”,“app”:“PHP”,“message”:“A session had already been started - ignoring session_start() at /volume1/web/owncloud/lib/private/session/internal.php#95”,“level”:0,“time”:“2016-08-01T09:03:28+02:00”,“method”:“GET”,“url”:“/index.php?logout=true&requesttoken=QzljfgsIDSIBBzQvJFN6ChYsdQkSBUoBCFUEJW1GNyA%3D%3A9U%2B9GdguLMceT13Mng6bQo8H9dvlX5tCcZidQfJ73bU%3D”,“user”:“–”}
{“reqId”:“MGXv7cf2q9vDBhG1ShYM”,“remoteAddr”:“XXX.XXX.XXX.XXX”,“app”:“webdav”,“message”:“Exception: {"Message":"HTTP\/1.1 401 No ‘Authorization: Basic’ header found. Either the client didn’t send one, or the server is mis-configured, No ‘Authorization: Basic’ header found. Either the client didn’t send one, or the server is mis-configured","Exception":"Sabre\\DAV\\Exception\\NotAuthenticated","Code":0,"Trace":"#0 [internal function]: Sabre\\DAV\\Auth\\Plugin->beforeMethod(Object(Sabre\\HTTP\\Request), Object(Sabre\\HTTP\\Response))\n#1 \/volume1\/web\/owncloud\/3rdparty\/sabre\/event\/lib\/EventEmitterTrait.php(105): call_user_func_array(Array, Array)\n#2 \/volume1\/web\/owncloud\/3rdparty\/sabre\/dav\/lib\/DAV\/Server.php(446): Sabre\\Event\\EventEmitter->emit(‘beforeMethod’, Array)\n#3 \/volume1\/web\/owncloud\/3rdparty\/sabre\/dav\/lib\/DAV\/Server.php(248): Sabre\\DAV\\Server->invokeMethod(Object(Sabre\\HTTP\\Request), Object(Sabre\\HTTP\\Response))\n#4 \/volume1\/web\/owncloud\/apps\/dav\/lib\/server.php(150): Sabre\\DAV\\Server->exec()\n#5 \/volume1\/web\/owncloud\/apps\/dav\/appinfo\/v2\/remote.php(29): OCA\\DAV\\Server->exec()\n#6 \/volume1\/web\/owncloud\/remote.php(138): require_once(‘\/volume1\/web\/ow…’)\n#7 {main}","File":"\/volume1\/web\/owncloud\/3rdparty\/sabre\/dav\/lib\/DAV\/Auth\/Plugin.php","Line":188,"User":false}”,“level”:0,“time”:“2016-08-01T09:12:47+02:00”,“method”:“REPORT”,“url”:“/remote.php/dav/calendars/XXX/XXX/”,“user”:“–”}
{“reqId”:“9N0/YfnIa4jM+S9QawXc”,“remoteAddr”:“”,“app”:“cli”,“message”:“Memcache \OC\Memcache\APCu not available for local cache”,“level”:1,“time”:“2016-08-01T09:15:02+02:00”,“method”:“–”,“url”:“–”,“user”:“–”}
{“reqId”:“9N0/YfnIa4jM+S9QawXc”,“remoteAddr”:“”,“app”:“cli”,“message”:“Memcache \OC\Memcache\APCu not available for distributed cache”,“level”:1,“time”:“2016-08-01T09:15:02+02:00”,“method”:“–”,“url”:“–”,“user”:“–”}