Synology DIskStation DSM 7

Synology Web Station Timeout erhöhen (DSM7)

Webserver haben für verschiedene Anfragen und Prozesse Timeouts konfiguriert. Das verhindert, dass Clients, wie der Browser, im Fehlerfall (wenn die Serveranwendung hängt, feststeckt, abstürzt oder sonst etwas mit dem Server passiert, während der Client auf eine Antwort wartet) nicht endlos auf eine Antwort warten und blockieren. Manchmal dauert es aber länger bis eine Anfrage bearbeitet wurde oder ein Prozess abgeschlossen wurde. Dauert das länger als das konfigurierte Timeout zeigt der Client eine Fehlermeldung, der Prozess am Server läuft aber weiter, das kann zu inkonsistenten Datenständen, endlosen Wiederholungen von Aufgaben und anderen Problemen führen. Im besten Fall ist es einfach nur lästig. Diese Probleme löst man, indem man das Timeout einfach erhöht. In DSM ist vieles, was die Web Station, bzw. die Webserver, betrifft nicht einfach und Timeouts gehören dazu. In diesem Artikel beschreibe ich, wie Ihr die Timeouts je nach Situation erhöhen könnt.

Die Webserver am Synology NAS

Timeouts begegnet man auf Synology Geräten, wenn man dessen Webserver (Nginx und/oder Apache) nutzt um Webanwendungen (z.B. WordPress, Nextcloud) bereitzustellen. Vorgänge die Timeouts auslösen sind Installationsroutinen, Updates oder aber Uploads von besonders großen Dateien. Bevor ich zur Lösungsanleitung komme noch eine kurze Erklärung zum Synology NAS als Webserver.

Auch wenn man die Web Station bzw. die Webserver-Pakete gar nicht installiert läuft auf dem NAS bereits ein Webserver. Dieser stellt DSM und die Synology-Anwendungen bereit. Seit DSM 6 ist das Nginx. Installiert ihr die Web Station um eigene Webseiten oder Webanwendungen bereitzustellen habt Ihr die Wahl ob ihr ebenfalls Nginx verwendet, oder ob Ihr lieber den guten alten Apache wollt. Entscheidet ihr euch für letzteres läuft der Apache aber hinter dem Nginx, der als Proxy fungiert. Das gilt es dann ich Problemfällen zu berücksichtigen, da beide Ihre eigene Konfiguration haben.

Timeout erhöhen

Unter DSM 6 war das Timeout schnell erhöht, für Nginx musste einfach die Proxy.conf editiert werden und für den Apache einfach eine config-Datei erstellt werden. Unter DSM 7 gestaltet sich die Angelegenheit nicht schwieriger allerdings kniffliger. Das Timeout kann in der Proxy.conf nicht gesetzt werden, ein nginx -t (Test ob die Nginx-Konfiguration keine Fehler aufweist) weißt darauf hin dass das Timeout bereits an anderer Stelle gesetzt wurde. Da denkt man sich doch, gut gemacht Synology, ein Problem weniger um das man sich kümmern muss.
Tja, das gilt aber nur solange man keinen virtuellen Host konfiguriert, denn für diese gilt das gesetzte Timeout nicht. Die Proxy.conf wird in jeder anderen Konfigurationsdatei und auch in den Konfigurationsdateien für die virtuellen Hosts eingebunden, daher war die Änderung allgemein gültig. nginx -t weist nur auf das Duplikat in der Proxy.conf hin, aber nicht auf die ursprüngliche Stelle. Die ist aber schnell gefunden, nämlich in der nginx.conf. Das ganze sieht nach einer schnellen Lösung aus: raus mit dem Timeout aus der nginx.conf und rein damit in die Proxy.conf. nginx -t gibt seinen Segen und schon kann Nginx neu gestartet werden. Ein erneutes nginx -t offenbart dann aber ein Problem. Das Timeout steht wieder in der nginx.conf. Die wird nämlich beim Neustart des Nginx neu erstellt. Der Ursprung der Konfiguration ist ein anderer. Sucht man etwas weiter, findet man schnell die Konfigurationsdatei für die virtuellen Hosts, aber der Versuch dort, anstelle der Proxy.conf hinzuzufügen ist nur von kurzer Dauer, denn nach einem Neustart ist auch diese Datei wieder im Originalzustand.

