Ich habe ein Problem mit einer Ubuntu-Instanz (Ubuntu 20.04.1 LTS) und Apache2 (Apache/2.4.41 (Ubuntu)). Ein virtueller Host stellt einige HTML-Dateien und Dokumente von einer gemounteten CIFS-Freigabe bereit. Die CIFS-Freigabe funktioniert normal, die Dateien sind im Dateisystem korrekt.
Allerdings kann Apache keine korrekten Antworten für jeden Dateityp generieren, der im Binärformat bereitgestellt wird (wie Bilder, Word-Dokumente, PDFs usw.). Wenn ich beispielsweise ein Bild herunterlade, image.gifwird die Datei heruntergeladen und auf dem Client gespeichert. Wenn ich die Datei mit einem Texteditor auf dem Client öffne, sieht sie folgendermaßen aus:
grade, Keep-Alive
Last-Modified: Thu, 12 Nov 2020 10:01:47 GMT
ETag: "b6b-5b3e600040144"
Accept-Ranges: bytes
Content-Length: 2923
Keep-Alive: timeout=5, max=100
Content-Type: image/gif
GIF89av[binary-string starting...]
Ein Teil der Antwortheader befindet sich jetzt also in der heruntergeladenen Datei, was eigentlich nie passieren sollte. Ich erwarte, dass die heruntergeladene Datei mit beginnt GIF89avund so weiter. Das Bereitstellen textbasierter Dateien (wie HTML) ist kein Problem und funktioniert wie erwartet. Wenn ich jedoch dieselbe Datei in das Dokumentstammverzeichnis eines anderen virtuellen Hosts auf demselben Server kopiere, der die bereitgestellte CIFS-Freigabe nicht verwendet, wird die Datei korrekt bereitgestellt (ohne Antwortheader darin). Ich gehe also davon aus, dass es ein Problem mit dieser Kombination aus bereitgestellter CIFS-Freigabe und Apache2 gibt, das zu diesem Fehler führt.
Ich habe bereits verschiedene Möglichkeiten zum Mounten des Shares probiert - das ist meiner Meinung nach aber richtig, da die Dateien ohne Apache direkt auf dem Dateisystem laufen.
Die Montage des Schar erfolgt /etc/fstabwie folgt
//192.168.0.1/share$ /mnt/share cifs username=user,password=pass,dom=contoso.local 0 0
das ist so ziemlich die einfachste Möglichkeit, es zu tun. Ich habe mit Optionen wie Erfahrungen gemacht iocharset=utf8, verschiedene Versionen ( vers=1.0oder vers=3.1) ausprobiert, aber das hat nichts geändert. Die Apache-Konfiguration ist auch die grundlegende, die mit Ubuntu 20 ausgeliefert wird, da wurde nichts Besonderes hinzugefügt oder geändert. Ich habe ein bisschen Erfahrung mit den MIME-Typen, aber Apache sollte in der Lage sein, sofort ein Image bereitzustellen.
Zusätzlich habe ich zum Testen einen PHP-Webserver ( php -S 192.168.0.2:8000) in diesem Verzeichnis gestartet - der liefert korrekte Binärdateien zurück, was mich ziemlich sicher macht, dass der Fehler irgendwo bei Apache liegt.
Was führt zu diesen beschädigten Antworten von Apache und wie kann ich das beheben?
Antwort1
Ich habe das gleiche Problem. Es scheint, dass dieses Problem erst kürzlich aufgetreten ist und möglicherweise mit der Kernel-Version 20.04 zusammenhängt. Ich sehe das Problem auch bei reinen Textdateien. Konnten Sie eine Lösung/einen Workaround finden? (Tut mir leid, ich habe nicht die nötige Reputation, um einen Kommentar zu posten.)
Edit: Ich konnte hier einen Fehlerbericht finden: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900821 Das Deaktivieren von EnableMMAP in der Apache-Konfiguration hat bei mir funktioniert:
EnableMMAP off
Antwort2
Fügen Sie in „/etc/apache2/apache2.conf“ Folgendes hinzu:
EnableSendfile Off
EnableMMAP off
Das hat mir das Leben gerettet~
Antwort3
Die zweite Antwort mit deaktiviertem EnableMMAP und deaktiviertem Enable Sendfile scheint das Problem für mich behoben zu haben.
Diese Direktive steuert, ob httpd die Sendfile-Unterstützung des Kernels verwenden darf, um Dateiinhalte an den Client zu übertragen. Wenn für die Bearbeitung einer Anfrage kein Zugriff auf die Daten in einer Datei erforderlich ist (z. B. bei der Übermittlung einer statischen Datei), verwendet Apache httpd standardmäßig Sendfile, um den Dateiinhalt zu übermitteln, ohne die Datei jemals zu lesen, sofern das Betriebssystem dies unterstützt.
Durch das Ausschalten wird die Möglichkeit ausgeschlossen, dass durch unterschiedliche oder nicht funktionierende Funktionen im Sendfile-Aufruf des Kernels Probleme entstehen.
Dies war ein Problem für RHEL 8 4.18.0-305.3.1.el8_4.x86_64