@MartinP Vielen Dank, das ist somit sehr dringlich und wird von Proxmox auch im Forum empfohlen. Die Updates laufen bei mir bereits.

Das Obige habe ich irgendwann nicht mehr zum Laufen gebracht. Folgendes funktioniert aber ersatzweise: Im PVE feststellen, wie der Coral - Stick sich manifestiert. root@pve:~# lsusb Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 002: ID 1b1f:c020 eQ-3 Entwicklung GmbH HmIP-RFUSB Bus 001 Device 003: ID 0403:6015 Future Technology Devices International, Ltd Bridge(I2C/SPI/UART/FIFO) Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 002 Device 002: ID 2109:711f VIA Labs, Inc. External Bus 002 Device 003: ID 18d1:9302 Google Inc. root@pve:~# Aktuell Bus 002/Device 003, kontrollieren... root@pve:~# ls -l /dev/bus/usb/002 total 0 crw-rw-r-- 1 root root 189, 128 Apr 30 16:02 001 crw-rw-r-- 1 root root 189, 129 Apr 30 16:02 002 crw-rw-r-- 1 root plugdev 189, 130 Apr 30 16:02 003 root@pve:~# Jetzt muss man leider im LXC-Config file basteln In /etc/pve/lxc# cat 107.conf habe ich folgende Zeile angehängt: lxc.mount.entry: /dev/bus/usb/002 dev/bus/usb/002 none bind,optional,create=dir 0,0 Damit wird das komplette obenstehende Verzeichnis in den LXC gemappt ... Das "Bäumchen-Wechsel-Dich" zwischen /dev/bus/usb/002/003 und /dev/bus/usb/002/004 ist damit egal, da frigate den kompletten /dev/bus/usb - Tree nach dem Coral-Stick durchforstet... frigate@ubuntu-frigate-privileged:~$ ls /dev/bus/usb/002 001 002 003 frigate@ubuntu-frigate-privileged:~$ ls /dev/bus/usb 002 frigate@ubuntu-frigate-privileged:~$

@saeft_2003 Die Lösung in der IT heißt immer Redundanz. Ein zweiter NUC, am besten mit einer CPU aus der gleichen Familie / Generation und du könntest die VMs sogar im laufenden Betrieb zwischen den beiden verschieben. Und immer einen Updaten, zurückschieben. So mache ich es bei mir, inklusive Replikation. Es geht auch ohne Smarthome und ioBroker bei uns, wäre dann aber schrecklich unbequem und umständlich.

@BananaJoe sagte in Proxmox Cluster oder HA: Hui, wieviel hast du denn? nur 4 :)

