alturismo

bei mir war es jetzt relativ einfach da Server und Gaming im selben Raum ist zu deinen Fragen Kabel ... naja, selbsterklärend aber bei so einer Verlängerung ... wird das wahrscheinlich kritisch. Alternative, USB Manager mit USB IP ... sprich, im Wohnzimmer ein Gerät (RPi, ...), dort USP IP verbinden mit UNRaid und damit dann Bluetooth realisieren ... siehe dazu den passenden USB Manager Thread.

perfekt ok, dann ... weißt du ja jetzt warum dem so ist bei zfs (oder btrfs) wo scrub nutzen. War mir auch nicht bewusst, aber ich nutze zfs nicht da genau die ganzen Dinge Sachen auslösen die man normal nicht will

mit was erstellst du Backups und wohin hast du die kopiert ... dort findest du auch deine Backups. mit GROßBUCHSTABEN wird es nicht besser ... im Gegenteil, viele werden dich dann eher ignorieren ... im Grundsatz und den bisherigen Fragen zu "sicher, sicherer, am sichersten, ..." wundert mich deine Vorgehensweise schon etwas den Server "extern" zu setzen, naja, egal jetzt, um mal den login zu prüfen ... da du nicht mehr auf den Server kommst. 1/ ausschalten 2/ Stick abziehen 3/ den Stick an einen Rechner deiner Wahl anschließen 4/ Inhalt von /config kopieren 5/ poste mal den Inhalt von ident.cfg, network.cfg dann kann eher jemand etwas dazu sagen ... durch die Aktivierung von SSL versucht der Server jetzt wahrscheinlich immer auf SSL zu routen mit der externen unraid domain ...

@Tremendous anscheinend hast du das selbst getriggert ... wenn dem so war ... jetzt wundere ich mich ... warum 1/ du das nicht angibst 2/ du dich wunderst dass die disks laufen ...

Trim ist klar dass dies nicht supported ist, scrub ... hmm ... @Tremendous du hast aber nicht manuell einen scrub ausgelöst ?

welche Docker laufen denn ? Ansatz, mal nach und nach abschalten, spindown manuell ausführen ob einer davon das auslöst ... und wenn zfs ... das hat halt seine Eigenarten, wobei es auch mich wundert ...

zeig mal den output von ls -la /mnt/user0/ da werden dir roots von allen Array Shares angezeigt ... sollte /appdata /system /domains ... drauf liegen, sollte der Rest selbsterklärend sein

hatte ich ganz übersehen also, von alleine löscht sich ja nichts, sprich, irgendwas hat ... oder irgendwer ... was du mal schauen kann, in NC mal unter gelöschten Dateien geschaut ?

dazu braucht es auch das UAD plus addon ... inkl. destructive mode (löschen, formatieren, ...) zu deinem workflow, wenn die disk sich "abmeldet" und dann wieder kommt ... wird die ziemlich sicher im Docker nicht remountet. Kannst folgendes mal schauen 1/ den mount dazu als slave setzen << könnte helfen ... 2/ luckybackup per script neu starten nachdem die externe disk on und mountet ist ... UAD kann auch scripts ausführen oder per userscripts nach Zeitplan.

Hardware ist sicherlich nicht auszuschließen ... aber btrfs ist (leider) hier auch öfters komplett in die Knie gegangen, bis zu dem Tag an dem ich (Idiot) mal blank (ohne Backups) stand ... das war dann das endgültige Aus hier ... und wenn du danach suchst ... wirst du einiges zu btrfs und Problemen lesen.

1/ screen / Übersicht machen der Docker, Docker und VM Dienst stoppen 2/ alles wegsichern sofern möglich (außer ../system/docker/.... macht keinen Sinn 3/ Platten neu formatieren und einrichten 4/ Backup retour spielen 5/ Docker und VM Dienst wieder starten (docker image / folder wird neu erstellt, ..system/docker/...) 5/ Docker neu installieren aus previous apps oder docker tab, add container, user templates ... alle Startparameter sind vorhanden /liegen auf dem Flash), persistent appdata waren dann ja gesichert / retour ... sprich, alles wie vorher und nix verloren

