Community-Lösung

ZimaOS-App kann nicht auf den Hauptspeicher schreiben: Ordnerbesitz von app-spezifischen Berechtigungen trennen

A January 2026 thread where a first community reply blamed general ZimaOS storage ownership and suggested recreating folders in Files. The original poster disproved that as a universal fix with SFTPGo and Navidrome, leading the responder to revise the diagnosis to application-specific permission and feature behavior.

Der Quellthread zeigt, warum „Die App kann nicht auf RAID schreiben“ nicht sofort als ein einzelner ZimaOS-Berechtigungsfehler betrachtet werden sollte. Die erste Antwort aus der Community behauptete, Container aus dem App Store hätten außerhalb ihres eigenen AppData-Ordners normalerweise nur Lesezugriff, sofern kein Ordner über „Dateien“ erstellt oder dort „angefasst“ wurde. Der ursprüngliche Verfasser versuchte genau das und konnte trotzdem keine SFTPGo-Ordner erstellen oder Musik aus Navidrome löschen.

Nach diesen Gegenbeispielen überarbeitete der Antwortende seine Erklärung: Dateisystemeigentümer sind nur eine Ebene. Jede Anwendung hat außerdem ihren eigenen Container-Benutzer, erwartete interne Pfade und Funktionsgrenzen. Diese spätere Korrektur ist die zuverlässigere Erkenntnis.

Es gibt drei verschiedene Berechtigungsebenen

  • ZimaOS-Hostspeicher: der tatsächliche RAID- oder Festplattenordner sowie dessen Eigentümer und Berechtigungen.
  • Docker-Volume-Zuordnung: ob der Hostordner in den Container eingebunden ist und ob die Einbindung schreibgeschützt erfolgt.
  • Anwendungsverhalten: unter welchem Benutzer die App ausgeführt wird und ob die Software selbst das Erstellen, Löschen oder Umbenennen von Dateien unterstützt.

Ein Fehler auf jeder dieser Ebenen kann wie „Zugriff verweigert“ aussehen.

Das Erstellen des Ordners in „Dateien“ war keine universelle Lösung

Der erste Vorschlag lautete, den Zielordner über ZimaOS „Dateien“ zu erstellen oder zu verschieben, damit der Eigentümer korrekt gesetzt würde. Der ursprüngliche Verfasser erstellte srv/data auf dem RAID, verwies SFTPGo darauf und erhielt weiterhin Fehler wegen verweigerter Berechtigungen.

Daher kann die Methode über „Dateien“ nicht als garantierte Lösung für alle Apps bezeichnet werden.

SFTPGo benötigt einen beschreibbaren Pfad, der zu seinem Laufzeitbenutzer und seiner Konfiguration passt

SFTPGo wird mit eigenen Berechtigungen sowie Regeln für virtuelle Ordner und Home-Verzeichnisse ausgeführt. Ein Hostverzeichnis kann vorhanden und sichtbar sein, während der SFTPGo-Prozess trotzdem nicht hineinschreiben darf.

Prüfen Sie bei einer aktuellen Bereitstellung gemeinsam den Hostordner, den Docker-Einbindungsmodus, die Container-UID/GID und das konfigurierte Home- bzw. virtuelle Verzeichnis des SFTPGo-Benutzers.

Der ursprüngliche Antwortende erklärte, Navidrome solle bei der Bibliotheksverwaltung als schreibgeschützt betrachtet werden und das Löschen von Titeln innerhalb von Navidrome sei in seinem Kontext nicht unterstützt. Die Unfähigkeit des Benutzers, einen Titel zu löschen, war daher kein guter Beleg dafür, dass die RAID-Berechtigungen grundsätzlich fehlerhaft waren.

Verwalten Sie Quelldateien für Musik mit „Dateien“ oder einem anderen Dateiverwaltungstool, sofern die jeweils aktuelle Navidrome-Version nicht ausdrücklich eine unterstützte Funktion zum Ändern von Dateien dokumentiert.

Prüfen Sie, ob das Docker-Volume schreibgeschützt eingebunden ist

Eine Volume-Zuordnung kann ausdrücklich den schreibgeschützten Modus verwenden. Wenn die App Dateien ändern soll, muss der Hostordner mit Lese- und Schreibzugriff eingebunden sein, und die Prozessidentität muss Schreibberechtigungen im Hostdateisystem besitzen.

Im aktuellen ZimaOS können Benutzer die Volume-Zuordnungen von Apps in den Anwendungseinstellungen einsehen und bearbeiten.

Das aktuelle ZimaOS macht Host- und Containerpfade transparenter

IceWhale dokumentiert inzwischen die Beziehung zwischen appseitigen Pfaden wie /config oder /media und den tatsächlichen Speicherordnern, die dahinterliegen.

Verwenden Sie das aktuelle ZimaOS-Pfadmodell für Apps, bevor Sie rekursives chmod/chown als erste Maßnahme einsetzen.

Verwenden Sie chmod 777 nicht als Abkürzung zur Diagnose

Umfassende Schreibberechtigungen können das eigentliche Problem verschleiern und gemeinsam genutzte Daten für unbeteiligte Prozesse zugänglich machen. Außerdem beheben sie keine App, die ein Volume absichtlich schreibgeschützt öffnet oder einen Pfad aufgrund ihrer eigenen Konfiguration ablehnt.

Ändern Sie nur die minimal erforderlichen Eigentümer- oder Gruppenberechtigungen für die App.

Eine bessere Diagnoseabfolge

  1. Bestätigen Sie den genauen Hostordner in ZimaOS.
  2. Bestätigen Sie, dass die App das Verzeichnis dem erwarteten Containerpfad zuordnet.
  3. Prüfen Sie, ob die Zuordnung schreibgeschützt ist.
  4. Ermitteln Sie die UID/GID oder den Benutzer, unter dem der Container ausgeführt wird.
  5. Überprüfen Sie, ob diese Identität in den Hostordner schreiben kann.
  6. Bestätigen Sie, dass die Anwendung selbst den versuchten Vorgang unterstützt.

FAQ zu Speicherberechtigungen von Apps

Hat das erneute Erstellen des Ordners in ZimaOS „Dateien“ den ursprünglichen SFTPGo-Fall gelöst?

Nein. Der ursprüngliche Verfasser versuchte es und erhielt weiterhin „Zugriff verweigert“.

Wird ein lesbarer RAID-Ordner automatisch in jeder App beschreibbar?

Nein. Der Docker-Einbindungsmodus, die Container-UID/GID und das Anwendungsverhalten sind weiterhin entscheidend.

Sollte Navidrome als universeller Dateimanager verwendet werden?

Nein. Betrachten Sie die Musikquelle als außerhalb von Navidrome verwaltet, sofern die aktuelle Anwendung nicht ausdrücklich Änderungen an Dateien unterstützt.