Ein Problem hatte ich noch Iobroker - Backups macht der backup-Adapter nur lokal, da nicht privilegierter LXC Container unter Proxmox... Im Gegensatz zu smb funktioniert aber rsync aus einem nicht privilegierten LXC Nach dem lokalen täglichen Backup gegen 02:00 startet etwas später dann cron gesteuert ein rsync-Job der das lokale Verzeichnis mit einem Verzeichnis auf der USB-Platte des Fileservers synchronisiert ... 5 * * * sshpass -p ".........." rsync -a /opt/iobroker/backups/* martin@192.168.2.84:/mnt/usbdrives/intenso1/backup/Martin/iobroker/ > /dev/null 2>&1 3 5 * * * sshpass -p "........." rsync -a /opt/iobroker/log/*.log.gz martin@192.168.2.84:/mnt/usbdrives/intenso1/backup/Martin/iobroker/Logs/ > /dev/null 2>&1 Heute morgen fehlte dann nach der gestrigen Umstellung das Backup der USB-Platte auf dem neuen Fileserver Nach dem Eingeben von... rsync -a /opt/iobroker/backups/* martin@192.168.2.84:/mnt/usbdrives/intenso1/backup/Martin/iobroker/ .... war klar, dass erstmal der fingerprint des neuen Servers abgenickt werden musste. Danach aber dann diese Fehlermeldung ... rsync: [generator] chgrp "/mnt/usbdrives/intenso1/backup/Martin/iobroker/iobroker_2026_02_17-02_40_10_backupiobroker.tar.gz" failed: Operation not permitted (1) Die neuen Files wurden aber letztendlich kopiert ... -rw-rw-r-- 1 nobody nogroup 89926 Feb 24 01:59 javascripts_2026_02_24-02_59_24_backupiobroker.tar.gz -rw-rw-r-- 1 martin smbusers 89928 Feb 25 01:57 javascripts_2026_02_25-02_57_25_backupiobroker.tar.gz User und Group unterschieden sich ... Bin nicht sicher, ob das auch vorher schon auftrat. Habe das aber jetzt mit zwei "--no-" Optionen geheilt. Keine Fehlermeldungen mehr ... martin@iobroker-test-sicher:~/gitea/iobroker_shellscripte$ rsync -a --no-owner --no-group /opt/iobroker/backups/* martin@192.168.2.84:/mnt/usbdrives/intenso1/backup/Martin/iobroker/ martin@192.168.2.84's password: martin@iobroker-test-sicher:~/gitea/iobroker_shellscripte$

@Negalein Dann sollte es besser ganz getrennt voneinander laufen. Wäre ja doof, wenn bei A alles runter fährt wenn nur bei B die Sicherung fliegt.

Ich war für Deine Frage hier das erste Mal auf diesem Weg in der Konsole der OpenCCU. Normal nehme ich PuTTY am PC oder Terminal am MacBook. Für "Notfälle" Termius am Tablet. Wobei ich bei der OpenCCU noch keinen Notfall hatte. Da sind es eher Updates der anderen VMs von der Couch aus.

War der Meinung, dass ich alle Verweise auf Enterprise getilgt/auskommentiert hätte... vielleicht verguckt...

Aktuell läuft nur auch mein WoMo Projekt parallel, da gibt es jede Menge properitären Blödsinn der in den ioBroker eingebunden werden will ;-) Habe die letzten zwei 'Tage' damit verbracht mit Hilfe von Gemini einen Gasflaschensensor per Bluetooth in IOB einzubinden, war echt zäh aber nun läufts. Ich habe mir zu 'Agent-DVR' aber mal einen leeren Container mit entsprechendem Namen angelegt, dann vergesse ich es nicht ;-)

An der Anleitung von @thomas-braun habe ich mich für alle Debian-VMs langgehangelt. Da gab es keine Probleme.

@peterfido sagte in Irgendwas verursacht 100derte Fail Logins auf meinem PVE: ProxMenuX soll ein Skript von GitHub lachladen und ungeprüft ausführen. Hast Du evtl. Ports ins Internet freigegeben? Nein habe ich getestet, von aussen kommt nix rein. Ich hab aber auch nie was konfiguriert, das irgendetwas raus darf, bzw ich von aussen aufs System. Das lag am Linux Control Adapter, ich hab den Proxmox mal raus, jetzt ist Ruhe, muss mal schauen, da stimmt ja dann wohl der Login nicht.

@Homoran Krass, der Mann hat Recht! Was man so alles rumfummelt über die Jahre. Danke für den Hinweis!

@liv-in-sky sagte in (Erled.)Proxmox - wo kommen die Daten her ?: soll ich mit mir selbst schreiben ? Wenn du selbst die Antwort gefunden hast, wäre es nicht verkehrt diese auch hier zu hinterlassen. Wenn jemand die selbe Frage hat und auf diesen [erledig] Thread stößt, ist er sicher dankbar neben der Frage auch die Antwort zu finden.

so einfach kann das sein https://community-scripts.github.io/ProxmoxVE/scripts?id=iobroker

@arteck said in Backup wird auf andere Nummer zurückgespielt: @guitardoc meine Frage brauchst nicht bantworten.. jo Oops, sorry, das hatte ich ganz übersehen... Hmm, ich kann auch nicht mehr sagen, wie ich es zurückgespielt hab. Vermutlich hab ich das genommen, wo ich zuerst gesehen hab, dass es das Backup ist was ich brauche... Interessant, dass es da Unterschiede gibt. Aber bei näherer Betrachtung macht das schon Sinn - wenn man aus dem LXC rückspielt, dann weiß er ja wohin, während von der Backupplatte kann es sonst wohin gehen. Ich vermute daher, dass ich es von der Backupplatte genommen hab, und dann hat er den ersten freien Slot vorgeschlagen, der ihm untergekommen ist (das war die 100). Und da die 101 möglicherweise auch noch lief, ließ sich die 101 auch nicht mehr für die Herstellung auswählen. Wieder was gelernt!

@feuersturm Danke! viel schlauer, was ich in mittlerer Zukunft mache, bin ich jetzt leider nicht. War gerade dabei wegen Renovierungen im Haus zu erweitern

@martinp sagte in Update proxmox 8 to 9: @david-g Ahh, also gibt die alte Bauernregel immer noch: Nie eine Doppelnull (x.0.0) installieren ;-) Ich habe da auch erstmal zwei Wochen gewartet. Es hat sich bisher gut bewährt .

@crunchip In dem Screenshot?! Von 511 GB noch 17 verfügbar. Ich habe nur die Fakten interpretiert. Mag ja sein das es was anderes bedeutet. Aber als einfacher Leser würde ich den roten 97% zustimmen. Edit : Ging mir auch eher um die Interpretation der roten Farbe . Edit 2: aber der Thread hier ist genau richtig sich mal mit den Begebenheiten von Proxmox zu beschäftigen.

@arteck ich habe das auch ab und zu mal. Meine Vermutung liegt da bei den Replication und Backups, das er da grade sehr beschäftigt ist und etwas länger mit der Antwort braucht.

@martinp hab mal den cronjob umgebaut 11 */4 * * * bash /root/scripte/Proxmox_Skripte/check_usb_hdd.sh 1> /dev/null 2> /dev/null Alles umgeleitet nach /dev/null, aber ob das den Returncode auch entschärft EDIT Scheint geholfen zu haben, habe den Haken bei "Notifications / mail-to-root" wieder aktiviert, und bisher keine mails... EDIT2: da fehlte ein führender Slash bei "/dev/null" hab es oben geändert...