Web Station zeigt 403-Fehler: Rechte und Webroot prüfen

Was der 403-Status bei Web Station eingrenzt

Der Statuscode grenzt den Fehler bereits deutlich ein: DNS-Auflösung, Netzwerkverbindung und der angesprochene HTTP- oder HTTPS-Port funktionieren zumindest so weit, dass ein Webserver antwortet. Ein Zeitüberschreitungsfehler oder eine abgelehnte Verbindung würde auf eine andere Ebene deuten. Auch ein PHP-Fehler ist nicht die erste Vermutung, weil PHP-Probleme häufiger eine Fehlerseite, einen HTTP-500-Status oder eine unvollständige Ausgabe verursachen.

Bei Synology Web Station liegen vier Prüfbereiche nahe beieinander, müssen aber getrennt werden:

• Das Webportal ordnet Hostname, Port und gegebenenfalls HTTPS einem Dokumentenstamm zu.
• Der Dokumentenstamm beziehungsweise Webroot bestimmt, aus welchem Ordner Inhalte ausgeliefert werden.
• Die Berechtigungen des gemeinsamen Ordners und seiner Unterordner bestimmen, ob der Webdienst Dateien lesen und Verzeichnisse durchlaufen darf.
• Eine Anwendung oder eine Regeldatei kann den Zugriff absichtlich verweigern, obwohl Portal und Dateirechte stimmen.

Ein 403 nach dem Aufruf eines Ordners kann außerdem schlicht bedeuten, dass dort keine gültige Startdatei liegt und die Anzeige von Verzeichnisinhalten deaktiviert ist. Das ist eine Schutzfunktion und noch kein Beleg für defekte DSM-Rechte.

Mit einer statischen Testdatei Portal und PHP voneinander trennen

Die schnellste risikoarme Gegenprobe ist eine harmlose HTML-Datei direkt im Dokumentenstamm des betroffenen Webportals. Lege dort über File Station eine Datei namens webstation-test.html mit einem kurzen Textinhalt an. Rufe diese Datei anschließend über exakt denselben Hostnamen, dasselbe Protokoll und denselben Port auf, die auch beim fehlerhaften Aufruf verwendet werden.

1. Öffne in Web Station die Portalübersicht und notiere den zugeordneten Dokumentenstamm. Die Bezeichnungen können sich je nach DSM- und Web-Station-Version unterscheiden; maßgeblich sind die Funktionsbereiche Webportal und Dokumentenstamm.
2. Kontrolliere in File Station, ob webstation-test.html wirklich unmittelbar in diesem Ordner liegt und nicht versehentlich in einem ähnlich benannten Unterordner.
3. Rufe die Datei mit vollständigem Dateinamen auf. Nutze dabei keinen alternativen NAS-Namen und keine andere Portnummer.
4. Entferne die Testdatei nach der Diagnose wieder.

Wird die Testdatei angezeigt, darf der Webserver den Webroot grundsätzlich lesen. Der Fehler liegt dann eher an der fehlenden Startdatei, an Regeln der Webanwendung oder an Rechten innerhalb eines Unterordners. Liefert bereits die Testdatei einen 403-Status, sind Portalzuordnung und Dateisystemrechte die nächsten Prüfpunkte. Erscheint stattdessen eine andere Webseite, verweist die Anfrage auf das falsche Portal oder wird durch eine vorgeschaltete Zuordnung anders behandelt.

Den tatsächlich verwendeten Webroot abgleichen

Web Station muss nicht zwangsläufig den allgemeinen gemeinsamen Ordner web verwenden. Ein benutzerdefiniertes Webportal kann einen eigenen Dokumentenstamm besitzen. Entscheidend ist daher nicht, wo die Projektdateien vermutlich liegen, sondern welcher Ordner dem aufgerufenen Hostnamen und Port in Web Station zugeordnet ist.