naja, es fängt mit btrfs Ausstiegen an ... Apr 28 10:01:51 NiMora kernel: nvme nvme0: Device not ready; aborting reset, CSTS=0x3 Apr 28 10:01:51 NiMora kernel: nvme nvme0: Removing after probe failure status: -19 Apr 28 10:01:51 NiMora kernel: nvme nvme1: Device not ready; aborting reset, CSTS=0x3 Apr 28 10:01:51 NiMora kernel: nvme nvme1: Removing after probe failure status: -19 Apr 28 10:01:51 NiMora kernel: nvme0n1: detected capacity change from 1953525168 to 0 Apr 28 10:01:51 NiMora kernel: nvme1n1: detected capacity change from 2000409264 to 0 Apr 28 10:01:51 NiMora kernel: BTRFS error (device nvme1n1p1): bdev /dev/nvme1n1p1 errs: wr 2, rd 0, flush 0, corrupt 0, gen 0 Apr 28 10:01:51 NiMora kernel: BTRFS error (device nvme1n1p1): bdev /dev/nvme0n1p1 errs: wr 1, rd 0, flush 0, corrupt 0, gen 0 Apr 28 10:01:51 NiMora kernel: BTRFS error (device nvme1n1p1): bdev /dev/nvme0n1p1 errs: wr 2, rd 0, flush 0, corrupt 0, gen 0 Apr 28 10:01:51 NiMora kernel: BTRFS error (device nvme1n1p1): bdev /dev/nvme1n1p1 errs: wr 3, rd 0, flush 0, corrupt 0, gen 0 Apr 28 10:01:51 NiMora kernel: BTRFS error (device nvme1n1p1): bdev /dev/nvme0n1p1 errs: wr 3, rd 0, flush 0, corrupt 0, gen 0 Apr 28 10:01:51 NiMora kernel: BTRFS error (device nvme1n1p1): bdev /dev/nvme1n1p1 errs: wr 4, rd 0, flush 0, corrupt 0, gen 0 Apr 28 10:01:51 NiMora kernel: BTRFS error (device nvme1n1p1): bdev /dev/nvme0n1p1 errs: wr 4, rd 0, flush 0, corrupt 0, gen 0 Apr 28 10:01:51 NiMora kernel: BTRFS error (device nvme1n1p1): bdev /dev/nvme1n1p1 errs: wr 5, rd 0, flush 0, corrupt 0, gen 0 Apr 28 10:01:51 NiMora kernel: BTRFS error (device nvme1n1p1): bdev /dev/nvme0n1p1 errs: wr 5, rd 0, flush 0, corrupt 0, gen 0 Apr 28 10:01:51 NiMora kernel: BTRFS error (device nvme1n1p1): bdev /dev/nvme1n1p1 errs: wr 6, rd 0, flush 0, corrupt 0, gen 0 Apr 28 10:01:51 NiMora kernel: BTRFS: error (device nvme1n1p1) in btrfs_commit_transaction:2494: errno=-5 IO failure (Error while writing out transaction) Apr 28 10:01:51 NiMora kernel: BTRFS info (device nvme1n1p1: state E): forced readonly Apr 28 10:01:51 NiMora kernel: BTRFS warning (device nvme1n1p1: state E): Skipping commit of aborted transaction. Apr 28 10:01:51 NiMora kernel: BTRFS: error (device nvme1n1p1: state EA) in cleanup_transaction:1992: errno=-5 IO failure Apr 28 10:01:52 NiMora kernel: traps: brave[13543] trap invalid opcode ip:55a6d2d877f9 sp:7ffca1cda1d0 error:0 in brave[55a6cdc34000+951a000] Apr 28 10:01:53 NiMora kernel: traps: brave[13631] trap invalid opcode ip:55efb86c57f9 sp:7ffd4039a2e0 error:0 in brave[55efb3572000+951a000] Apr 28 10:01:54 NiMora kernel: traps: brave[13696] trap invalid opcode ip:55aff46827f9 sp:7fff03b3ea60 error:0 in brave[55afef52f000+951a000] und das Ende wiederholt sich bis zum Ende ... bei btrfs gibt es von mir persönlich nur eins, weg davon ... wenn du ein raid1 pool nutzt dann teste mal den Umstieg auf zfs ... single cache immer xfs, aber du hast ja 2 drives ... dann wäre aktuell zfs einen Versuch wert.

