Revan335

Wenn du nicht mal ins BIOS/UEFI kommst, dann stimmt mit dem Board was nicht.

Was ist wenn du CMOS Batterie mal entfernst oder eine andere Möglichkeit zum BIOS/UEFI Reset nutzt?

Wenn du so ne Batterie hast und es immer noch Probleme gibt diese mal tauschen. Vielleicht ist die leer oder hat nen defekt.

Mit der aktuellen Version 7.1.4 gibt es dazu einen Fix der dies unten in der Leiste besser sichtbar macht bzw. wieder ermöglicht.

Die genaue Ursache weiß ich immer noch nicht, allerdings funktionierte auch ein anderer Stick an einem anderen Port mit älterem OS auch nicht fehlerfrei.
 
Erst nach Upgrade auf V7 läuft es nun wieder. Egal ob alter oder aktueller Stick.

Per SATA Kabel und Strom sind also intern.
 
 
Hmmm.... der Editor mobil am Handy ist wohl sehr beschränkt. Sowas wie Codeblock .... gibt es dort nicht.
 
Dann muss der Desktop Modus herhalten. Mobil wäre aber super es da auch geht.
Oct 13 21:15:01 Raster Docker Auto Update: Community Applications Docker Autoupdate running Oct 13 21:15:01 Raster Docker Auto Update: Checking for available updates Oct 13 21:15:27 Raster Docker Auto Update: Stopping Ripper Oct 13 21:15:29 Raster kernel: docker0: port 8(vethe1de2a0) entered disabled state Oct 13 21:15:29 Raster kernel: veth091c513: renamed from eth0 Oct 13 21:15:29 Raster kernel: docker0: port 8(vethe1de2a0) entered disabled state Oct 13 21:15:29 Raster kernel: device vethe1de2a0 left promiscuous mode Oct 13 21:15:29 Raster kernel: docker0: port 8(vethe1de2a0) entered disabled state Oct 13 21:15:29 Raster Docker Auto Update: Installing Updates for Ripper Oct 13 21:16:42 Raster Docker Auto Update: Restarting Ripper Oct 13 21:16:42 Raster kernel: docker0: port 8(veth1d30066) entered blocking state Oct 13 21:16:42 Raster kernel: docker0: port 8(veth1d30066) entered disabled state Oct 13 21:16:42 Raster kernel: device veth1d30066 entered promiscuous mode Oct 13 21:16:43 Raster kernel: eth0: renamed from vethed8b7c1 Oct 13 21:16:43 Raster kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth1d30066: link becomes ready Oct 13 21:16:43 Raster kernel: docker0: port 8(veth1d30066) entered blocking state Oct 13 21:16:43 Raster kernel: docker0: port 8(veth1d30066) entered forwarding state Oct 13 21:16:43 Raster sSMTP[21002]: Creating SSL connection to host Oct 13 21:16:43 Raster sSMTP[21002]: SSL connection using TLS_AES_256_GCM_SHA384 Oct 13 21:16:45 Raster sSMTP[21002]: Sent mail for ***@posteo.de (221 2.0.0 Bye) uid=0 username=root outbytes=746 Oct 13 21:16:45 Raster Docker Auto Update: Community Applications Docker Autoupdate finished Oct 13 21:18:42 Raster emhttpd: spinning down /dev/sdf Oct 13 21:18:44 Raster emhttpd: spinning down /dev/sdg Oct 13 21:18:44 Raster emhttpd: spinning down /dev/sde Oct 13 21:20:50 Raster kernel: sr 7:0:0:0: ioctl_internal_command return code = 2 Oct 13 21:20:50 Raster kernel: sr 7:0:0:0: Sense Key : 0x4 [current] Oct 13 21:20:50 Raster kernel: sr 7:0:0:0: ASC=0x53 ASCQ=0x0  
Interessant.
Der Docker war an.
Hab ihn jetzt mal ausgemacht und beobachte es weiter.
Dennoch wäre es interessant wieso dies passiert. (Das öffnen der Disc Schublade)
 
Yes, das ist mit dabei.
https://registry.hub.docker.com/r/rix1337/docker-ripper
 
Vielen Dank!
 
Viele Liebe Grüße
 
Revan335

Scheint geholfen zu haben, sind verschwunden.

Hier einmal eine Grafik, die das Konstrukt hoffentlich besser verständlich macht.

Dadurch wird verhindert, das bspw. das Backup System was an den Main Daten ändern kann, da der Zugriff nur "ro" erfolgt.
 
Trotz "ro" bei /mnt/user am Backup Pfad/luckyBackup, funktioniert der "rw" Mount von /mnt/user/Test_LB und der Pfad ist somit beschreibbar.
 
Es sieht derzeit gut aus, luckyBackup meldet keine Fehler mehr und in den Logs kann ich auch nicht mehr die Meldungen bzgl. cannot delete non-empty directory: .luckybackup-snaphots und seine Unterordner finden.
Das Aufteilen und entfernen von Include only scheint also der entscheidende Knackpunkt zu sein.
 
Vielen Dank an alle für die Unterstützung!
 
Viele Liebe Grüße
 
Revan335

Schade, das es scheinbar bei include only nicht zum gewünschten Ergebnis kommt.
 
 

Bis jetzt keine weiteren Parity oder SATA Fehler. Soweit ich das erkennen kann.
 
SATA Kabel und Strom also der Verursacher. Nach aktuellen Stand.

Hab den Punkt und die Lösung in der Doku ergänzt, da ich dieses Phänomen auch schon hatte und diesen Thread verlinkt.
 

Hab dazu auch mal ne Anleitung geschrieben:
 
 

Vermutlich wurde des Rätsels Lösung gefunden. Die Ursache allerdings noch nicht:
 

Hab im Ubuntuusers Wiki den entscheidenden Hinweis gefunden.
 
// ist für den Pfad wichtig. Entweder steht das in den Dokus von Vorta/Pika oder Borg Seiten nicht oder ich muss es über sehen haben trotz mehrfacher Prüfung.
 
ssh://borg@Unraidname:Port//backup/Clientname
 
Teste es jetzt mal weiter.