OwnCloud mit nginx und MariaDB auf Debian Jessie (2)
16. November 2017 um 19:38 Uhr von Atari-Frosch
Es ist schon ein paar Monate her, daß ich OwnCloud auf meinem Server installiert und darüber geschrieben hatte. Kurz nach der Veröffentlichung des Blogartikels meldete mir der zweite Nutzer, er könne nichts hochladen, da sei kein Speicherplatz mehr frei. Bei meinen Tests vorher hatte das alles einwandfrei funktioniert.
Nun war da erst mal die Luftröhrenentzündung und noch so einiges andere Zeug, was mich alles daran hinderte, mir die Sache nochmal anzusehen. Vorgestern und heute war ich dann nochmal dran. Beim ersten Test mußte ich die Erfahrung des Nutzers bestätigen: Kein Speicherplatz, 0 Bytes, und deshalb kein Upload möglich. Sagen wir's so: Meine Lernkurve war mal wieder sehr flach …
Zunächst einmal bemühte ich natürlich Tante Google. Die Fehlermeldung findet sich dort dutzende Male, wenn auch allesamt für Versionen unterhalb von 10; beginnend aber immerhin mit der Version 5. Es gab und gibt offenbar viele Möglichkeiten, diese Fehlermeldung auszulösen. Meine war nicht dabei.
Schließlich landete ich im Bugtracker von OwnCloud bei Fehler #18886 "Not enough storage available" / Upload limit of 0 byte on Strato und hängte mich da mit meiner Fehlerbeschreibung an. Sinngemäß:
Ich fürchte, ich muß hier noch einen hinzufügen. Nicht Strato, sondern ein dedizierter Server unter Debian Jessie, mit OwnCloud 10.0.2. Gleiches Problem, wie's scheint. Direkt nach der Installation funktionierte alles, genutzt wurde nur das Webinterface. Kurz darauf waren Uploads über das Webinterface nicht mehr möglich, es sagt: „Nicht genug freier Speicherplatz, Du willst 267 kB hochladen, aber es sind nur 0 Bytes frei.“ Tatsächlich verfügbar sind etwa 2 TB. Die Inodes sind nur zu 1 % belegt (xfs). Die Dateirechte müßten stimmen. Im Logfile findet sich keine Warnung oder Fehlermeldung. Ich änderte die Standard-Quota auf 10 GB, aber keine Änderung.
Auf Hinweise des Entwicklers Vincent Petry testete ich erstmal, was PHP als freien Speicherplatz auf dem Medium und im Dateiverzeichnis sieht (beides auf derselben Partition). Das Ergebnis war positiv; es wurden die ca. 2 TB an freiem Speicher gesehen. Dann meinte er, dann könne er sich auch nicht erklären, warum die Weboberfläche mir 0 Bytes anzeigt.
Ich hatte dazwischen das Problem auch auf GNUsocial und Google+ mal ein bißchen gestreut. Benedikt Geißler gab mir einen Hinweis, der mir zunächst weiterhalf: nämlich, mal in das error.log des Webservers zu schauen, was der dazu meint. Da fand sich tatsächlich eine dazu passende Fehlermeldung:
2017/11/14 17:21:50 [error] 19589#0: *1361 access forbidden by rule, client: 37.201.xxx.xxx, server: wolke.atari-frosch.de, request: "GET /index.php/apps/files/ajax/getstoragestats.php?dir=%2F HTTP/1.1", host: "wolke.atari-frosch.de"
Vincent meinte darauf (Übersetzung von mir):
Hmm, wenn getstoragestats "/" benutzt, dann meint er den Pfad im data-Verzeichnis, nicht vom echten root aus.
Dann nannte er mir eine zusätzliche PHP-Zeile, die ich an einer bestimmten Stelle einer bestimmten PHP-Datei von OwnCloud eintragen sollte. Und ab da wurde es für mich erstmal konfus. Denn: Die genannte Datei war nicht auffindbar. Sie steht nicht im genannten Pfad; mehr noch: Der genannte Pfad existiert überhaupt nicht. An dem Punkt gab ich erstmal auf. Das war vorgestern.
Heute ging ich dann nochmal dran und lernte: Der Pfad im GitHub stimmt offenbar nicht mit dem Pfad im Programmpaket überein. Die gesuchte Datei Local.php liegt also nicht unter $owncloud/core/blob/v10.0.2/lib/private/Files/Storage, sondern unter $owncloud/lib/private/Files/Storage – muß man wissen. Das war offenbar nicht einmal dem Entwickler bewußt.
Aber der Reihe nach. Zunächst ging ich davon aus, daß ich die Datei deshalb nicht habe, weil ich das Update auf die aktuelle Version 10.0.3 noch nicht durchgeführt hatte. Also wollte ich das erstmal tun. Das Ergebnis dieses Versuchs war, daß mir das Programm occ eine Fehlermeldung vorsetzte, die was von einer nicht abgefangenen Exception erzählte. Ja danke auch.
Dann hoffte ich darauf, daß ich dieser 10.0.3 erzählen könne, sie sei eine Neuinstallation, indem ich die Basis-Konfigurationsdatei löschte (sie stand zusammen mit der gesicherten Version 10.0.2 natürlich nochmal woanders auf dem Server). Das klappte dann aber auch erstmal nicht so ganz. Zwar bekam ich den Installationsbildschirm auf dem Webinterface angezeigt, aber die Installationsroutine stellte fest, daß es den gewünschten Admin-Usernamen schon gibt. Im nächsten Schritt entsorgte ich also die Datenbank – da die Instanz noch nicht aktiv genutzt worden war, war das ja kein Problem. Daraufhin lief die Installationsroutine durch.
Die gesuchte Datei fand ich aber immer noch nicht, und mittlerweile hatte Vincent ja auch mitgeteilt, daß es die auch in der 10.0.2 geben muß. Es war dann eher so eine Spontan-Idee, den Pfad mal ein bißchen woanders zu suchen, und siehe da, ich fand das Verzeichnis lib beim Durchblättern parallel zu core – statt darunter, wie im GitHub-Pfad. Damit konnte ich dann endlich die zusätzliche Zeile dort eintragen. Natürlich stellte ich den Loglevel auch, wie angegeben, auf Debug um.
Das Ergebnis nach einem weiteren Upload-Versuch war enttäuschend. 0 Bytes. Keine Eintragung im OwnCloud-eigenen Log, auch nicht das, was die zusätzlich eingefügte Zeile hätte melden sollen. Selbes Ergebnis nach einem Reload von nginx und einem Neustart von php5-fpm.
Und dann kam ich auf die Idee, nochmal ins error.log von nginx zu schauen:
2017/11/16 16:52:26 [error] 12925#0: *28985 access forbidden by rule, client: 37.201.xxx.xxx, server: wolke.atari-frosch.de, request: "GET /index.php/apps/files/ajax/getstoragestats.php?dir=%2FPhotos HTTP/1.1", host: "wolke.atari-frosch.de"
Hier stach mir nun der Anfang des Eintrags ins Auge, auf den ich vorher gar nicht geachtet hatte (und Vincent offenbar auch nicht): access forbidden by rule. Der Zugang wurde durch eine Regel verboten. Und zwar auf Webserver-Ebene!
Moment. Da war was gewesen.
Genau. Ich hatte zuletzt nochmal die Konfigurationsdatei zum Host editiert, um https zu erzwingen, nachdem das Let's-Encrypt-Zertifikat da war. Dabei war mir aufgefallen, daß diese Datei eine Anweisung nicht enthält, die ich sonst in allen Host-Konfigurationen mit dynamischem Gedöns stehen habe. Nämlich diese hier:
include global/restrictions.conf;
In dieser Datei steht unter anderem folgende Anweisung an den Webserver:
# Deny access to any files with a .php extension in the uploads directory
# Works in sub-directory installs and also in multisite network
# Keep logging the requests to parse later (or to pass to firewall utilities such as fail2ban)
location ~* /(?:uploads|files)/.*\.php$ {
deny all;
Also: Der Webserver darf in Upload-Verzeichnissen nicht auf PHP-Dateien zugreifen. Offenbar gilt das auch für PHP-Dateien, die von außerhalb des Upload-Verzeichnisses in dieses hineingreifen wollen, denn die Anweisung für die Abfrage des Speicherplatzes steht selbst nicht in einer PHP-Datei innerhalb des Upload-Bereichs. Wenn das aber nicht geht, dann kann OwnCloud den zur Verfügung stehenden Speicherplatz nicht ermitteln und sagt halt einfach: Da ist keiner.
Das paßt auch zu der Erkenntnis, die ich beim Suchen so nebenbei gewonnen hatte: OwnCloud behauptet auch dann 0 Bytes, wenn es eigentlich gar nicht weiß, wieviel Speicher verfügbar ist. 0 Bytes kann also heißen, es ist tatsächlich nichts mehr frei, oder der Speicherplatz ist unbekannt bzw. konnte nicht ermittelt werden. Ob das Problem das eine oder das andere ist, verrät es einem aber nicht. Das wäre wohl wieder zu einfach.
Also: Zeile rausgelöscht, nginx einen reload geschickt – und OwnCloud funktioniert einwandfrei.
Ja, das war mal wieder das mit der langen Leitung. 😉
17. November 2017 at 0:16
Der Zugriff auf /index.php/apps/files/ajax/getstoragestats.php wird vermutlich über andere Regeln in nginx auf /apps/files/ajax/getstoragestats.php umgeleitet und ist kein Request auf index.php, welches außerhalb files und uploads liegen würde. Da getstoragestats.php innerhalb von files liegt wird dann der Zugriff verwehrt.
Nahelegen würde ich eventuell auf Dauer einen Wechsel auf NextCloud. Ich glaube ownCloud hat einen Großteil seiner Triebkraft verloren, aber vielleicht liege ich mit der Einschätzung falsch. Zum NextCloud-Fork ist, soweit ich verstehe, der Großteil der Entwickler gewechselt. Das Update funktionierte bei mir recht problemlos.
Das Ausschließen der PHP-Dateien ist leider noch ein dämliches Relikt von Uralt-Webanwendungen. Die meisten modernen Anwendungen, auch in PHP, nutzen ja einen eigenen Router um Requests Resourcen zuzuordnen. Bei ownCloud/NextCloud bedeutet das bspw. auch, dass keine .htaccess-Dateien synchronisiert werden, wenn man nicht den Quelltext der Clouds patched. Ärgerlich, wenn man oft Webprojekte drin hat.
Hach, Technik, vollkommen ist sie nie.
3. April 2023 at 1:43
hallo ich das gleiche Problem mit owncloud 10.12 kein speicherplatz verfügbar obwohl 1 TB da ist
ich nutze apache2 und nicht nginx kannst du mir helfen welche datei muss ich editieren??
Danke im voraus
3. April 2023 at 18:04
Hallo Giovanni, uff, mit Apache hab ich schon länger nix mehr zu tun gehabt. Die Art der Lösung bei mir war denn doch sehr nginx-spezifisch.
Hast Du abgeglichen, ob die Fehlermeldung im error.log gleich ist? Es muß ja nicht zwingend dasselbe Problem sein; die Fehlermeldung kann, wie ich damals beschrieben hatte, auf unterschiedliche Weise ausgelöst werden.
Du kannst mir die Infos – Logfile-Auszüge oder eventuell sogar Deine Apache-Konfiguration – auch per Mail schicken, an <frosch@atari-frosch.de>, falls Du die hier nicht reinkippen möchtest.