Kurz gesagt: Wenn ZimaOS Files eine NAS-Freigabe sehen kann, bedeutet das nicht, dass jede Docker-App darauf zugreifen kann
Host und Container haben unterschiedliche Dateisystemansichten. ZimaOS Files kann eine eingebundene NAS unter /media/Plank-home-storage/Media/Books, während Readarr, Audiobookshelf oder ein anderer Container nur die Pfade sieht, die ausdrücklich in diesen Container eingebunden wurden. Binde den tatsächlichen ZimaOS-Hostpfad in den Container ein und verwende anschließend den containerseitigen Pfad innerhalb der Anwendung.
Jede Volume-Zeile als Hostpfad → Containerpfad lesen
Zum Beispiel:
/media/Plank-home-storage/Media/Books -> /books
/DATA/Downloads -> /downloadsDie linke Seite existiert auf ZimaOS. Die rechte Seite existiert innerhalb von Readarr. Wähle in der App /books, nicht den Hostpfad. Die aktuellen ZimaOS-App-Pfade erklären diese Trennung. Docker bezeichnet denselben Mechanismus als Docker-Bind-Mounts.
Zuerst nachweisen, dass die NAS auf dem Host eingebunden ist
findmnt | grep -i cifs
mount | grep -i cifs
ls -la /mediaWenn die NAS-Freigabe hier fehlt, kann Docker sie ebenfalls nicht verwenden. Behebe zuerst den SMB/NFS-Mount. Wenn Files sie durchsuchen kann, fahre mit der Containerzuordnung fort, statt die Remote-NAS zu ändern.
Dann nachweisen, dass die App den Containerpfad sehen kann
docker exec -it READARR_CONTAINER sh
ls -la /booksWenn /books fehlt, überprüfe die Volume-Einstellungen. Wenn es vorhanden, aber leer ist, stelle sicher, dass der Hostpfad auf den richtigen eingebundenen Ordner verweist. Wenn Dateien sichtbar sind, Importe aber fehlschlagen, liegt das Problem nun bei Berechtigungen, Benennungen oder app-spezifischen Bibliotheksregeln.
Dieselbe NAS nicht unabhängig in jeder App einbinden
Wenn der entfernte Speicher einmal auf der ZimaOS-Hostebene eingebunden und anschließend in Apps per Bind-Mount eingebunden wird, gibt es eine zentrale Stelle zur Verwaltung von Zugangsdaten und erneuten Verbindungen. Der Nachteil ist die Abhängigkeit vom Host-Mount. Ein fehlender Remote-Mount kann gefährlich werden, wenn eine App in ein leeres lokales Verzeichnis mit demselben Pfad schreibt.
Die NAS-Dateifreigabe hilft dabei, entfernten Speicher vom App-Zugriff zu trennen.
Berechtigungen sind auch nach der Korrektur des Pfads wichtig
touch /books/.write-test
rm /books/.write-testWenn der Test fehlschlägt, verwenden Sie nicht chmod 777 dauerhaft. Überprüfen Sie die SMB-Anmeldedaten, die Container-UID/GID und den Lese-/Schreibmodus des Volumes.
Eine einheitliche Pfadstrategie für den gesamten *arr-Stack verwenden
Readarr, Sonarr, Radarr und Download-Clients lassen sich leichter verwalten, wenn sie einheitliche Hostpfade verwenden. Uneinheitliche Zuordnungen sind ein häufiger Grund dafür, dass eine App eine Datei importiert, während eine andere meldet, der Pfad existiere nicht.
Die ZimaOS-App-Anforderungen bieten ein umfassenderes Modell für den App-Speicher.
App-Daten und Mediendaten getrennt halten
Die Konfiguration gehört in AppData. Bücher und Medien gehören auf das NAS oder in den Speicherpool. Downloads können in einem dritten Pfad liegen. Die ZimaOS-Datenmigration ist hilfreich, wenn sich das Speicherlayout nach der Installation geändert hat.
Denken Sie daran, dass der NAS-Mount des Hosts einen eigenen SMB-Lebenszyklus hat.
Ein Docker-Bind-Mount macht die entfernte SMB-Verbindung nicht zuverlässiger, sondern stellt lediglich das bereits eingebundene Hostverzeichnis bereit. Die Linux-CIFS-Mounts erklären die Host-Ebene unterhalb der Containerzuordnung. Wenn die Verbindung zum entfernten NAS getrennt wird, kann der Containerpfad weiterhin vorhanden sein, während die erwarteten Dateien verschwinden. Überwachen Sie daher den Mount selbst und nicht nur die App.
Bei stark automatisierten *arr-Stacks ist das Neustartverhalten wichtig. Stellen Sie sicher, dass die Remote-Freigabe eingebunden ist, bevor Sie Apps starten, die Dateien verschieben oder umbenennen. Andernfalls kann eine Anwendung Verzeichnisse im lokalen Dateisystem erstellen, obwohl sie auf der Netzwerkfreigabe vorgesehen waren.
FAQ
Warum kann ZimaOS Files mein NAS sehen, Readarr aber nicht?
ZimaOS Files arbeitet auf der Host-Ebene. Readarr sieht nur Verzeichnisse, die ausdrücklich in seinen Container eingebunden wurden.
Soll ich in Readarr /DATA eingeben?
Nur wenn /DATA oder ein Unterordner tatsächlich in den Container eingebunden ist. Verwenden Sie normalerweise den containerseitigen Pfad wie /books.
Was ist, wenn die App den Ordner sieht, aber nicht darin schreiben kann?
Überprüfen Sie den Bind-Modus, die SMB-Anmeldedaten und die Container-UID/GID.
Können alle *arr-Apps denselben Medien-Mount verwenden?
Ja. Einheitliche Zuordnungen erleichtern in der Regel das Verständnis von Importen und Hardlinks.
Soll die App-Konfiguration auf der NAS-Freigabe liegen?
Belassen Sie die Containerkonfiguration im stabilen lokalen AppData-Verzeichnis, sofern die App nicht ausdrücklich Netzwerkdateisysteme für ihre Datenbank unterstützt.
