Community-Lösung

ZimaOS-Apps können den Speicher nicht sehen: Docker-Volumes für Jellyfin, Emby und Plex hinzufügen

A June-November 2024 ZimaCube thread where Jellyfin, Emby, and Plex could only browse paths exposed inside their Docker containers. IceWhale staff instructed users to edit app volume mappings; multiple users later confirmed adding the storage/media volume fixed the problem. ZimaOS subsequently improved the UI and added managed app-data migration.

Wenn Jellyfin, Emby oder Plex nur ZimaOS-HD, nicht aber die Festplatte, NVMe oder das RAID sehen können, auf dem deine Medien tatsächlich liegen, besteht das Problem normalerweise nicht darin, dass Docker „keine Berechtigung für das NAS“ hat. Ein Container kann nur Hostordner durchsuchen, die ZimaOS als Volumes in ihn einbindet.

Das war die zentrale Lösung im ursprünglichen Thread vom Juni 2024. ETWang1991 wies die Benutzer an, die Einstellungen der App zu öffnen und den neuen Speicher als Volume hinzuzufügen. Der ursprüngliche Beitragende antwortete, dass es danach „wie am Schnürchen“ funktionierte, und ein anderer Jellyfin-Benutzer kam später nach dem Ansehen der Screenshots zum gleichen Schluss.

Eine Docker-App sieht nicht das gesamte Host-Dateisystem von ZimaOS

Die Container-Isolierung ist beabsichtigt. Jellyfin kann /Media innerhalb seines Containers nur dann, wenn dieser Pfad einem tatsächlichen Hostverzeichnis mit den Medien zugeordnet wurde.

Dass ein Laufwerk in den ZimaOS-Dateien angezeigt wird, macht es nicht automatisch in jedem App-Store-Container sichtbar.

Öffne die Einstellungen der App und bearbeite die Volumes

ZimaOS-Anwendungsmenü mit hervorgehobenen Einstellungen zum Bearbeiten einer Docker-App
Die offizielle Antwort verwies die Benutzer in die Einstellungen der jeweiligen App, da Volume-Zuordnungen pro Anwendung konfiguriert werden.

Wähle den tatsächlichen Medienordner auf dem Host

ZimaOS-Speicherauswahl mit den Ordnern „TV-Serien“, „Musik“ und „Filme“ unterhalb des Medienverzeichnisses
Der Speicherauswahldialog zeigt den Hostordner, der in den Container eingebunden wird.

Wähle das Verzeichnis auf dem tatsächlichen Speicher, das deine Bibliothek enthält, statt einen geratenen übergeordneten Pfad wie /Main-Storage.

Host- und Containerpfade haben unterschiedliche Aufgaben

Jellyfin-Einstellungen mit ZimaOS-Speicherpfaden auf der Hostseite, die Container-Volume-Pfaden zugeordnet sind
Der Hostpfad kennzeichnet den tatsächlichen ZimaOS-Ordner; der Containerpfad ist der Ort, an dem Jellyfin innerhalb seines isolierten Dateisystems suchen wird.

Der Containerpfad sollte einfach und stabil sein, etwa /media oder /MediaFüge in Jellyfin Bibliotheken über diesen Containerpfad hinzu – nicht über den direkten Hostpfad.

Mehrere Benutzer bestätigten, dass die Volume-Zuordnung der fehlende Schritt war

Der ursprüngliche Beitragende sagte, dass die Änderung funktioniert habe. Ein anderer Benutzer mit einem RAID-5-Main-Storage sah zunächst nur die Betriebssystemfestplatte und antwortete dann, dass ihm die Screenshots die entscheidende Idee gegeben hätten: „Ich musste die Volumes zu Jellyfin hinzufügen.“

Das ist eine quellenbestätigte Lösung und kein spekulativer Workaround für Berechtigungen.

Einzeln hinzugefügte Laufwerke waren 2024 ein Schwachpunkt der Benutzeroberfläche

Einige Teilnehmer hatten Schwierigkeiten, einzeln aktivierte Laufwerke oder RAID-Speicher im alten Auswahlfenster auszuwählen. Mitarbeiter von IceWhale antworteten, dass einzelne Laufwerke aktiviert und verwendet werden konnten, und erklärten später, dass die Benutzeroberfläche verbessert worden sei.

Diese Einschränkungen aus dem Jahr 2024 gehören zum frühen ZimaOS. Die aktuellen Speicher- und App-Einstellungen von ZimaOS machen den verwalteten Speicher deutlich transparenter.

Aktuelles ZimaOS dokumentiert App-Speicherpfade ausdrücklich

Die aktuelle IceWhale-Dokumentation erklärt nun, dass Container aus dem App Store dauerhafte Daten in realen Host-Ordnern speichern und dass die Volume-Zuordnungen jeder App in ihren Einstellungen überprüft und geändert werden können.

