Synology NAS (DSM)

Auf einer Synology laufen ein paar Dinge anders als auf einem gewöhnlichen Linux-Server — das hat nichts mit Tunetorch zu tun, kostet aber beim ersten Start regelmäßig Zeit. Diese Seite sammelt die drei Punkte, über die praktisch jeder stolpert, und sagt jeweils, woran man erkennt, dass genau dieser Punkt das Problem ist.

Die allgemeine Installation steht unter Installation mit Docker; hier stehen nur die Abweichungen.

Port 5000 ist schon belegt

DSM betreibt seine eigene Weboberfläche auf Port 5000. Ein Container, der denselben Port belegen will, startet gar nicht erst oder verdrängt die Anmeldung an der NAS.

Wähle deshalb einen anderen Host-Port. Im Container bleibt es bei 5000:

    ports:
      - "7999:5000"

Tunetorch ist danach unter http://<NAS-Adresse>:7999 erreichbar. Läuft ein Reverse-Proxy davor, zeigt dessen Ziel ebenfalls auf diesen Host-Port.

Der Container läuft mit einer anderen UID

Ein freigegebener Ordner auf der NAS gehört selten 1000:1000. Prüfe die Zahlen auf dem Host — per SSH oder in der File Station — und setze sie:

    environment:
      TT_PUID: "1026"
      TT_PGID: "100"

1026:100 ist auf DSM ein häufiger Wert (erster angelegter Benutzer, Gruppe users), aber kein Naturgesetz: Maßgeblich ist der Eigentümer deines Datenordners.

Der wichtigste Punkt: Freigaben sind für den Container nicht automatisch lesbar

Das ist der Stolperstein, der am meisten Zeit kostet — und der einzige, bei dem alles richtig aussieht, während nichts funktioniert.

Das Symptom: Du hängst deine Musiksammlung als /app/import oder /app/musik ein, in der File Station und über das Netzwerk kannst du den Ordner problemlos lesen — und Tunetorch findet trotzdem nichts. Der Import erkennt das inzwischen: Er zeigt einen Hinweis an und lässt sich gar nicht erst starten. Ältere Stände meldeten stattdessen „erfolgreich abgeschlossen, 0 Dateien importiert“ — wenn du das siehst, ist es dieselbe Ursache.

Der Grund: DSM verwaltet freigegebene Ordner über eine eigene Berechtigungsliste (Windows-artige ACL) und setzt die klassischen Linux-Rechte des Ordners dafür bewusst auf „niemand darf etwas“. Solange du selbst über DSM zugreifst, greift die Berechtigungsliste und alles ist gut. Ein Programm im Container hat aber keine DSM-Anmeldung — es ist nur eine Benutzernummer. Deckt die Berechtigungsliste diesen Zugriff nicht ab, bleiben die klassischen Rechte übrig, und die lassen niemanden hinein.

Dass der Ordner dir gehört und du ihn lesen kannst, sagt darüber nichts aus. Genau das macht den Fall so zäh: Jede Prüfung, die man üblicherweise anstellt, sieht in Ordnung aus.

Die Lösung

In DSM: Systemsteuerung → Freigegebener Ordner → deinen Ordner wählen → Bearbeiten → Berechtigungen. Trage dort den Benutzer, unter dessen Nummer der Container läuft (also TT_PUID von oben), namentlich ein und gib ihm mindestens Lesen.

Anschließend musst du die Berechtigung ausdrücklich auf die Unterordner anwenden — in der File Station über Eigenschaften → Berechtigung. Ohne diesen zweiten Schritt öffnet sich nur die oberste Ebene, und der Zugriff scheitert eine Ebene tiefer.

So prüfst du es nach

Der entscheidende Punkt: Prüfe als App-Benutzer, nicht als Administrator.

docker exec -u 1026:100 tunetorch ls /app/import

Kommt die Ordnerliste, ist alles in Ordnung. Kommt Permission denied, fehlt der Eintrag in der Berechtigungsliste oder er wurde nicht auf die Unterordner angewandt.

Ohne -u ist die Prüfung wertlos. docker exec läuft sonst als root, und root umgeht die Rechteprüfung vollständig — du bekommst immer die Ordnerliste zu sehen, egal wie die Rechte stehen.

Falls die Oberfläche einmal nicht trägt

Ersatzweise per SSH auf der NAS (nicht im Container — dort ist die Sammlung nur lesend eingehängt):

sudo chmod o+rX /volume1/<dein-ordner>
sudo chmod -R g+rX /volume1/<dein-ordner>

Das große X ist Absicht: Es gibt das Betretungsrecht nur an Ordner weiter und macht deine Audiodateien nicht ausführbar.

Der Start dauert etwa eine Minute

Auf NAS-Hardware vergeht zwischen dem Start des Containers und der ersten beantworteten Anfrage rund eine Minute — die Datenbank wird geprüft und der Server hochgefahren. Ein „Bad Gateway“ vom Reverse-Proxy in dieser Zeit ist normal und verschwindet von selbst.

Erst wenn es dauerhaft bleibt, lohnt die Suche. Ein guter erster Blick ist das Container-Log: Steht dort als einziger Zugriff die interne Gesundheitsprüfung (127.0.0.1, Python-urllib), hat deine Anfrage den Container nie erreicht — die Ursache liegt dann davor (Proxy, Portfreigabe, Namensauflösung), nicht in Tunetorch.

Weiter

• Bibliothek befüllen — Import, Upload und Scan
• Fehlerbehebung — alles, was nicht Synology-spezifisch ist