mgutt

Verstehe ich nicht. Der hat den Pfad doch kurz vorher erstellt 🤔 Sicher, dass der Pfad "Archiv" heißt und nicht "archiv"? Mal mit folgendem Kommando prüfen bitte: ls /mnt/user Bitte teste auch mal stattdessen einen Diskpfad. /mnt/user ist ja Unraid's virtueller Pfad auf alle möglichen Ziele. Nimm mal /mnt/disk1/Archiv oder welche Disk auch immer das Ziel sein soll. Ich bin von keiner Variante ein Freund, wenn man "appdata" sichert, da dort häufig Dateien drin sind, die "root" gehören und wenn man solche Dateien 1:1 sichern will, muss man auch root auf dem Ziel sein. Und das wäre ist riskant, weil ein Angreifer, der das eine Passwort knackt, gleich auch den Backupserver platt machen kann. Ich mache das komplexer, aber dafür deutlich sicherer. Ich habe einen rsync Container installiert, der rein lesend auf meine Daten zugreifen kann. Mein Backupserver verbindet sich mit diesem Container als root und kann daher die Dateien 1:1 ziehen, aber es kann niemals passieren, dass beide Server kompromittiert werden, da der Backupserver nur lesen kann und der Heimserver gar keinen Login vom Backupserver kennt. Auch kann der Backupserver die meiste Zeit aus sein, da er weiß wann das Backup fertig ist. Ich sichere übrigens appdata lokal vom Cache auf das Array, damit das Skript die Container sauber stoppt. Dh mein Backupserver holt nicht appdata direkt ab, sondern nur das Backup davon. Natürlich muss man das nicht so machen wie ich und kann ansonsten auch auf beliebige Ziele sicheren, aber das würde ich wie gesagt nur für Shares empfehlen, wo Nutzerrechte keine Rolle spielen bzw leicht repariert werden können wie zb persönliche Shares, wo Dokumente und Medien drin liegen. Und klar. SMB ist ein No Go wegen der Hardlinks. Irgendwie geht das wohl schon, aber das sollte man nur machen, wenn man es verifiziert hat.

Häh? Das bezieht sich auf SMB Shares von unRAID. Also wenn die das Ziel sind. Auf SMB sollte man sowieso niemals sichern. Dadurch gehen diverse Dateirechte verloren. Den Check habe ich selbst entwickelt. Ergänze bitte vor dieser Zeile: transfer_count=$(rsync --dry-run --itemize-changes --recursive --link-dest="$link_dest_path/link_dest" "$empty_dir/" "$dst_path/hard_link" | wc -l) Das: rsync --dry-run --itemize-changes --recursive --link-dest="$link_dest_path/link_dest" "$empty_dir/" "$dst_path/hard_link_test" Und dann brauche ich die Logs von dem Skript.

Snapshots sind keine Backups, weil sie auf der selben Partition existieren. Man kann Snapshots ja nicht auf andere Datenträger verschieben. Also kann man schon, aber dann sind sie auch nichts anderes als Backups, weil dann alle Daten 1:1 kopiert werden.

Sobald es wieder passiert die Logs posten. Die liegen dann in /boot/log, also auf dem Stick.

Spielt keine Rolle. Genauso wenig ob du den passenden Xeon holst. Hauptsache günstig. Ja das ist möglich Das be quiet! Pure Power 12 M 550W könnte eine Option sein. Aber Messwerte hat glaube ich noch keiner gepostet. Da du VMs betreiben willst und die den RAM reservieren, könnte es mit 16GB eng werden. Ich würde vermutlich 2x 32GB verbauen 😁 Wie viel Speicher belegen am Ende deine Medien? SSD Only ist vermutlich keine Option?

4K, SDR Tone Mapping und Subtitle Burn-In transcodiert der auf 1080p ruckelfrei? Dann brauche ich wohl doch ein neues Setup 🤔

Der eine testet 30 Sekundenclips und der andere hat angeblich 4K mit HDR und Untertiteln transcodiert, was nicht mal eine Nvidia GPU schafft. Ich bin skeptisch.

Der N5095 ist zu schwach für Plex: https://forums.unraid.net/topic/97626-support-plex-media-server-official/?do=findComment&comment=1304864 Das sollte auch für den N5105 gelten. Der ist ja quasi baugleich bzw sogar noch stärker in der TDP begrenzt.

Meist hilft da ein Serverneustart