Vergleiche drei Angaben Zeichen für Zeichen: den Hostnamen im Browser, die Port- beziehungsweise HTTPS-Zuordnung des Portals und den hinterlegten Dokumentenstamm. Achte besonders auf mehrere Portale mit ähnlichen Namen, einen Aufruf über die IP-Adresse statt über den vorgesehenen Hostnamen und Projekte, die nach einem Verschieben weiterhin auf den alten Ordner zeigen.

Der Webroot muss die öffentlich auszuliefernden Dateien enthalten. Bei manchen Webanwendungen ist das nicht der oberste Projektordner, sondern ein darin liegender öffentlicher Unterordner. Eine pauschale Umstellung auf einen Unterordner namens public wäre dennoch falsch, solange die jeweilige Anwendung diese Struktur nicht ausdrücklich verwendet.

Lesen und Durchlaufen statt pauschaler Vollzugriff

Für statische Webseiten benötigt der von Web Station verwendete Systemdienst mindestens Leserechte auf die Dateien und Zugriff auf alle Ordner entlang des Pfades. Fehlt die Berechtigung bereits an einem übergeordneten Verzeichnis, hilft ein scheinbar korrektes Recht an der einzelnen HTML-Datei nicht. Auf Synology-Systemen ist dafür regelmäßig der interne Systembenutzer beziehungsweise Dienstkontext http relevant; welche internen Konten sichtbar sind, hängt von DSM-Version und Berechtigungsdialog ab.

Öffne in File Station die Eigenschaften des Dokumentenstamms und prüfe die Berechtigungen einschließlich der erweiterten Ansicht für Systembenutzer, sofern sie angeboten wird. Kontrolliere außerdem den gemeinsamen Ordner in der DSM-Systemsteuerung. Eine explizite Verweigerung hat Vorrang vor einer an anderer Stelle erteilten Erlaubnis. Das betrifft besonders ACL-Einträge, die vom Elternordner geerbt wurden.

• Der Webdienst braucht für normale Auslieferung Lesezugriff, aber nicht automatisch Schreib- oder Administrationsrechte.
• Jeder übergeordnete Ordner bis zum Dokumentenstamm muss für den Dienst zugänglich sein.
• Unterordner mit abweichender Vererbung müssen separat geprüft werden.
• Explizite Verweigerungen sollten nicht durch zusätzliche, großzügige Erlaubnisse überdeckt werden; kläre ihre Herkunft.
• Schreibrechte sind nur dort sinnvoll, wo die Webanwendung sie nachweislich benötigt, etwa für einen festgelegten Cache- oder Uploadordner.

Teste eine Änderung zunächst nur am betroffenen Dokumentenstamm und mit der statischen Testdatei. Rechte wie Vollzugriff für alle Benutzer beseitigen zwar möglicherweise das Symptom, öffnen aber unnötig große Bereiche und erschweren die spätere Ursachenanalyse.

Startdatei, Unterordner und Anwendungsregeln unterscheiden

Funktioniert der direkte Aufruf der Testdatei, während nur die Domain oder das Verzeichnis einen 403-Status liefert, prüfe als Nächstes die Startdatei. Im Dokumentenstamm muss eine vom Webserver berücksichtigte Datei wie index.html oder – bei passender PHP-Konfiguration – index.php vorhanden sein. Groß- und Kleinschreibung sind auf dem NAS relevant: Index.html und index.html können unterschiedliche Dateinamen sein.

Öffnet sich die Startdatei mit ausgeschriebenem Dateinamen, aber nicht beim Aufruf des Verzeichnisses, liegt das Problem wahrscheinlich an der Indexbehandlung oder an einer Webserverregel. Tritt der Fehler nur in einem Unterordner auf, vergleiche dessen ACLs und geerbte Rechte mit dem funktionierenden Webroot. Ein ausschließlich bei PHP-Dateien auftretender 403-Status lenkt die Prüfung auf das verwendete Webdienst-Backend, das PHP-Profil und anwendungsspezifische Regeln; die Dateirechte bleiben dennoch als Gegenprobe relevant.

Webanwendungen können Zugriffe außerdem anhand des Pfades, der IP-Adresse oder anderer Bedingungen verweigern. Prüfe deshalb Regeldateien und die Dokumentation der eingesetzten Anwendung, wenn statische Dateien im selben Ordner funktionieren. Ändere solche Regeln einzeln und sichere die ursprüngliche Datei, damit sich jede Änderung zurücknehmen lässt.

Die Antwort muss vom erwarteten Synology-Webportal stammen

Bei mehreren Portalen, einem Reverse Proxy oder einem vorgeschalteten Netzwerkdienst kann ein anderer Endpunkt den 403-Status erzeugen. Die lokale Gegenprobe trennt diese Ebene vom eigentlichen Webroot: Rufe das Portal im lokalen Netz mit dem dafür vorgesehenen Hostnamen auf. Bei namensbasierten Portalen ist ein bloßer Aufruf der NAS-IP keine gleichwertige Prüfung, weil der Hostname über die Portalzuordnung entscheidet.

Protokolle nutzen, bevor Web Station neu eingerichtet wird

Ein Neuinstallieren des Pakets verändert möglicherweise die Umgebung, erklärt aber keine falsche Portalzuordnung und korrigiert keine ACL im Projektordner. Prüfe vorher das Protokollzentrum von DSM sowie die in Web Station beziehungsweise beim gewählten Backend verfügbaren Protokollfunktionen. Die genaue Ablage und Benennung hängt von DSM, Web-Station-Version und eingesetztem HTTP-Backend ab.

Rufe die fehlerhafte Adresse einmal neu auf und gleiche den Zeitpunkt mit den Einträgen ab. Eine Meldung über verweigerten Dateizugriff lenkt auf Ordnerrechte oder einen gesperrten Pfad. Ein Hinweis auf fehlende Indexdateien passt zu einem Verzeichnisaufruf ohne gültige Startseite. Taucht der Aufruf im erwarteten Webdienstprotokoll gar nicht auf, sollte die Anfragezuordnung vor weiteren Dateirechtsänderungen geprüft werden.

Priorisierte Route bis zur Erfolgskontrolle

1. Sichere Screenshots der Portalzuordnung, des Dokumentenstamms und der vorhandenen ACLs. Notiere Hostname, Protokoll und Port.
2. Prüfe in Web Station, welcher Webroot genau diesem Portal zugeordnet ist.
3. Lege dort vorübergehend eine statische HTML-Datei an und rufe sie mit vollständigem Dateinamen auf.
4. Bei einem 403 der Testdatei kontrollierst du Lesezugriff, Ordnerdurchlauf und explizite Verweigerungen für den von Web Station verwendeten Dienstkontext.
5. Bei erfolgreicher Testdatei prüfst du Startdatei, Groß- und Kleinschreibung, Unterordnerrechte und Regeln der Webanwendung.
6. Bei abweichendem Verhalten zwischen lokalem und externem Aufruf untersuchst du Reverse Proxy oder vorgeschaltete Zugriffskontrollen, ohne den Webroot weiter zu öffnen.
7. Wiederhole den ursprünglichen Aufruf und kontrolliere zusätzlich eine bekannte statische Datei. Entferne die Testdatei und dokumentiere die tatsächlich geänderte Berechtigung.

Die Reparatur ist erst sauber abgeschlossen, wenn das vorgesehene Portal die richtige Startseite ausliefert, nicht benötigte Schreibrechte weiterhin fehlen und ein erneuter Aufruf keinen 403-Status mehr erzeugt. Bleibt die Sperre trotz korrekter Testdatei, Portalzuordnung und nachvollziehbarer ACL bestehen, sind die Webserver- und Anwendungsprotokolle die belastbarere Grundlage als weitere pauschale Rechteänderungen.