Das liegt daran, dass Synology die eigentlichen Konfigurationsdateien für Nginx und Apache aus separaten Quelldateien immer neu generieren. Das hat wohl damit zu tun, wie Synology die Webserver-Konfiguration hinter dem grafischen Benutzerinterface der Web Station versteckt. Synology stellt sicher, dass der Betrieb von DSM und den Paketen so wenig wie möglich gestört werden kann. Unerfahrene Nutzer sollen so wenig wie möglich kaputt machen können. Für uns erfahrene Nutzer ist es dadurch aber oftmals schwierig Änderungen vorzunehmen.

Der Ursprung – und somit der Ort für eine persistierende Änderung – ist ein anderer, bzw. sind es mehrere Orte. Denn abhängig davon ob ihr Apache oder Nginx verwendet, müssen andere Anpassungen vorgenommen werden.

Mit DSM 7.1 und dem enthaltenen Update für die Web Station scheint man das Problem endlich in der GUI regeln zu wollen, allerdings ist das nur zur Hälfte gelungen. Mehr dazu weiter unten.

Nginx als Webserver

Nutzt ihr den Nginx als Webserver, habt ihr schon das längere Timeout von 3600 Sekunden. Das gilt aber, wie bereits erwähnt nicht, wenn Ihr einen vHost konfiguriert. Damit auch Anwendungen die über vHosts aufgerufen werden ein längeres Timeout haben, müsst ihr folgende Anpassungen vornehmen:

  1. Verbindet euch per SSH (z.B. PuTTY) mit eurem NAS.
  2. Führt die Änderungen als root durch. Gebt dazu sudo -i (Enter), dann das Passwort und erneut (Enter) ein, dann werden alle Befehle als root ausgeführt. Alternativ könnt ihr jeden Befehl mit sudo starten und das Passwort eingeben, wenn ihr dazu aufgefordert werdet.
  3. Öffnet die Datei /etc/nginx/fastcgi.conf im Editor:
vi /etc/nginx/fastcgi.conf
Timeout erhöhen
Timeout erhöhen
  1. Fügt am Ende der Datei die Zeile fastcgi_read_timeout 3600s; ein.
  2. Speichert und schließt die Datei.
  3. Testet zuerst die Nginx-Konfiguration, startet dann den Nginx neu, wenn der Test positiv ausfällt und testet die Konfig danach erneut:
nginx -t
synosystemctl restart nginx
nginx -t

Apache als Webserver

Nutzt ihr den Apache fungiert Nginx immer noch als Proxy und auch hier gilt das hohe Timeout für virtuelle Hosts nicht. Um dieses anzupassen ist folgendes notwendig:

  1. Verbindet euch per SSH (z.B. PuTTY) mit eurem NAS.
  2. Führt die Änderungen als root durch. Gebt dazu sudo -i (Enter), dann das Passwort und erneut (Enter) ein, dann werden alle Befehle als root ausgeführt. Alternativ könnt ihr jeden Befehl mit sudo starten und das Passwort eingeben, wenn ihr dazu aufgefordert werdet.
  3. Öffnet die Datei /var/packages/WebStation/target/misc/VirtualHost-nginx.mustache im Editor.
vi /var/packages/WebStation/target/misc/VirtualHost-nginx.mustache
  1. Fügt die Zeile proxy_read_timeout 3600s; im Block für Apache 2.2 bzw. Apache 2.4 unter include proxy.conf; ein. Führt die Änderung in jenem Block durch, der zur verwendeten Apache-Version passt. Ihr könnt die Zeile aber auch in beiden Blöcken einfügen.
  2. Speichert und schließt die Datei.
  3. Testet zuerst die Nginx-Konfiguration, startet dann den Nginx neu, wenn der Test positiv ausfällt und testet die Konfig danach erneut:
nginx -t
synosystemctl restart nginx
nginx -t
Proxy-Timeout für vHosts erhöhen
Proxy-Timeout für vHosts erhöhen

Das Timeout für den Proxy ist jetzt auch unter Verwendung von virtuellen Hosts erhöht. Jetzt kann es aber immer noch am Apache zum Timeout kommen. Das lässt sich, wie auch schon unter DSM 6 beheben:

  1. Erstellt (als root) die Datei /usr/local/etc/apache2X/sites-enabled/user.conf
vi /usr/local/etc/apache2X/sites-enabled/user.conf
  1. Fügt die Zeile TimeOut 3600 ein.
  2. Speichert und schließt die Datei.
  3. Startet den Apache neu.

Jetzt kommt es auch bei längeren Vorgängen zu keinen Timeouts mehr. Egal ob Ihr virtuelle Hosts/Reverse Proxys verwendet oder nicht und egal welchen Webserver ihr als HTTP-Backend-Server auswählt.

Nachtrag Timeout in der GUI

Mit 7.2 scheint das Timeout endlich über die GUI gesetzt werden zu können.

Setzt man unter DSM 7.1 das Timeout in der GUI bringt das leider nicht viel. Nach 60 Sekunden ist weiterhin Schluss. Ich habe den Hinweis erhalten, man müsse im PHP-Profil unter Kern die Variable default_socket_timeout umstellen (dort ist tatsächlich 60 eingetragen). Bringt aber auch nichts, zumindest nicht unter DSM 7.1. Ich habe dann dem Synology Support geschrieben. Leider hat es eine Weile gedauert bis ich klar machen konnte was mein Problem bzw. mein Anliegen ist. Als ich unter DSM 7 eine ähnliche Frage gestellt hatte habe ich prompt eine Antwort mit der oben stehenden Lösung bekommen. Diesmal hat es etwas länger gedauert. Die Antwort war wieder das editieren trotz Variablen in der GUI, noch dazu hat die mir zugesandte Lösung auch nicht funktioniert.
Was ist da also los? Hat Synology tatsächlich vergessen, dass Sie auch Apache als Backendserver anbieten? Oder hat sich einfach ein Fehler eingeschlichen? Bei den vielen Templates und Schnipsel, aus denen sich die eigentlichen Konfigurationsdateien zusammensetzen, wäre das nicht verwunderlich. Oder ist das ganze gar Absicht? Die Frage ist, wer soll da noch durchblicken, zumal in der GUI ja gar nicht ersichtlich ist wofür die Timeouts gelten.
Der Support war so nett mir einen Feature-Request zu erstellen. Leider bekommt man keinerlei Rückmeldung ob ein Feature-Request berücksichtigt wird oder nicht. Mein Tipp, erstellt ebenfalls einen Feature-Request, je mehr desto eher wird ein Feature berücksichtigt.

Möchtet Ihr noch detailliertere Schritt-Für-Schritt-Anleitungen für euer Synology NAS, mit viel mehr Hintergrundinformationen, Tipps und Tricks? Dann holt euch mein Wissen als als umfassendes Praxis-Handbuch. Mehr Infos findet ihr in keinem Buch zu Synology und alles in der von mir gewohnten Qualität.

Die dritte Auflage enthält Aktualisierungen zu DSM 7.1 und den Updates von WebStation, Surveillance Station und Synology Photos.

Das Buch direkt beim Verlag

Das Buch auf Amazon

