Wie man den Hermes Agent auf einem Heimserver betreibt, ohne Daten zu verlieren

Kurze Antwort

Um Hermes Agent auf einem Heimserver ohne Datenverlust zu betreiben, verlassen Sie sich nicht auf das interne Dateisystem des Containers als einzigen Speicherort für Konfiguration, Fähigkeiten, Protokolle, generierte Dateien oder Gateway-Einstellungen. Planen Sie zuerst einen persistenten Host-Ordner oder Docker-Volume, mounten Sie ihn in den Container-Pfad, den die App tatsächlich nutzt, prüfen Sie die Dateibesitzrechte und vergewissern Sie sich, dass die Daten nach Neustart oder Neukonfiguration noch vorhanden sind. Dieser Artikel konzentriert sich auf das häufige Fehlerbild, bei dem ein Container einen Ordner wegen Problemen mit Volume-Mount, Berechtigungen oder Pfadzuordnung nicht finden kann.

Der sicherste Workflow für Anfänger ist:

1. Identifizieren Sie, welche Hermes Agent-Daten erhalten bleiben müssen.
2. Wählen Sie einen dedizierten Host-Ordner oder ein von Docker verwaltetes Volume.
3. Ordnen Sie diesen Speicher dem richtigen Container-Pfad zu.
4. Bestätigen Sie, dass der App-Benutzer darauf schreiben kann.
5. Sichern Sie wichtige Konfigurationen vor Updates oder Neuaufbauten.
6. Starten Sie neu und prüfen Sie, ob Konfiguration, Protokolle, generierte Dateien und Gateway-Einstellungen noch vorhanden sind.

Ein laufender Container bedeutet nicht automatisch, dass Ihre Daten sicher sind. Daten sind nur sicher, wenn sie an einem persistenten Ort gespeichert sind, vom richtigen Benutzer beschreibbar sind, bei Bedarf gesichert werden und nach dem Neustart überprüft werden.

Warum Hermes Agent-Daten in einer Container-Umgebung verschwinden können

Containerisierte Apps sind oft einfach zu starten und zu ersetzen. Das ist nützlich für Updates, Tests und Wiederherstellung, bedeutet aber auch, dass alles, was nur in der wegwerfbaren Container-Schicht gespeichert ist, verloren gehen kann, wenn der Container entfernt, neu erstellt oder neu gebaut wird.

Für einen selbstgehosteten KI-Agenten kann dies mehr als nur Grundeinstellungen betreffen. Je nachdem, wie Sie den Agenten nutzen, können Modellkonfiguration, Fähigkeiten, generierte Dateien, Protokolle, Messaging-Gateway-Einstellungen und anderer App-Zustand wichtig sein.

Container-Neustarts vs. persistente App-Daten

Ein normaler Container-Neustart entfernt nicht immer Daten. Wenn die Daten in einem persistenten Volume oder korrekt zugeordneten Host-Ordner gespeichert sind, sollten sie nach dem Neustart weiterhin verfügbar sein.

Das Risiko entsteht, wenn wichtige Dateien nur in der beschreibbaren Schicht des Containers liegen. Diese Schicht ist nicht dasselbe wie ein geplanter persistenter Speicherort. Wenn Sie den Container neu erstellen, ohne den richtigen Pfad zu erhalten oder erneut zu mounten, startet die App möglicherweise neu oder findet ihre vorherigen Dateien nicht.

Warum das Löschen oder Neuerstellen eines Containers ungespeicherten Zustand entfernen kann

Das Löschen oder Neuerstellen eines Containers unterscheidet sich vom Neustart. Ein neu erstellter Container kann ein neues internes Dateisystem, neue Umgebungsvariablen oder eine andere Mount-Zuordnung verwenden.

Wenn Hermes Agent-Einstellungen, Fähigkeiten, Protokolle oder generierte Ausgaben nie in einem persistenten Host-Ordner oder Volume gespeichert wurden, folgen sie möglicherweise nicht dem neuen Container. Deshalb können sowohl „die App hat gestern funktioniert“ als auch „die App wurde nach dem Update zurückgesetzt“ wahr sein.

Die sichere Vorgehensweise ist, den Austausch eines Containers als ein Datenrisiko zu betrachten, es sei denn, Sie haben bestätigt, wo die App-Daten gespeichert sind.

Warum Host-Pfade und Container-Pfade zuerst geplant werden müssen

Ein Host-Pfad ist der Ort, an dem Daten auf dem Heimserver gespeichert sind. Ein Container-Pfad ist der Ort, an dem die App diese Daten aus dem Container heraus sieht. Ein Volume-Mount oder Bind-Mount verbindet diese beiden Welten.

Wenn der Host-Pfad korrekt, aber an den falschen Container-Pfad gebunden ist, verhält sich die App möglicherweise so, als ob der Ordner nicht existiert. Wenn der Container-Pfad korrekt, der Host-Pfad aber flüchtig ist, schreibt die App möglicherweise Daten an einen unerwünschten Ort.

Planen Sie die Zuordnung, bevor Sie die App starten, nicht nachdem Sie Daten verloren haben.

Welche Daten sollten Sie vor dem Start des Hermes-Agenten schützen?

Bevor Sie einen Container ändern, ein Image aktualisieren oder ein Gateway neu konfigurieren, listen Sie die Daten auf, deren Neuerstellung schmerzhaft wäre. Nicht jede Datei benötigt denselben Schutz, aber Sie sollten wissen, welche Dateien kritisch sind.

Eine nützliche Regel lautet: Schützen Sie alles, was Identität, Zugriff, Konfiguration, erlernte Workflows oder Ausgaben speichert, die Sie nicht leicht neu erzeugen können.

Agentenkonfiguration und Einstellungen des Modellanbieters

Modelleinstellungen umfassen normalerweise die Anbieterwahl, Endpunktwerte, Modellnamen, kontextbezogene Optionen und API-Zugriff. Wenn diese Einstellungen verloren gehen, kann der Agent starten, aber nicht korrekt antworten.

Speichern Sie die Modellkonfiguration in einem persistenten App-Datenpfad, nicht in einer temporären Shell-Sitzung. Wenn die Konfiguration über Umgebungsvariablen bereitgestellt wird, bewahren Sie eine sichere Kopie der Compose-Datei, der Env-Datei oder der Bereitstellungsnotizen auf.

Schützen Sie auch alle Einrichtungsauswahlen, die bestimmen, wie der Agent Terminal-Tools oder Messaging-Gateways verwendet.

App-Speicher, Sitzungen, Skills und Laufzeitstatus

Hermes-Agent-Daten können mehr als eine Konfigurationsdatei enthalten. Die Hermes-Skills-Datenstruktur erklärt, dass Skills in ~/.hermes/skills/ gespeichert sind, was die primäre Quelle für gebündelte, hub-installierte und vom Agenten erstellte Skills ist. Sie beschreibt auch verwandte Zustände wie gebündelte Manifeste, Skill-Bundles, Hub-Tap-Konfiguration, ausstehende Skill-Schreibvorgänge und Konfigurationseinstellungen.

Das ist wichtig, weil vom Agenten erstellte Skills zu wiederverwendbarem prozeduralem Gedächtnis werden können. Wenn der falsche Pfad eingebunden ist, verlieren Sie nicht nur Einstellungen, sondern auch Workflows, die der Agent gelernt hat, oder Skills, die Sie installiert haben.

Behandeln Sie Skills, Bundles, ausstehende Schreibvorgänge und profilbezogene Zustände als persistente Agentendaten.

Downloads, generierte Dateien, Protokolle und Tool-Ausgaben

Generierte Dateien werden leicht übersehen. Ein Agent kann während der normalen Nutzung Pläne, Skripte, Berichte, Screenshots, Protokolle oder heruntergeladene Dateien erstellen.

Diese Dateien können im aktiven Arbeitsbereich, im Backend-Arbeitsverzeichnis, im App-Home-Verzeichnis oder in einem eingebundenen Ausgabeordner gespeichert werden. Wenn sich dieser Ort nur im Container befindet, können die Dateien verschwinden, wenn der Container entfernt wird.

Für den praktischen Einsatz entscheiden Sie, wo generierte Dateien auf dem Host-Server erscheinen sollen, und überprüfen Sie, ob der Container dort schreibt.

API-Schlüssel, Bot-Tokens und Umgebungsvariablen

Geheimnisse sind keine gewöhnlichen App-Daten. API-Schlüssel, Bot-Tokens, Dashboard-Passwörter und Umgebungsvariablen benötigen sowohl Persistenz als auch Schutz.

Speichern Sie Geheimnisse nicht in zufällig generierten Ausgabeordnern oder breit geteilten Verzeichnissen. Bewahren Sie sie in einem kontrollierten Konfigurationspfad mit eingeschränktem Zugriff auf.

Eine gute Geheimnisverwaltungs-Einrichtung sollte folgende Fragen beantworten:

• wo das Geheimnis gespeichert ist;
• welcher Benutzer es lesen kann;
• ob es in Backups enthalten ist;
• ob das Backup verschlüsselt oder zugangskontrolliert ist;
• wie das Geheimnis rotiert werden kann, wenn es offengelegt wird.

Host-Pfad vs. Container-Pfad vs. Volume-Mounts

Dies ist das Schlüsselkonzept hinter den meisten „Container kann Ordner nicht finden“ und „Daten sind nach Neustart verschwunden“-Problemen. Ein Container kann nur sehen, was sich in seinem eigenen Dateisystem befindet oder was in ihn eingebunden wurde.

Verwenden Sie Die Agentendaten-Überlebenskarte, um die Einrichtung zu organisieren, bevor Sie Fehler beheben.

Framework-Modul	Schlüssel-Frage	Was es Ihnen hilft zu entscheiden	Setup- / Fehlerbehebungsfokus
Dateninventar	Welche Daten Neustart oder Neuerstellung des Containers überleben müssen	Welche Konfigurationen, Fähigkeiten, Protokolle, Downloads, Tokens und generierte Dateien geschützt werden müssen	Verhindert, dass wichtige Agentendaten als flüchtiger Zustand behandelt werden
Persistenzpfad	Wo persistente Daten auf dem Host gespeichert werden sollten	Ob ein dedizierter Host-Ordner, Docker-Volume oder Bind-Mount verwendet werden soll	Verhindert Datenverlust nach Neuerstellung des Containers
Mount-Mapping	Ist der Host-Pfad korrekt in den Container-Pfad gemappt?	Ob die App den vorgesehenen Ordner tatsächlich sehen kann	Hilft bei der Diagnose von fehlenden Ordnern und falschen Zielpfad-Fehlern
Berechtigungsgrenze	Welcher Benutzer die eingebundenen Daten besitzt und welcher darauf schreibt	Ob Host-Benutzer, Container-Benutzer, App-Benutzer oder root die Dateien besitzt	Hilft, „Permission denied“ zu beheben, ohne alles root-eigen zu machen
Backup-Grenze	Was vor Updates oder Neukonfiguration gesichert werden sollte	Welche Daten kritisch und welche temporär sind	Verhindert den Verlust von Konfiguration, Fähigkeiten, Sitzungen, Tokens und Gateway-Einstellungen
Neustart-Validierung	Existieren die Daten nach Neustart oder Update noch?	Ob die Einrichtung tatsächlich dauerhaft ist	Verwandelt „es läuft“ in eine wiederholbare Sicherheitsprüfung

Was der Host-Server speichert

Der Host-Server speichert die echten Ordner, Festplatten und von Docker verwalteten Speicherorte. Wenn Sie einen Bind-Mount verwenden, wählen Sie einen bestimmten Host-Ordner. Wenn Sie ein benanntes Docker-Volume verwenden, wählt und verwaltet Docker den Speicherort.

Diese Unterscheidung ist wichtig, da die Sichtbarkeit des Hosts Backup und Migration beeinflusst. Ein bindgemounteter Ordner ist für Anfänger möglicherweise leichter zu finden und zu kopieren. Ein benanntes Volume ist für von Docker verwaltete App-Daten möglicherweise sauberer, aber Sie müssen trotzdem wissen, wie man es überprüft oder sichert.

Wählen Sie den Speicherstil basierend darauf, ob Sie menschenlesbare Host-Ordner, von Docker verwaltete App-Persistenz oder einen kontrollierten Backup-Pfad benötigen.

Was der Container sehen kann

Der Container sieht sein eigenes internes Dateisystem und alle eingebundenen Pfade. Er sieht nicht automatisch jeden Ordner auf Ihrem Heimserver.

Dockers Bind-Mount-Anleitung zeigt, wie ein Host-Verzeichnis im Container an einem Zielpfad erscheinen kann und wie Dateiänderungen zwischen Host und Container reflektiert werden, wenn das Mount korrekt ist.

Das ist die Kernidee: Die App ist egal, wo eine Datei auf dem Host existiert, solange die Datei nicht in den Pfad eingebunden ist, den die App verwendet.

Wie Volume-Mounts App-Daten persistent halten

Ein persistentes Mount gibt der App einen stabilen Ort zum Schreiben von Daten, der über die Lebensdauer eines einzelnen Containers hinausgeht. Für App-Daten ist dies oft der Unterschied zwischen „neustartsicher“ und „nur Container-Lebensdauer“.

Das Mount muss dem von der App erwarteten Datenpfad entsprechen. Wenn die App in einen internen Ordner schreibt, Sie aber einen anderen Ordner einbinden, können die Daten trotzdem in temporären Speicher gelangen.

Eine gute persistente Einrichtung sollte definieren:

• der Host-Ordner oder das benannte Volume;
• der Zielpfad im Container;
• ob das Mount schreibbar oder nur lesbar ist;
• welche App-Daten dort hingehören;
• wie der Pfad gesichert wird.

Warum falsche Pfadzuordnung zu Fehlermeldungen über fehlende Ordner führt

Falsche Zuordnung sieht oft wie ein fehlendes Ordnerproblem aus. Der Ordner kann auf dem Host existieren, aber der Container kann ihn nicht sehen. Oder der Container hat einen Ordner am erwarteten Pfad, aber er ist nicht mit dem Host-Ordner verbunden, den Sie vorgesehen haben.

Häufige Symptome sind:

• Die App meldet, dass ein Ordner nicht existiert;
• Generierte Dateien erscheinen im Container, aber nicht auf dem Host;
• Logs verschwinden nach dem Neuaufbau des Containers;
• Konfiguration setzt sich nach dem Update zurück;
• Sie bearbeiten einen Host-Ordner, aber die App verwendet weiterhin alte Einstellungen;
• Backup-Skripte laufen, schließen aber nicht die echten App-Daten ein.

Wenn dies passiert, überprüfen Sie Host-Pfad und Container-Pfad zusammen. Untersuchen Sie nicht nur eine Seite.

So starten Sie Hermes Agent, ohne Daten zu verlieren

Das Ziel ist nicht nur, Hermes Agent zu starten. Das Ziel ist sicherzustellen, dass die Daten, die Ihnen wichtig sind, Neustart, Update, Neuaufbau und Neukonfiguration überleben.

Schritt 1: Wählen Sie einen dedizierten Host-Datenordner

Wählen Sie einen Host-Datenordner, bevor Sie den Container starten oder neu erstellen. Er sollte leicht zu identifizieren, einfach zu sichern und nicht mit nicht verwandten persönlichen Dateien vermischt sein.

Ein dedizierter Ordner reduziert das Risiko, da Sie sehen können, was zur App gehört. Er vermeidet auch, dass Ihr gesamtes Home-Verzeichnis oder andere sensible Ordner in den Container eingebunden werden.

Ein praktischer Host-Datenordner sollte:

• app-spezifisch;
• außerhalb von temporären Download-Pfaden;
• in Ihren Backup-Plan einbezogen;
• nicht breit mit nicht verwandten Diensten geteilt;
• nur für die Benutzer oder Dienste beschreibbar, die Zugriff benötigen.

Schritt 2: Datenordner in den Container einbinden

Binden Sie den Host-Datenordner in den Containerpfad ein, den die App erwartet. Dies ist der Moment, in dem viele Datenverlustprobleme entstehen oder vermieden werden.

Bei einem Bind-Mount wählen Sie den Host-Pfad aus, und der Zielpfad ist der Ort, an dem er im Container erscheint. Bei einem benannten Volume verwaltet Docker den Speicherort auf der Host-Seite.

Gehen Sie nicht davon aus, dass die App automatisch einen gemounteten Ordner verwendet. Bestätigen Sie, dass das gemountete Ziel mit dem tatsächlichen App-Datenpfad übereinstimmt.

Schritt 3: Bestätigen, dass der Container den erwarteten App-Datenpfad verwendet

Nach dem Mounten den Pfad von innen im Container prüfen. Ein Ordner kann auf dem Host existieren und trotzdem für die App unsichtbar sein, wenn er nicht korrekt gemountet ist.

Die einfachste Validierung ist, eine harmlose Testdatei von einer Seite zu erstellen oder zu finden und zu bestätigen, dass sie auf der anderen Seite erscheint. Dann prüfen, ob die App echte Konfigurations-, Log- oder generierte Dateien in denselben persistenten Pfad schreibt.

Dieser Schritt ist besonders wichtig vor Updates oder Migrationen.

Schritt 4: Dateibesitz und Schreibberechtigungen prüfen

Ein korrektes Mount kann trotzdem fehlschlagen, wenn die App nicht darauf schreiben kann. Berechtigungsfehler treten oft auf, wenn Dateien von root erstellt wurden, die App später aber als anderer Benutzer läuft.

Überprüfen Sie die Eigentümerschaft, bevor Sie Berechtigungen breit ändern. Die richtige Lösung ist meist, dem vorgesehenen App-Benutzer Lese- und Schreibrechte für den spezifischen App-Datenordner zu geben, nicht jedem Prozess volle Kontrolle über breite Host-Verzeichnisse.

Wenn Sie „Zugriff verweigert“ sehen, identifizieren Sie:

1. der gemountete Host-Pfad;
2. der Zielpfad im Container;
3. der Benutzer, der die App ausführt;
4. der Dateibesitzer;
5. ob das Mount schreibgeschützt ist;
6. ob ein Backup- oder Exportpfad auch beschreibbar ist.

Schritt 5: Geheimnisse und Konfigurationsdateien außerhalb entfernbarer Pfade aufbewahren

Geheimnisse und Konfigurationsdateien sollten nicht nur in temporären Ordnern, generierten Ausgabeverzeichnissen oder ad-hoc Shell-Verläufen liegen. Wenn Sie Umgebungsvariablen verwenden, bewahren Sie die Bereitstellungsdatei oder Env-Datei an einem kontrollierten, persistenten Ort auf.

Vermeiden Sie es, Geheimnisse mit Logs oder generierten Artefakten zu vermischen. Logs können zur Fehlerbehebung geteilt werden, während Geheimnisse niemals unbedacht geteilt werden sollten.

Wenn Sie Geheimnisse sichern, schützen Sie das Backup. Ein Backup, das API-Schlüssel oder Bot-Token offenlegt, stellt ein anderes Risiko dar.

Schritt 6: Container neu starten und überprüfen, ob die Daten noch vorhanden sind

Nach der Einrichtung den Container neu starten und prüfen, ob die wichtigen Daten erhalten bleiben. Dies ist der praktischste Test für Persistenz.

Hören Sie nicht bei „der Container startet“ auf. Bestätigen Sie, dass:

• Modelleinstellungen existieren weiterhin;
• Fähigkeiten oder App-Zustand bleiben sichtbar;
• Logs werden weiterhin am erwarteten Ort gespeichert;
• generierte Dateien erscheinen auf dem Host;
• Gateway- oder Bot-Einstellungen funktionieren weiterhin;
• Backup-Dateien können sich befinden.

Eine Einrichtung, die die Neustartvalidierung besteht, ist viel sicherer als eine, die nur die Erstinstallation bestanden hat.

Berechtigungen, Backups und Sicherheitsgrenzen

Datensicherheit hängt von drei Grenzen ab: wer schreiben kann, was gesichert wird und was der Agent berühren darf. Diese Grenzen sind besonders wichtig für selbstgehostete Agenten, da sie Dateien erstellen, Workflows ändern oder mit Tools interagieren können.

Warum Container-Benutzerberechtigungen wichtig sind

Container-Benutzerberechtigungen entscheiden, ob die App ihre Daten lesen und schreiben kann. Wenn die App als ein Benutzer läuft, der gemountete Ordner jedoch einem anderen Benutzer gehört, können Schreibvorgänge fehlschlagen.

Deshalb kann das Ausführen eines Setup-Befehls als Root später Probleme verursachen. Root kann Dateien erfolgreich erstellen, aber der normale App-Benutzer kann sie möglicherweise nicht ändern.

Beheben Sie Berechtigungen auf Ebene des App-Datenordners. Vermeiden Sie breite Berechtigungsänderungen, die nicht verwandte Host-Dateien freigeben.

Warum Sie vermeiden sollten, alles als Root auszuführen

Root kann viele Einschränkungen umgehen, aber das macht es nicht zu einer sicheren Standardeinstellung. Alles als Root auszuführen kann root-eigene Dateien erzeugen, Berechtigungsprobleme verbergen und der App mehr Zugriff geben, als sie benötigt.

Für die meisten selbstgehosteten App-Workflows sollte Root nur für spezifische administrative Schritte verwendet werden. Die routinemäßige App-Konfiguration sollte, wenn möglich, als der vorgesehene App- oder Container-Benutzer ausgeführt werden.

Ein sichereres Muster ist das Prinzip der geringsten Rechte: Geben Sie der App nur Schreibzugriff auf die Ordner, die sie benötigt.

Wann man schreibgeschützte Mounts oder begrenzte Ordner verwendet

Verwenden Sie schreibgeschützte Mounts, wenn der Agent Dateien inspizieren, aber nicht ändern soll. Verwenden Sie begrenzte beschreibbare Ordner, wenn der Agent Ausgaben erstellen, aber keine umfassenden persönlichen oder Systemverzeichnisse berühren soll.

Dies ist besonders nützlich, wenn der Agent Berichte, Pläne oder Skripte generieren soll, ohne Schreibzugriff auf alle Serverdateien zu erhalten.

Ein Design mit begrenztem Ordnerumfang reduziert die Auswirkungen von Fehlern. Es erleichtert auch Backups, da Sie wissen, welcher Ordner den App-Zustand und welcher die generierten Ausgaben enthält.

So sichern Sie Agent-Daten vor Updates oder Neukonfiguration

Sichern Sie wichtige App-Daten, bevor Sie Container-Images, Mount-Pfade, Gateway-Einstellungen oder Profile ändern. Ein Backup ist nur nützlich, wenn Sie wissen, was es enthält und wie man es wiederherstellt.

Die Docker-Community Diskussion über Berechtigungsfehler bei Volume-Backups zeigt ein häufiges Nutzerproblem: Ein Pfad kann existieren, aber Backup- oder Schreibvorgänge können wegen Berechtigungs-, Eigentums-, Labeling- oder Mount-Einschränkungen fehlschlagen.

Nutzen Sie dies als Erinnerung, Backups zu testen, nicht nur zu erstellen. Ein Backup-Plan sollte sowohl die Erstellung als auch die Wiederherstellungsprüfung umfassen.

Häufige Probleme und wie man sie behebt

Wenn Hermes Agent-Daten fehlen, installieren Sie die App nicht sofort neu. Identifizieren Sie zuerst, welche Schicht fehlgeschlagen ist: Dateninventar, Persistenzpfad, Mount-Mapping, Berechtigungsgrenze, Sicherungsgrenze oder Neustartvalidierung.

Der Container kann einen gemounteten Ordner nicht finden

Dies bedeutet normalerweise, dass der Pfad in einer Schicht existiert, in der anderen jedoch nicht. Der Host-Ordner ist möglicherweise nicht gemountet, der Zielpfad im Container könnte falsch sein oder die App sucht an einem anderen Ort.

Überprüfen Sie in dieser Reihenfolge:

1. Bestätigen Sie, dass der Ordner auf dem Host existiert.
2. Bestätigen Sie, dass der Container das Mount hat.
3. Bestätigen Sie den Zielpfad innerhalb des Containers.
4. Bestätigen Sie, dass die App so konfiguriert ist, dass sie diesen Zielpfad verwendet.
5. Bestätigen Sie, dass der App-Benutzer den Ordner lesen kann.
6. Bestätigen Sie, dass das Mount nach Änderungen an Compose- oder Run-Einstellungen neu erstellt wurde.

Beheben Sie das nicht, indem Sie zufällige Ordner im Container erstellen. Das kann den Fehler vorübergehend verbergen, während die Daten im flüchtigen Speicher bleiben.

App-Daten werden nach Neustart zurückgesetzt

Wenn Daten nach dem Neustart zurückgesetzt werden, schreibt die App möglicherweise in das interne Dateisystem des Containers statt in den persistenten Pfad. Sie könnte auch ein anderes Profil, eine andere Umgebungsvariable oder ein anderes Datenverzeichnis als erwartet verwenden.

Überprüfen Sie, ob der Datenpfad vor und nach dem Neustart derselbe ist. Prüfen Sie dann, ob der Ordner durch ein Mount oder nur durch die Container-Ebene unterstützt wird.

Wenn die App neu erstellt wurde, bestätigen Sie, dass dasselbe Volume oder Bind-Mount am neuen Container angehängt wurde.

Zugriffsfehler im Datenverzeichnis

„Permission denied“ bedeutet, dass die App den Pfad sieht, aber die erforderliche Aktion nicht ausführen kann. Das Problem kann Eigentümerschaft, schreibgeschützte Mount-Einstellungen, Dateisystem-Labels oder eine Diskrepanz zwischen Host- und Container-Benutzer sein.

Beginnen Sie mit der kleinsten Prüfung: Kann der App-Benutzer eine harmlose Testdatei im Datenverzeichnis erstellen? Wenn nicht, prüfen Sie den Besitzer und die Berechtigungen dieses Pfads.

Vermeiden Sie es, das Problem durch breite Schreibrechte auf das gesamte Host-Verzeichnis zu lösen. Beheben Sie den App-Datenpfad und den vorgesehenen App-Benutzer.

Generierte Dateien werden nur im Container gespeichert

Wenn generierte Dateien nach dem Neuaufbau verschwinden, wurden sie wahrscheinlich im Container statt in einem gemounteten Host-Pfad gespeichert. Das passiert oft, wenn das Arbeitsverzeichnis oder das Ausgabeverzeichnis der App nicht gemappt ist.

Entscheiden Sie, wo generierte Dateien abgelegt werden sollen. Mounten Sie dann diesen Ausgabeordner oder konfigurieren Sie die App so, dass sie an einem bestehenden persistenten Speicherort schreibt.

Nachdem Sie den Pfad geändert haben, erzeugen Sie eine harmlose Testdatei und bestätigen Sie, dass sie auf dem Host erscheint.

Bot- oder Gateway-Einstellungen verschwinden nach Neukonfiguration

Gateway-Einstellungen können verschwinden, wenn die Konfiguration in einem nicht-persistenten Pfad gespeichert ist oder wenn die App nach dem Neustart unter einem anderen Profil läuft. Dasselbe kann passieren, wenn eine Umgebungsvariable an einer Stelle geändert wird, der laufende Container aber einen anderen Wert verwendet.

Überprüfen Sie, ob die Gateway-Konfiguration, der Bot-Token-Verweis, die Allowlist und die Dashboard-Einstellungen am erwarteten persistenten Speicherort gespeichert sind. Starten Sie dann das Gateway neu und bestätigen Sie, dass die Einstellungen aktiv bleiben.

Wenn der Bot vor dem Neustart funktioniert, danach aber nicht, konzentrieren Sie sich auf Persistenz und Umgebungs-Konfiguration, bevor Sie das Token ändern.

So überprüfen Sie, ob Ihre Hermes-Agent-Daten sicher sind

Eine sichere Einrichtung sollte Neustart-, Schreib-, Backup- und Zugriffsprüfungen bestehen. Diese Prüfungen müssen nicht kompliziert sein, sollten aber nach größeren Änderungen wiederholt werden.

Konfiguration bleibt nach Neustart erhalten

Ändern Sie eine harmlose Einstellung, starten Sie den Container neu und überprüfen Sie, ob die Einstellung erhalten bleibt. Dies bestätigt, dass die App in den persistenten Speicher schreibt.

Wenn die Einstellung verschwindet, fügen Sie nicht weiter Konfigurationen hinzu. Beheben Sie zuerst den Datenpfad.

Logs und generierte Dateien erscheinen im erwarteten Host-Ordner

Logs und generierte Dateien sollten dort erscheinen, wo Sie sie auf dem Host erwarten. Wenn sie nur im Container erscheinen, gehen sie möglicherweise beim Neuaufbau verloren.

Überprüfen Sie beide Seiten des Mounts. Host und Container sollten sich über die relevanten Dateien einig sein.

Der Agent kann ohne Berechtigungsfehler in die App-Daten schreiben

Der Agent sollte in der Lage sein, als der vorgesehene Benutzer in seinen App-Datenordner zu schreiben. Ein erfolgreicher Schreibtest ist hilfreicher als nur zu bestätigen, dass der Ordner existiert.

Achten Sie nach dem Neustart auf Berechtigungsfehler in den Logs. Einige Berechtigungsprobleme treten erst auf, wenn der Agent versucht, die Konfiguration zu aktualisieren, eine Fähigkeit zu schreiben, eine generierte Datei zu speichern oder den Gateway-Status zu aktualisieren.

Sicherungsdateien können gefunden und wiederhergestellt werden

Eine Sicherung ist unvollständig, bis Sie sie finden und an einem Testort wiederherstellen können. Bestätigen Sie mindestens, dass die Sicherung die Daten enthält, die Sie schützen wollten.

Für wichtige Konfigurationen stellen Sie die Sicherung vor der Nutzung in einen separaten Ordner oder eine Testinstanz wieder her. So vermeiden Sie, dass Wiederherstellungsprobleme erst nach Datenverlust entdeckt werden.

Dashboard- oder Nachrichten-Zugang funktioniert nach Neustart weiterhin

Nach dem Neustart überprüfen Sie, ob das Dashboard oder der Nachrichten-Zugang weiterhin funktioniert. Dies bestätigt, dass persistente Daten, Zugangsdaten, Gateway-Einstellungen und Netzwerkzugang weiterhin übereinstimmen.

Wenn das Dashboard funktioniert, aber die Nachrichtenübermittlung fehlschlägt, überprüfen Sie die Gateway-Einstellungen und den Token-Zugriff. Wenn die Nachrichtenübermittlung funktioniert, aber generierte Dateien verschwinden, überprüfen Sie den Ausgabepfad und die Mounts.

Wie das in einer echten Heimserver-Umgebung funktioniert

In einer echten Heimserver-Umgebung gilt dieselbe Datensicherheitslogik, auch wenn das System ein benutzerfreundliches Dashboard bietet. Sie müssen dennoch wissen, welche Daten erhalten bleiben müssen, wo sie gespeichert sind, wie der Container sie sieht, welcher Benutzer darauf schreiben kann und wie Sie dies nach einem Neustart überprüfen.

Zum Beispiel zeigt der ZimaOS Hermes Agent Setup-Workflow einen gerätespezifischen Pfad, der die Konfiguration des Modellanbieters, die Einrichtung des Telegram-Gateways, das Betreten des Hermes-Containers, die Aktivierung der App-Umgebung, die Überprüfung des Web-Dashboards und die Fehlerbehebung bei Berechtigungs- oder Bot-Antwortproblemen umfasst.

Für Nutzer, die Docker-Apps, Agenten-Workflows und lokale Dienste auf einer kompakten, ständig eingeschalteten Maschine betreiben, ist ZimaBoard 2 Heimserver ein relevantes Beispiel für die Art von leichtgewichtigem Heimserver-Umfeld, in dem persistente Ordner, Container-Pfade, Berechtigungen und Speichererweiterung gemeinsam geplant werden müssen. Es ist nicht die einzige mögliche Konfiguration, aber sie entspricht der Art von selbstgehostetem App-Workflow, der in diesem Leitfaden behandelt wird.

Die allgemeine Lektion ist portabel: Bevor Sie einem containerisierten Agenten nützliche Arbeit anvertrauen, stellen Sie sicher, dass seine wichtigen Daten über den Container hinaus erhalten bleiben, der gerade läuft.

FAQ

Warum sind meine Hermes Agent-Daten nach dem Neustart des Containers verschwunden?

Ein einfacher Neustart sollte persistente Daten nicht löschen, aber die App kann zurückgesetzt erscheinen, wenn sie in einen nicht-persistenten Containerpfad geschrieben hat. Die Daten können auch fehlen, wenn der Container ohne dasselbe Volume oder Bind-Mount neu erstellt wurde. Überprüfen Sie den Host-Pfad, Container-Pfad und den tatsächlichen App-Datenpfad, bevor Sie weitere Einstellungen ändern.

Was ist der Unterschied zwischen einem Docker-Volume und einem Bind-Mount?

Ein Docker-Volume wird von Docker verwaltet, während ein Bind-Mount einen von Ihnen gewählten Host-Ordner in den Container einbindet. Ein Volume ist oft sauber für appverwaltete Daten, während ein Bind-Mount leichter direkt auf dem Host zu finden ist. Die beste Wahl hängt davon ab, ob Sie Docker-verwalteten Speicher oder einen sichtbaren Host-Ordner für Backup und Inspektion wünschen.

Wo sollte ich die Hermes Agent-App-Daten auf einem Heimserver speichern?

Verwenden Sie einen dedizierten persistenten Ordner oder ein Docker-Volume anstelle eines temporären Containerpfads. Der Speicherort sollte leicht zu sichern sein, auf die Bedürfnisse der App beschränkt und nicht mit sensiblen, nicht verwandten Dateien vermischt sein. Der wichtigste Punkt ist, dass der erwartete Containerpfad der App tatsächlich auf diesen persistenten Speicher abgebildet sein muss.

Warum sagt der Container, dass ein Ordner nicht existiert?

Der Ordner kann auf dem Host existieren, aber nicht im Container. Das bedeutet normalerweise, dass das Mount nicht erstellt wurde, der Quellpfad falsch ist, der Zielpfad falsch ist oder die App in einem anderen Containerpfad sucht. Überprüfen Sie sowohl die Host-Seite als auch die Container-Seite, anstatt blind einen neuen Ordner zu erstellen.

Sollte ich Hermes Agent als Root ausführen, um Berechtigungsfehler zu vermeiden?

Das Ausführen als Root kann den unmittelbaren Fehler verbergen, aber es kann Dateien im Besitz von Root erstellen und das Risiko erhöhen. Ein sichererer Ansatz ist, dem vorgesehenen App-Benutzer nur Lese- und Schreibrechte für den erforderlichen App-Datenpfad zu geben. Verwenden Sie Root nur für spezifische administrative oder Reparaturaktionen, wenn Sie die Änderung verstehen.

Wie oft sollte ich die Hermes Agent-Daten sichern?

Sichern Sie vor Updates, dem Neuaufbau von Containern, Pfadänderungen, Gateway-Neukonfigurationen oder der Migration zu einem anderen Server. Für den aktiven Gebrauch planen Sie regelmäßige Backups basierend darauf, wie oft sich Skills, Einstellungen, generierte Dateien oder Sitzungen ändern. Ein Backup ist erst dann zuverlässig, wenn Sie bestätigt haben, dass die Dateien gefunden und wiederhergestellt werden können.