Das Gewinde wird nicht gedruckt (geht so fein auch gar nicht), sondern man realisiert Taschen, wo man nachher Muttern reinsteckt. Hier sieht man so Taschen bei einem meiner Netzteilrahmen: Und hier die zwei Schrauben, die dann von oben reingeschraubt wurden: Je nachdem gibt es auch keine Hebelwirkung, weil man den Rahmen ja genauso breit wie das Netzteil machen kann. Ist nur die Frage, ob man rechts noch ein Loch am Gehäuse findet, wo man den Rahmen festmachen kann. In meinem Fall war das einfach wie man sieht, weil es zig Löcher gab. Oder meinst du allgemein wegen dem Gewicht des Netzteiles und weil es soweit absteht vom Rahmen? Gut, da hilft wie in meinem Fall natürlich der massive Druck. Also mit 2mm Dicke geht das natürlich nicht. Ich brauchte den Rahmen übrigens, weil ich ein Corsair Shift Netzteil verbauen wollte, was in dem Gehäuse nicht vorgesehen war: https://www.computerbase.de/forum/threads/mechanic-master-c26-deutlich-kleiner-als-worlds-smallest-matx-sliger-cerberus.1985999/post-28307462

Ich hatte jetzt den ganzen Halterahmen mit dickem ABS nachgebaut, so dass er nach rechts exakt die Schraubpunkte vom Netzteil abdeckt. Also unter das Netzteil kommt dann nichts. Das mit den Legosteinen meinte ich nur, um die passenden Abmessungen des Halterahmens zu ermitteln. Aber du machst das schon 😁

This shouldn't work as the movie itself has a complete different inode id on a complete different device (disk in array).

Noch mal: Hinlegen, nicht stellen. Dh das Netzteil schwebt über RAM und teilweiss der CPU und natürlich auch dem USB Kram. Dir fehlt dann nur der passende Halterahmen. Testweise halt mit Legosteinen die Höhe festlegen und dann abmessen und mit dem 3D Drucker einen passenden Halterahmen realisieren.

Und außer der Fehlermeldung kommt dann kein normaler Eintrag mehr?

Sowas darfst du ruhig in gekürzter Form posten. #scrollenohneende

Hier hat zufällig jemand das selbe Problem: https://forums.unraid.net/topic/145100-build-report-jonsbo-n3-cwwk-j6413-soc/ Könnte man es nicht umdrehen und einen sehr flachen CPU Kühler verbauen? Müsste man sich natürlich was wegen der Halterung überlegen.

Da fehlen sie ganzen Devices. Komisch. EDIT: Ok. Hier was gefunden: https://unix.stackexchange.com/a/368333/101920 Also ergänze bitte mal -M beim ursprünglichen Kommando. Ich vermute dann geht es wieder.

Da fehlen die Infos zum PCIe Link. Probier mal -vvv oder -vvvv ob dann was mit ASPM auftaucht. Dann müssen wir den ersten Befehl nur entsprechend um die v's erweitern.

Jetzt bin ich aber gespannt mehr zu hören 😁 Vielleicht ist es ja so, dass in C10 diese Werte gar nicht mehr ausgelesen werden können?! Wäre mir jetzt auch neu, aber wer weiß. Mit lspci -vv kannst du dir alles ausgeben lassen und schauen, ob die Geräte in der Zeile, wo eigentlich ASPM stehen sollte nun was ganz anderes stehen haben.

Check the container logs

While accessing the local IP of Plex or do you have a domain / reverse proxy in front of your Plex container?

Ich persönlich finde solche Peaks absolut uninteressant. Für die Ermittlung der Netzteilleistung beim Kaltstart eines Servers vielleicht interessant, aber bei alltäglichen Messungen ist mir der Millisekunden Peak echt egal. Ich will dann bewusst den Durchschnitt der letzten Sekunden. Ansonsten hab ich nachher ein Fazit, dass ein Gerät 5 bis 50W verbraucht, obwohl es zu 99% bei 25W hängt. Und ich würde schon sagen, dass der selbst deutlich häufiger misst, denn wenn ich den Server neustarte, ist der Maxwert immer ähnlich. Würde er wirklich nur alle 10 Sekunden messen, müsste ich entweder kaum was sehen (wenn Sekunde 1 bis 8 der Start war) oder den extremen Peak (wenn Sekunde 9/10 der Start war).

>keine neu hinzugefügten ... nicht Na dann läuft's ja 😁

Dann mach das doch mal 😉 Öffnest du Nextcloud über die Domain oder lokale IP? Letzteres geht nicht über den Proxy und der Check muss daher fehlschlagen. Ruf doch einfach mal die komplette URL mit deiner Domain auf um zu sehen was passiert.

Fritz!DEC 200 und das Diagramm sieht man dann direkt auf der Weboberfläche der Fritz!Box. Die DECT 200 misst sehr genau, ist aber auch teuer.