Verwenden Sie das aktuelle ZimaOS-Modell für Docker-App-Pfade, wenn Sie Jellyfin, Emby, Plex oder eine andere App zuordnen.

Speicherort von AppData und Medien sind getrennt

Konfigurations- und Datenbankdateien der Anwendung können am konfigurierten Speicherort für App-Daten liegen, während große Mediendateien in einem anderen RAID- oder HDD-Pool gespeichert werden. Verweisen Sie das Konfigurations-Volume der App nicht auf den Filmordner und gehen Sie nicht davon aus, dass das Verschieben von AppData jede Medienbibliothek verschiebt.

Aktuelles ZimaOS kann verwaltete Anwendungsdaten verschieben

Mit der aktuellen Datenmigration können Docker-Images und Docker-Anwendungsdaten in einen anderen Speicherbereich verschoben werden. Dadurch wird ein anderes Problem gelöst als durch das Hinzufügen eines Medien-Volumes: Das eine bestimmt, wo die App selbst dauerhafte Zustände speichert, während das andere dem Container Zugriff auf Benutzermedien gewährt.

Siehe den aktuellen Workflow für die Migration verwalteter Anwendungsdaten.

Wählen Sie schreibgeschützte Medien-Mounts, wenn die App keine Dateien ändern muss

Ein Medienserver muss Filme und Musik in der Regel lesen können, benötigt aber nicht unbedingt die Berechtigung, die Quellbibliothek zu löschen oder neu zu organisieren. Wenn das aktuelle App-Paket dies zulässt, verringert eine schreibgeschützte Zuordnung der Medien den Schaden, den ein kompromittierter oder falsch konfigurierter Container verursachen kann.

Anwendungen, die Dateien absichtlich umbenennen, verschieben oder importieren – etwa einige Download- oder Fotoverwaltungs-Stacks –, benötigen ein anderes Modell für Schreibberechtigungen.

Volume-Zuordnung und Dateisystemberechtigungen sind getrennt zu prüfen

Das Hinzufügen des korrekten Host-Ordners ist die erste Voraussetzung. Der Containerprozess muss außerdem über ausreichende Dateisystemberechtigungen verfügen, um diesen Ordner zu lesen oder zu beschreiben. Wenn ein zugeordnetes Verzeichnis angezeigt wird, aber leer geöffnet wird oder Berechtigungsfehler zurückgibt, ermitteln Sie zunächst die Container-UID/GID und die Besitzverhältnisse auf dem Host, bevor Sie weitreichende Berechtigungen verwenden. chmod 777 Umgehungslösungen.

Das Problem der Quelle aus dem Jahr 2024 bestand hauptsächlich in der fehlenden Volume-Zuordnung; spätere Berechtigungsprobleme sollten erst diagnostiziert werden, nachdem der korrekte Pfad tatsächlich gemountet wurde.

Den Containerpfad bei Neuinstallationen stabil halten

Wenn die Jellyfin-Bibliothek mit /Mediaund den Containerpfad in /mnt/media2 Bei einer Neuinstallation kann die vorhandene Bibliothek als fehlend erscheinen, obwohl die Dateien auf dem Host nie verschoben wurden.

Behalten Sie nach Möglichkeit denselben Containerpfad bei oder aktualisieren Sie die Bibliothekskonfiguration der Anwendung bewusst, nachdem sich die Zuordnung geändert hat.

Die aktuelle Benutzeroberfläche ist besser als die Auswahl im Jahr 2024, aber die Docker-Regel hat sich nicht geändert

IceWhale räumte in der ursprünglichen Quelle ein, dass der alte Speicherauswahldialog verwirrend war, und verbesserte die Oberfläche später. Das aktuelle ZimaOS zeigt den Speicherort der App-Daten, Host-/Containerpfade, die Speichermigration und die Nutzung des App-Caches nun direkter an.

Die zugrunde liegende Docker-Regel bleibt unverändert: Ein Container sieht nur, was in ihn gemountet wurde.

FAQ zum Speicherzugriff von Apps

Warum kann ZimaOS Files ein Laufwerk sehen, Jellyfin jedoch nicht?

Files läuft auf Host-Ebene; Jellyfin läuft in einem Container und sieht nur die gemounteten Volumes.

Wurde im ursprünglichen Thread bestätigt, dass das Hinzufügen des Volumes funktioniert?

Ja. Mehrere Nutzer meldeten Erfolg, nachdem sie das Speicher-/Medienvolume hinzugefügt hatten.

Sollte Jellyfin den unveränderten Hostpfad durchsuchen?

Nein. Jellyfin sollte den Containerpfad verwenden, der dem zugeordneten Host-Ordner entspricht.