Synology NAS (DSM)

Auf einer Synology laufen ein paar Dinge anders als auf einem normalen Linux-Server. Mit Tunetorch hat das nichts zu tun, kostet beim ersten Start aber oft Zeit. Diese Seite sammelt die Punkte, über die fast jeder stolpert, und sagt dir jeweils, woran du erkennst, dass genau dieser Punkt das Problem ist.

Die allgemeine Installation steht unter Installation mit Docker. Hier stehen nur die Unterschiede.

Port 5000 ist schon belegt

DSM nutzt Port 5000 für seine eigene Weboberfläche. Ein Container, der denselben Port belegen will, startet gar nicht erst oder verdrängt die Anmeldeseite der NAS.

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

    ports:
      - "7999:5000"

Tunetorch erreichst du danach unter http://<NAS-Adresse>:7999. Läuft ein Reverse-Proxy davor, muss auch er auf diesen Port zeigen.

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 trag sie ein:

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

1026:100 ist auf DSM ein häufiger Wert (erster angelegter Benutzer, Gruppe users), aber nicht immer richtig. Entscheidend ist, wem dein Datenordner gehört.

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

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

Woran du es merkst: 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, aber Tunetorch findet trotzdem nichts. Der Import erkennt das und zeigt einen Hinweis an, statt zu starten. Siehst du in einer älteren Version „erfolgreich abgeschlossen, 0 Dateien importiert“, ist es dieselbe Ursache.

Der Grund: DSM regelt den Zugriff auf freigegebene Ordner über eine eigene Berechtigungsliste (eine ACL wie unter Windows). Die normalen Linux-Rechte des Ordners setzt es dafür auf „niemand darf etwas“. Greifst du selbst über DSM zu, zählt die Berechtigungsliste, und alles funktioniert. Ein Programm im Container meldet sich aber nicht bei DSM an, es hat nur eine Benutzernummer. Erlaubt die Berechtigungsliste diesen Zugriff nicht, bleiben nur die normalen Linux-Rechte übrig, und die lassen niemanden hinein.

Dass der Ordner dir gehört und du ihn lesen kannst, sagt darüber nichts. Genau das macht den Fall so zäh: Alles, was man üblicherweise prüft, sieht in Ordnung aus.

Die Lösung

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

Danach 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 eine Ebene tiefer ist wieder Schluss.

So prüfst du es nach

Wichtig: Prüfe als der Benutzer, unter dem Tunetorch läuft, nicht als Administrator.

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

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

Ohne -u bringt die Prüfung nichts. docker exec läuft sonst als root, und root darf alles. Du siehst dann immer die Ordnerliste, egal wie die Rechte stehen.

Falls es über die Oberfläche nicht klappt

Alternativ per SSH auf der NAS (nicht im Container, dort ist die Sammlung nur zum Lesen 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 Recht zum Öffnen nur an Ordner weiter und macht deine Musikdateien nicht ausführbar.

CD-Rippen: Das Laufwerk bleibt unsichtbar

Ein CD-Laufwerk an der NAS kannst du für das CD-Rippen in aller Regel nicht nutzen. Auch die richtigen Zeilen in der Compose-Datei helfen hier nicht.

Woran du es merkst: Tunetorch zeigt in den Server-Einstellungen kein Laufwerk an, obwohl eines eingesteckt ist.

Der Grund: DSM erkennt das Laufwerk zwar als USB-Gerät, bringt aber den Treiber nicht mit, der daraus ein CD-Laufwerk (/dev/sr0) macht. Belegt ist das auf einer DS1621+ mit DSM 7.4, dort fehlt der Treiber vollständig. Auf anderen Modellen sieht es sehr wahrscheinlich genauso aus. Tunetorch liest CDs aber nur über genau dieses Gerät.

So prüfst du es nach

Ohne SSH geht das über den Aufgabenplaner: Systemsteuerung → Aufgabenplaner → Erstellen → Geplante Aufgabe → Benutzerdefiniertes Script, als Benutzer root. Steck das Laufwerk vorher ein und trag als Script ein:

{
  ls -l /dev/sr*
  find /lib/modules -name "sr_mod.ko*"
  dmesg | grep -i "CD-ROM"
} > /volume1/<dein-ordner>/laufwerk.txt 2>&1

Führ die Aufgabe einmal von Hand aus und öffne laufwerk.txt in der File Station:

Was du stattdessen tun kannst

Statt /dev/sr0 legt DSM für das Laufwerk nur einen allgemeinen Geräteeintrag an (/dev/sg…). Den kann Tunetorch nicht nutzen, und du solltest ihn auch nicht durchreichen: Dieselbe Art Eintrag gibt es für jede Festplatte der NAS, und wer ihn freigibt, gibt dem Container direkten Zugriff auf deine Festplatten.

Der Start dauert etwa eine Minute

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

Erst wenn es dauerhaft bleibt, lohnt sich die Suche. Schau dafür zuerst ins Log des Containers: Taucht dort nur die interne Gesundheitsprüfung auf (127.0.0.1, Python-urllib), ist deine Anfrage nie beim Container angekommen. Dann liegt die Ursache davor (Proxy, Portfreigabe, Namensauflösung) und nicht bei Tunetorch.

Weiter

Zurück zur Dokumentations-Übersicht