Hinweis: Der beschriebene Fehler kann durch unterschiedliche Ursachen ausgelöst werden. Mein Fall war relativ exotisch und betrifft wohl nur wenige Leute oder Konfigurationen. Wenn Sie aber schon alle anderen, einschlägig dokumentierten Lösungen erfolglos durchprobiert haben könnte dies hier einen Versuch wert sein.
Witzigerweise war genau das nämlich bei mir der Fall: Alle anderen Stricke waren gerissen und dies hier ein glücklicher Zufallsfund.
Ach – noch was: Falls Sie jetzt auf der Suche nach der schellen Lösung sind ohne viel Geschwafel dann springen Sie einfach direkt runter zur Lösung. Viel Erfolg!

Bei mir läuft nextcloud auf nginx, in erster Linie zum automatischen Backup der Photos auf den Handies der Familie. Und um häufig benötigte Dokumente an einer zentralen Stelle für alle verfügbar zu haben. Nachdem die „zerebralen Wachstumsschmerzen“ vom Begreifen und Anpassen verschiedener Tutorials einmal überstanden waren hatte ich letztlich eine nette, schnelle und coole home-cloud mit der ich bis heute mehr als zufrieden bin.

Hin und wieder gibt es natürlich Updates für so ziemlich jede der involvierten Komponenten. Und während sich der Fedora Server und nginx als eher einfache und unproblematische „no-brainer“ in Sachen Updates erweisen, herrscht bei mir hinsichtlich nextcloud immer eine gewisse unbequeme Unsicherheit vor, ob das ganze Geraffel nach einem update nich genauso problemlos läuft wie davor.

Vor kurzem stand wieder einmal ein Release-Update an und als ich danach (nach längerer Zeit und eher zufällig) einen Blick auf nextcloud’s eingebaute Sicherheits- und Einrichtungsüberprüfung warf, fiel mir auf dass dort ein „falsch konfigurierter header“ angemäkelt wurde:

bildschirmfoto der warnung zu falsch konfiguriertem header aus der sicherheitsüberprüfung von nextcloud
Sicherheits-Scan in nextcloud’s Einstellungen > Verwaltung > Übersicht

Als Freizeit-Web-Administrator hat man nur selten direkt vor Augen, in welcher .conf Datei von nginx man jetzt aktiv werden muss und wie der Eintrag genau auszusehen hat, damit die Warnung verschwindet. Dank des world wide web ist eine entsprechende Anleitung aber meist nur ein paar Klicks entfernt.

Fehler Nummer 1

Mein erster Fehler war, dass ich anstatt „wie-man-es-richtig-macht“ die offizielle Dokumentation von nextcloud zu Rate zu ziehen, die Abkürzung für faule Leute nahm: Ein paar Begriffe in den webbrowser geklatscht und ab dafür. Hossa – und schon sprudelte es Lösungen. Die meisten davon aus den Foren von nextcloud.

Also los: Flugs die entsprechende .conf Datei im Texteditor laden und achtlos per Kopieren-Einfügen die Zeile reinsemmeln, die irgendwer irgendwo irgendwann mal veröffentlicht hatte. Muss reichen. Läuft bei mir.
Speichern, beenden, nginx neu starten. Die Sicherheitsüberprüfung im Browser laden.

Aber es funktionierte nicht. Mist.
Also nochmal – alles doppelt und dreifach prüfen und wiederholen und „auf Nummer sicher“ gehen und ALLES von nginx bis zum Fedora Server einmal durchstarten… aber nö.
Die Warnung war immer noch da.

Fehler Nummer 2

Mein nächster Schritt war zu überlegen, ob denn vielleicht einfach die Meldung falsch war. Denn, hey, man weiss ja nie: Wer weiss schon, was irgend so ein Programm prüft… und vielleicht sagen die nur der Header fehlt obwohl er in Wirklichkeit da ist? Es kann ja durchaus sein, dass die da zwar gnadenlos perfekten Code für ein fantastisches Produkt bauen, aber eben halt bei einfachen Sachen versagen? Nun gut – Zeit einmal wieder alles anzuzweifeln und die Entwicklerwerkzeuge meines Webbrowsers zu konsultieren. Mal sehen ob… ich glaub’s ja nicht! Da isser doch:

bildschirmfoto der entwicklerwerkzeuge con chromium die den header scheinbar korrekt anzeigt
Was zur Hölle ist das Problem? Der header is doch da! DA! DAA!

Na bitte! Wusst‘ ich’s doch: Da werkeln nur Pfeifen und ich bin ein Genie! Super. Prima. Aber… wie behebe ich das denn?

Nun kann es ja wohl nicht sein, dass ich der Einzige auf Gottes Erden bin, der dieses Problem hat. Nein, es gibt immer jemand anders der es auch hat. Hoffentlich hat dieser jemand es mittlerweile gelöst. Zeit sich zu konzentrieren und das Thema vielleicht doch mal ernst zu nehmen. Tief durchatmen und nochmals eintauchen in die Welt der Foren um die Diskussionen gründlich und vollständig durchzuarbeiten. Hoffentlich muss ich nicht den ganzen Weg bis zum bitteren Ende gehen… also letztlich alle Karten auf stackoverflow setzen.

Wie sich herausstellte herrschte wohl über vergangene nextcloud Versionen hinweg einige Verwirrung bezüglich dieses headers. Irgendwann, so behauptete jemand, wurde der header mal „von PHP“ geliefert – was immer das bedeuten soll (vermutlich bezogen auf den PHP-Code von nextcloud). Andere meinten, die betreffende Zeile wäre über verschiedene conf-Datei gewandert und letztlich dann völlig aus der Lieferung verschwunden womit es jetzt den Benutzern obliegen würde, sie irgendwo händisch reinzuschreiben. Oder so. Und dann gab es da noch das Gerücht, dass wenn die Zeile mehr als einmal innerhalb des config-Dateiengewusels vorhanden war, es sein könne, dass sie tatsächlich einfach nicht mehr funktionierte. Die genaue Entstehung und der finale status quo waren also völlig unklar aufgrund vieler widersprüchlicher Foreneinträge und Ansichten.

Bis hierhin war aber eine Sache klar:
Die Leute hatten diese Zeile in ihrer Konfiguration aber irgendwie ging es nicht. Kommt mir bekannt vor. Für jede „Bei mir klappt das“-Aussage in den Foren gab es vielfache Antworten a la „Ich hab‘ die Zeile HAARGENAU von Dir kopiert und es geht NICHT!“.

Hier ein paar Lesebeispiele:

Die „ich-glaub’s-ja-nicht“ Lösung

Irgendwann hatte ich mich bei der Lektüre einer Diskussion bis zum Ende vorgekämpft als ich über einen einzelnen, kurzen Kommentar stolperte. Den augenöffnenden, maulsperrenden, #facepalm, #headdesk Moment der Erleuchtung:

https://help.nextcloud.com/t/x-frame-options-sameorigin-nc-on-nginx-keeps-warning-me/1553/15

Bildschirmfoto des Kommentars im nextcloud Forum der darauf hinweist dass typografische Anführungszeichen durch echte Anführungszeichen zu ersetzen sind
Nur weil etwas wie ein Anführungszeichen aussieht, muss es noch lange keins sein.

Äh, wie? Moment – echt jetzt?
Ja. Und genau dasselbe war mir passiert!
Okay: Terminal öffnen, die entsprechende nginx config-Datei in nano laden und die typografischen Anführungszeichen durch „normale“ Anführungszeichen ersetzen. Speichern, Schließen, nginx durchstarten, die Admin-Einstellungsseite im Browser laden und ungeduldig auf das Ergebnis der Sicherheitsüberprüfung warten…

Bildschirmfoto der erfolgreichen Sicherheitsüberprüfung in nextcloud
Puuuh. Endlich.

Tschüss Warnung!

VarIr – Du hast mir (und vielen anderen wohl auch) den Tag gerettet! Vielen Dank für das Teilen dieser Information!

Und die Moral? Pass‘ bloß auf wenn Du irgendwas aus einem Browserfenster kopierst und in einen Code-Editor einfügst, selbst wenn der Text so aussieht als verwendet er code Formatierung!

Ich könnte es jetzt auf die nextcloud Leute schieben, die Verfasser des Forum-CSS oder die Autoren der Forenbeiträge. Aber letztlich muss ich mir an die eigene Nase fassen: Ich hätte das sofort beim Einfügen in den Editor sehen müssen. Darin verwende ich nämlich absichtlich eine Schriftart, die diese Abweichungen darstellt – auch wenn sie auf den ersten Blick vielleicht nicht so offensichtlich sind.

Die Lehren daraus (mal wieder)

Was meinen ersten Fehler angeht: Ich hätte die Zeile aus der offiziellen „Beispiel-Konfigurationsdatei“ abtippen sollen, die absichtlich mit viel Aufwand und Sorgfalt von jemanden speziell für Administratoren eines nginx-Servers (also mich, ich Depp) zur Verfügung gestellt wurde. Oder zumindest von dort kopieren.

Zum Fehler 2: Anstatt ausschließlich auf die Entwicklerwerkzeuge von Chromium zu vertrauen, hätte ich mindestens eine Gegenprobe mit einem anderen Programm machen sollen. Beispielsweise kann man wie folgt (alle SSL-Fehler ignorierend) die Header auch mit curl überprüfen:

curl -I -k https://DieNextcloudURL/login

Daraufhin erscheint eine Liste der vom Server gesendeten header und deren Inhalte. Der „falsch-angeführte“ SAMEORIGIN header taucht in der curl-Ausgabe im Terminal wie folgt auf:

Bildschirmfoto der curl Ausgabe zu den headern des nextcloud servers. Auch hier werden typografische Anführungszeichen ausgegeben, sind aber nur schwer als solche zu erkennen
Auch mit curl ist das Problem nicht auf Anhieb zu erkennen.

Wenn Sie jetzt denken, dass das schon der Weisheit letzter Schluss war dann halten Sie sich fest. Hier das, was die Entwicklerwerkzeuge von Firefox dazu sagen:

Bildschirmfoto der Entwicklerwerkzeuge von Firefox mit den headern des nextcloud-Servers. Hier sind deutlich Steuerzeichen vor und hinter dem headernamen zu erkennen
Okay. Also DAS nenne ich mal eindeutig!

Das Gute an der Geschichte: Nur wenige Tage später konnte ich genau diese Art von Ausrutscher in einem Groovy-Skript eines Kollegen quasi auf Anhieb erkennen: Syntaxfehler – obwohl eigentlich alles korrekt war. Unzulässiges Zeichen an genau der Stelle wo sich das „Anführungszeichen“ befand?
Tja, das kam mir irgendwie schmerzlich bekannt vor. Man lernt halt nie aus.