8 thoughts on “Synology Web Station Timeout erhöhen (DSM7)

  1. Hallo Andreas, herzlichen Dank für die Erläuterungen und Workarounds im Blog und im Buch!
    Ich habe auf einer neuen DS220+ (out of the box, DSM 7.1-42661 Update 4) Nextcloud gemäß der Anleitung https://www.heise.de/ratgeber/Nextcloud-als-Docker-Instanz-im-NAS-einrichten-4199681.html installiert. Manches war hakelig, doch es läuft nun schon erwartungsgemäß – bis auf das Timeout-Problem, weil die Anmeldung im Webinterface zu lange dauert. Das betrifft einen User mit > 12.000 Dateien und > 16 GByte Daten. User mit wenig Daten sind beim Login nicht betroffen.
    Die Datei /etc/nginx/fastcgi.conf habe ich gemäß Anleitung ergänzt und nginx neu gestartet – ohne Erfolg.
    Die Datei /var/packages/WebStation/target/misc/VirtualHost-nginx.mustache existiert nicht, lässt sich auch mit dem mc nicht finden (kein vHost verwendet?).
    Das Verzeichnis /usr/local/etc/apache2X/* existiert nicht (Apache ist nicht aktiviert).
    Was ist zu tun?
    Herzliche Grüße, Manfred

    1. Hallo Manfred,

      Ja ganz recht, ohne vHost existiert diese Datei nicht.
      Da du einen Docker Container nutzt ist primär der die Anlaufstelle für ein Timeout, da der Container ja selbst den Webserver bereit stellt und der auch genutzt wird.
      Je nachdem ob der Container Apache oder Nginx nutzt, müsstest du dort das Timeout kontrollieren.
      Natürlich kann immer noch der DS Proxy (Nginx) das Timeout verursachen. Wie greifst du auf den Docker Container zu? Hast du dafür einen Reverse Proxy konfiguriert?
      Timeouts für Reverse Proxys kannst du in den Erweiterten Einstellungen für den jeweiligen Proxy finden (Systemsteuerung > Anmeldeportal > Reverse Proxy).

      Ich hoffe das hilft dir erst mal weiter.

      Grüße
      Andreas

      1. Herzlichen Dank, Andreas! Genau in den Erweiterten Einstellungen der Reverse Proxys fand ich die Timeout-Einstellungen. Der Einfachheit halber habe ich alle Werte in beiden Proxy auf 900 (Sek.) gesetzt. Nun funzts. Später werde ich untersuchen, wieso der Login mehr als 1 Min. dauert.
        Herzliche Grüße, Manfred

  2. Hallo.
    Verstehe ich es richtig, dass die Änderungen des Timout wie hier beschrieben nicht notwendig sind, wenn man kein virtuellen Host nutzt?

    VG
    Jörg

    1. Hallo Jörg,

      Ich bin mir nicht zu 100% sicher. ist schon eine Weile her dass ich alle Fälle durchgetestet hab. Ich glaube die Konfig unter sites-enabled brauchst du trotzdem, auch wenn du keinen vHost aber Apache als Webserver verwendest.

      Grüße
      Andreas

  3. Servus,
    Im eBook steht
    1. Erstellen Sie die Datei /usr/local/etc/apache2X/sites-enabled/user.conf
    2. Fügen Sie die beiden Zeilen TimeOut 900 und ProxyTimeout 900

    Hier im Blog
    Fügt die beiden Zeilen TimeOut 3600 und ProxyTimeout 3600 ein ?

    egal oder Wichtig ?

    1. Hallo Andreas,

      Die Zahl gibt die Zeit in Sekunden an. 600 (10 Minuten) ist schon ein hoher Wert und reicht im Normalfall völlig aus. 900 ist der Wert den der Synology-Support verwendet hat, von dem ich die Lösung für DSM 7 erhalten habe. 3600 ist ein Wert der in anderen Quellen verwendet wird.
      Du kannst gerne höhere Werte angeben, dadurch kann eigentlich nichts schief gehen. Tritt ein tatsächlicher Fehler am Server auf, oder wird die Verbindung getrennt, dauerts halt nur einfach länger bis der Client das mitbekommt.

      Grüße
      Andreas

Schreibe einen Kommentar zu Jörg Thiem Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert