Beiträge von Bodo

Es scheint am DNS zu liegen. Wenn ich die IP verwende, gibt es keine Probleme mit ssh.

Ich habe mich auch für die Standardvariante entschieden. Bislang nur bei einem Server und der ist auch noch nicht durch damit.

Was mich aber sehr wuschig macht, die ssh-Anmeldungen bei beiden(!) Servern funktionieren seit neuestem nicht mehr, obwohl gestern noch alles ok war. Wird langsam merkwürdig.

Wäre es sinnvoll, others auf none zu setzen, statt read only?

So sieht's aus. Ein Neuanfang ist besser.

Danke für die schnelle Antwort ... und den Link.

Wahrscheinlich werde ich das so machen, hätte aber schon gern die Ursache gefunden ... und verstanden.

Zitat von macom

Dafür gibt es das resetperms plugin von omv-extras

Das habe ich bereits (hier im Forum) gefunden, allerdings noch nicht verwendet. Wollte meine anderen Dienste nicht mit plattmachen. Und verstehen würde ich es auch gern bis ins Detail, woran es liegt. Da hilft stumpfes Zurücksetzen nur bedingt, bietet allerdings einen neuen, sauberen Anfanges.

Zitat von macom

Wie hast du denn den rsync job aufgesetzt? Scheduled Job, rsync plug in, script? Am besten die Einstellungen per screenshot posten.

Wurde direkt als Dienst im OMV konfiguriert.

Inzwischen habe ich nochmals die Berechtigungen auf das Wurzelverzeichnis rekursiv neu gesetzt.

Der Besitzer und und die Gruppe xy darf jeweils rwx, others darf nichts (none). Hier die ACL dazu, alles andere ist nicht gesetzt (nichts gelb markiert bei den einzelnen Benutzern und Gruppen. Unter den "normalen" Berechtigungen (Permissions) hat nur der Besitzer und die Gruppe xy Lese-und Schreibrechte. Einzele Rechte an Benutzer sind nicht vergeben, ich steuere das nur über Gruppenrechte.

Der rsync-User ist Teil der Gruppe xy und sollte damit überall hinkommen.

Kannst du mir das rot Markierte erklären.

Wenn ich es recht verstehe (und es gibt hier ja auch Posts dazu), sollte man die ACL nur verwenden, wenn notwendig.

Meine Frage: Kann ich in der ACL ALLES, also auch die Rechte für das rot markierte auf NONE setzen und NUR in den Permissions die Rechte vergeben oder funktioniert das nicht. Ich hätte gedacht, komplett ohne ACL (also überall NONE) sollte gehen oder wie wäre es richtig?

Hallo zusammen,

inzwischen versuche ich seit einigen Wochen, rsync zu durchschauen ... und dabei arbeitete es seit Jahren problemlos. Allerdings vermute ich eine bisher nie ganz saubere Konfiguration.

Aber zum Problem:

rsync soll die Daten aus bestimmten Verzeichnissen von zwei OMVs synchronisieren ... und hat das auch jahrelang getan. Der Job wird immer manuell ausgelöst.

Beim letzten Aufrufen der Aufgabe gab es die Meldung: "receiving incremental file list rsync: [sender] opendir "." (in <Verzeichnis>) failed: Permission denied (13)", obwohl nichts geändert wurde, nur vorher Updates eingespielt.

Und jetzt kommt das, was man nie machen soll, ich habe an den Berechtigungen manipuliert, in der Annahme, dass dies etwas bringen könnte. Natürlich Quatsch, wenn vorher nichts verändert wurde.

Jedenfalls hat nichts geholfen. Nun habe ich ein neues Verzeichnis (auf gleicher Verzeichnisebene) angelegt, entsprechend freigegeben und der Sync hat auf Anhieb funktioniert.

Um herauszubekommen, woran es liegt, habe ich dem rsync-user (der heißt bei mir auch direkt so), alle Rechte auf das Dateisystem entzogen, auf beiden Servern. Was soll ich sagen, völlig egal, es geht weiterhin. Und das macht mir die meisten Sorgen!

In der Annahme, die Systeme verkonfiguriert zu haben, habe ich folgende Fragen:

* Wie kann ich alle Rechte auf das Dateisystem (FTP, NFS, SMB, RSYNC) korrekt zurücksetzen?

* Wie sind die korrekten Einstellungen in OMV zu setzten (gern ein kurzes Beispiel).

* Lässt sich erklären, warum rsync beim Testverzeichnis noch funktioniert hat, obwohl ich dem User "rsync-user", mit dem sich der eine Server zum anderen verbindet, auf beiden Servern die Dateirechte entzogen hatte?

Ein Tipp wäre toll.

Hallo,

ich hatte unter OMV5 Docker und einige Container in Benutzung. Seit inzwischen längerer Zeit kann ich diese unter OMV6 nicht mehr verwalten. Nutzbar sind die eingerichteten Container weiterhin (z.B. Nextcloud).

Allerdings sind sie nicht mehr in Verwendung, da ich sie, wegen der Probleme mit Docker, durch physische Geräte ersetzt habe.

Meine Frage ist nun, wie ich die Docker-"Altlasten" entweder doch wieder verwalten oder diese restlos entfernen kann.

Das vorhandene Watchtower habe ich "irgendwie halb" gelöscht und in der neuen Form installiert, bekomme aber folgende Meldung:

Weitere Versuche habe ich dann nicht mehr unternommen, da ich es nicht noch schlimmer machen möchte.

Nextcloud würde ich zwar zum Testen gern behalten, kann aber auch damit leben, wenn alles entsorgt wird. Hätte gern wieder ein einigermaßen sauberes System.

Kann mir vielleicht jemand helfen ...?

Niemand eine Idee?

Ich würde auch alles (Docker und sämtliche Container) entfernen und es komplett neu versuchen, müsste nur wissen, wie alles richtig entfernt wird.

Hallo,

ich habe das Problem, dass Docker auf meinem OMV6 läuft, jedoch keine Container gestartet werden können.

Hier ein Beispiel für Portainer:

docker start portainer

Error response from daemon: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error setting cgroup config for procHooks process: bpf_prog_query(BPF_CGROUP_DEVICE) failed: invalid argument: unknown

Error: failed to start containers: portainer

Grub habe ich angepasst und neu gestartet.

GRUB_CMDLINE_LINUX_DEFAULT="quiet apparmor=0"

Hat jemand einen Tipp, was ich tun kann?

Um das Thema zu schließen, kurze Info zum letzten Stand.

Nach vielen Stunden des Testens erscheint mir Snapraid, zumindest für mich, keine Alternative. Der Pflegeaufwand ... und dass Gefühl einer gewissen Unsicherheit, welche Daten nun tatsächlich aktuell auf dem Server liegen und auch verfügbar sind, wenn eine HDD ausfällt (ist der Sync gelaufen, ...), haben mich dazu bewogen, beim klassischen RAID zu bleiben. Wie gesagt, diese Aussage gilt nur für mich und meine Anforderungen. Wollte das Thema nur nicht offen lassen ....

Hallo,

mir wurde Snapraid als Alternative zum kassischen RAID empfohlen wurde und mir gefällt die flexible Erweiterbarkeit. Deshalb habe ich mir auf meinem Bakupserver ein Snapraid mit vier Datenplatten und einer Paritätsplatte erstellt und dieses mit Daten gefüllt. Diese Daten sind im Anschluss mehrmals auf dem Server hin und her kopiert worden. Zum Zustand des Snapraids anbei zwei Anhänge - das ist der aktuelle Stand und gleichzeitig das Problem.

Was muss ich tun, um die aufgeführten Fehler zu beheben und das Snapraid in einen sicheren Zustand zu versetzen?

... und was bedeutet "Getötet' nach dem Ausführen des Befehls "snapraid fix" bzw. "snapraid sync"?

Kann ich OMV so einstellen, dass automatisch nach meinentwegen einem GB-Daten bzw. jede Stunde ein Plattensync ausgelöst wird oder was sind sinnvolle Einstellungen, wenn ich nur Daten per rsync auf den Server schiebe und diesen danach wieder abschalte?

Snapraid läuft aber bislang komme ich nicht damit klar.

Habt Ihr einen Tipp, was zu tun ist?

Zuerst mit snapraid scrub, danach snapraid fix versucht. Ergebnisse siehe Anhang.

Ich hab' gerade keine Idee ....

Was bedeutet "getötet"?

Zitat von HannesJo

Das RAID war aber vorhin noch eingehängt als du die Festplatten löschen wolltest, das hatte ich richtig verstanden? Also wenn es jetzt ausgehängt ist solltest du es in der OMV GUI unter RAID löschen können.

Hat bestens funktioniert. Danke.

So, neuer Server läuft ... aber das RAID 5 ist wieder/noch immer da.

Hat jemand einen Vorschlag, wie ich es am besten entferne? Bevor HannesJo wieder (berechtigte) Kritik übt!

Hab hier was dazu gefunden: https://debianforum.de/forum/viewtopic.php?t=110319

omv-fistaid meldet keine Fehler.

Die Konfiguration war schon etwas umfangreicher aber ich denke, ich werde neu installieren.

HannesJo, bedauerlicherweise hast du in diesem Fall absolut recht.

Andererseits liegen die Daten noch auf zwei weiteren Servern und teilweise auf einer weiteren HDD.

Für den schlimmsten Fall habe ich mich vorher gedanklich auf eine Neuinstalltation eingestellt, da ich nie sicher bin, wie sauber alles entfernt wird oder ob bei diesem Server, nach geschätzten 10 Jahren Nutzung, eine Neuinstalltation eh die bessere Entscheidung ist.

Was meine Herangehensweise hier betrifft, stimme ich die aber voll zu - Asche auf mein Haupt.

Leider erreiche ich den Server, nach meiner Glanztat, nicht mehr über die GUI oder SSH.

Habt ihr eventuell noch eine Idee, ansonsten bleibt wohl nur eine Neuinstallation.

Nein, nur die Datenplatten. Diese sind inzwischen auch vom Mainboard getrennt.

Ich habs inzwischen "versaut".

Hab unter Festplatte (glaube ich zumindest) "diese Platte" (schnell) löschen, für jede Platte, ausgewählt.

Nun kann ich den OMV leider nicht mehr über den Browser oder SSH erreichen, nur noch direkt an der Maschine ist die Console verfügbar.

Einen Tipp, wie ich (nach meiner voreiligen Aktion) weitermachen kann?

Mir ist allerdings nicht klar, warum der Zugriff per Browser/sSH nicht mehr klappt).