für die Zukunft (bringt hier ja leider nichts mehr), lös die Probleme anstelle zu versuchen die zu "umkurven" ...

denk mal drüber nach ... die Parity läuft in Echtzeit und passt die bei jeder Aktivität mit an, daher auch die reduzierte Schreibgeschwindigkeit ... es ist kein Backup

die Ansage dass die zu warm wird lässt sich lösen ... aber ich bin verwundert dass dies Auswirkungen hat weil eine nvme bei 45 Grad erst warm wird ich stelle die nvme erst ab 68° zur Warung ein ... aber du solltest dir eher Gedanken machen warum deine bei 45° in die Knie geht ... @Ford Prefect war schneller

Nein, Parity ist kein Backup, Parity ist Redundanz der vorhandenen Daten bei einem Ausfall einer / zweier Platten (je nach setup) ...

exakt ... und von alleine "verschwinden" keine Daten ... entweder waren Sie nie da oder "was auch immer" hat die gelöscht ... immer noch ...

das sollte auf 99 100 stehen wird von dem Docker nicht unterstützt, daher kannst du dir das schenken, macht aber keinen Unterschied ... du hast ja anscheinend schon etwas gelesen und ich schätze daher kommen solche Einträge, Hintergrund, der Docker muss das auch "können", meist in der Dokumentation was es an Variablen gibt usw ... hier dann https://www.tinymediamanager.org/docs/docker also, UID, GID 0 0 wäre root, das sollte im Docker gut gehen ... aber 99 100 wäre "normal" dass die Medien und Dateien nicht evtl. nur für root zur Verfügung stehen. dann fehlen dir auch ein paar mounts würde ich sagen ... zumindest data zu appdata und ein Media Share ... also, nochmals schauen was eigentlich unterstützt wird, sauber einstellen, uid gid wäre 99 100 zu empfehlen, usw usw ...

bevor du anfängst wild Rechte neu zu setzen zeig mal deinen docker run <<klick<< command von TMM dann mal ein Beispiel wo die Medien liegen wo das nicht funktioniert Beispiel, output von ls -la /mnt/user/Media/TVRIPS dann kann man eher was dazu sagen ... die smb settings sind relevant wer, wie ... per smb darauf Zugriff hat, der TMM läuft ja auf dem Docker mit direktem Zugriff ... das kommt später wenn wir darüber nachdenken warum es so ist wie es ist ...

ajo ganz genau alles gut @DataCollector ich hab mich vertan weil ich dachte die ssd war im array, war sie nicht ... darauf bezogen geht nunmal kein "parity is valid" ... auch alles gut.

dann zeig doch mal die Rechte wo es nicht geht ... dann stell dir die Frage wie kommen die Dateien dahin und wie die Rechte vergeben werden ... Dann kann man ggf. helfen, entweder "stumpf" vorher die Rechte ändern oder beim "Vorgang" gleich alles richtig machen

ei ei ei ... wo willst du denn die Dokumente haben ? hast du dir ein Share erstellt für Dokumente ? hast du dir in einem vorhandenen Share einen Ordner erstellt für deine Dokumente ? ... und dorthin mountest du dann Beispiel, ich nutze einen Share Dokumente und einen separaten import Pfad ... export gar nicht da ich eh sichere ... jetzt hast du beide Beispiele vereint, eigener Share, Ordner in einem vorhandenen Share ... wenn du dein o.g. Beispiel nutzt, liegen die Daten später im appdata Ordner, wenn das ok ist kannst du das auch so machen ... aber nicht wenn was nicht passt aus Versehen den ganzen appdata/paper... löschen, dann sind auch deine Dokumente weg.

da liegt dein Fehler, pass die mal ordentlich an und dann sollte das auch gehen ... /mnt/usr/src/.... ist sicher nicht dein Share auf Unraid ...

zumindest ein paar mehr Infos geben oder im paperless Forum, github, ... nachfragen ... wie sieht der docker run << klick aus, wie ladest du wohin hoch, was sagt das paperless log aus ... usw usw ...