mgutt

Alles ist natürlich nicht read-only. 1.) Habe ich normale User Shares mit Schreibrechten, wo Daten vom Client manuell ausgelagert werden (Videos etc). Diese Shares sichere ich inkrementell auf eine separate Platte im Array ohne SMB Zugang. Diese Daten sind also nur sicher, solange der Server nicht gehackt wird. 2.) Alle anderen Shares wie Filme, Musik, (alte) Fotos, etc sind read-only. Auch hier darf der Server nicht gehackt werden. Und davon sprach ich in meinem vorherigen Beitrag: 3.) Alle Windows-Clients besitzen einen zweiten read-only User namens "backup". Über diesen User mounte ich den Client in unRAID und lasse dort das Backup vom Client erstellen. Das ist sicher, wenn der Client ODER der Server gehackt wird. Wenn beide gehackt werden, hat man verloren. 4.) Um auch bei einem gehackten Server sicher zu sein (und gegen Einbruch, Feuer, etc), habe ich einen Remoteserver. Der greift ebenfalls nur über einen read-only User zu. Ich verstehe aber, dass das nicht jeder zB aus Kostengründen umsetzen kann. Fazit: Man muss sich Gedanken darüber machen wer alles auf welchen Wegen auch immer Schreibrechte besitzt und diese möglichst vermeidet. Einfach nur eine Backup-Software auf dem Client haben, die aufs NAS sichert, ist jedenfalls keine sinnvolle Methode.

Deswegen sichere ich alle Container inkrementell auf eine HDD im Array. Container können nur das verändern wo sie Rechte für besitzen. Also die Pfade, die in den Einstellungen hinterlegt sind. Deswegen ist bei mir Krusader auch dauerhaft aus. Ein Container mit Schreibrechten auf /mnt besitzt viel zu viel Macht. Plex hat bei mir zb ausschließlich lesende Rechte auf die Filme.

Du hast den Client mit seinen Daten und den Server. Wird eines von beiden gehackt, sind die Daten noch auf dem jeweils anderen. Da der eine nicht auf den anderen schreiben kann, kann er auch nichts verschlüsseln. Wird also der Client gehackt, kann er nicht das Backup verschlüsseln. Wird der Server gehackt, kann er nicht den Client verschlüsseln. Ob nun ein Virus vom Client in einem Backup auf dem Server steckt ist völlig irrelevant, weil du Dateien aus dem Backup ja nicht auf dem Server ausführst (und nein, das kann nicht einfach so passieren, schon gar nicht unter Linux). Du darfst dich natürlich nicht mit dem Client auf dem Server zb per root anmelden. Den Login könnte bei einem gehackten Client mitgelesen werden. Außerdem besteht natürlich die geringe Wahrscheinlichkeit, dass der Client gehackt wird, während der Server auch eine Sicherheitslücke besitzt. Genau deswegen gilt in der Industrie die 3-2-1 Backupregel: 3 Kopien auf mindestens 2 verschiedenen Datenträgern und 1 Kopie an einem externen (Offline) Standort. Wie viel man davon nun privat umsetzt, muss natürlich jeder selbst entscheiden. Ob Lucky Backup root hat (hat es nicht, weil Container), spielt keine Rolle, weil das ja auf dem Server stattfindet, der dem Client nichts anhaben kann. Hat Lucky Backup eigentlich User Logins? Wenn nein, wäre Lucky Backup sinnlos, weil der Angreifer ja nur auf die GUI wechseln müsste um die Backups zu löschen.

Alter Stick... Neuer Stick. Ich versteh nur Bahnhof. Warum gehst du nicht einfach auf die Website?! https://forums.unraid.net/my-servers/ Kannst du da das Backup vom alten Server herunterladen oder nicht? Wenn nein, dann Support kontaktieren. Das Backup vom neuen Server nützt dir doch nichts. Da ist doch keine Lizenz für erworben worden?! Wenn du ein altes Backup hast, dann das auf dem Stick wiederherstellen und fertig. Willst du nun unbedingt den neuen Stick mit seinen Dateien behalten, dann extrahiere dir aus dem alten Backup die Schlüsseldatei. Ist im Verzeichnis Config und endet auf .key

unRAID erlaubt nur ein Array. Daher ginge nur als UD mounten

Das geht auf keinen Fall, weil die Parity die größte Disk sein muss. Ist zwar asozial, aber es gäbe noch die Option Widerrufsrecht.

Ist in meinem ersten Link erklärt.

Nein. Die Parity muss die größte Platte bilden. Keine Ahnung ob man in dem Zustand mit einer zweiten 18TB Parity die ersten 4TB Parity ausbauen könnte, während das Array emuliert wird?!

1,3W pro Lüfter (12V x 0,11A) Aber nur bei Vollgas. Aber die Mellanox aus deiner Signatur war nicht verbaut oder?

So funktioniert WoL nicht. So funktioniert WoL. 🤷

Nein. Siehe auch: https://forums.unraid.net/topic/99393-häufig-gestellte-fragen/?do=findComment&comment=1021986 Deswegen haben alle meine Shares nur Leserechte bzw temporäre Schreibrechte: https://forums.unraid.net/topic/116555-smb-share-auto-write-protection/ Außerdem mounte ich alle Windows PCs in unRAID über einen Windows User mit Leserechten und sichere die Dateien auf einen Share ohne SMB Rechte mit diesem Skript: https://forums.unraid.net/topic/97958-rsync-incremental-backup/ Gegen Ransomware hilft nur das rein lesende Abhol-Konzept.

Naja war der Brenner per SATA verbunden oder nicht? Das Powerkabel alleine hat ja keinen Einfluss auf die C-States?! Und zu den 18W: Naja immer noch mies würde ich sagen. Aber jetzt sag morgen nicht, dass du ein Hot Swap Gehäuse und 5 RGB Lüfter "vergessen" hast 😅 Also im Ernst. Wenn du jetzt C8 hast, dann kann doch nur noch dein Messgerät schlecht sein, das Netzteil oder du hast immer noch großartige Verbraucher, die nichts mit den Lanes zu tun haben.

Klingt komisch. Der Ordner ist jedenfalls nicht persistent, sondern im RAM und beim Neustart daher weg.

Dein Ernst? Du "übersiehst" einen Brenner 🧐

Das kannst du dir sparen. Die alte Version zeigt grundsätzlich falsche überhöhte C-States an, weil die neuen CPUs nicht erkannt werden. Mit der alten habe ich zb durchgehend C9.

Ich nutze dafür manuell erstellte Shares über Settings > SMB > SMB Extra. Beispiel: [Nginx-Proxy-Manager] path = /mnt/user/appdata/npm/data/nginx valid users = marc read list = write list = marc force user = root Auf die Art schreibt mein Nutzer marc mit root-Rechten.

Du entfernst nur den Haken in Nerd Tools powertop ist auch nur eine Anwendung und kein Dienst. Anwendungen haben in Linux keinen Einfluss auf sonstige Prozesse. Ob sie da sind oder nicht, spielt daher keine Rolle.

Die hat er aber trotzdem. Der Container selbst hat nur intern keine entsprechende Einstellung gesetzt, dass diese IP in Unraid angezeigt wird. Nützt dir aber alles nichts, denn wenn der Minecraft Container eine br0 IP hat, ist er ja nicht über die IPv6 erreichbar auf die feste-ip.net verweist. Er hat dann eine komplett neue IPv6. Und ich habe das auch noch nicht geschafft so einzustellen, dass das bei einer Internet-Neuverbindung noch läuft. Was du aber probieren kannst ist in NPM einen Stream-Host anzulegen. Der Stream-Host leitet alles 1:1 durch. Minecraft bleibt dann in Bridge, bekommt dann aber zB 25566 als Port und in NPM stellst du eingehend 25565 ein und leitest auf die IP von Minecraft plus 25566 weiter: Bei Stream-Hosts gibt es übrigens keine Domains. Alle deine Domains, sei es plex.example.com:25565 oder nextcloud.example.com:25565 funktionieren dann für Minecraft.

Du könntest versuchen den anderen LAN-Port zu deaktivieren. Laut Anleitung ist das LAN2: Außerdem könntest du Audio deaktivieren: Zuletzt hätte ich dann noch probiert: - Ist unter Peripherals > SATA > Aggressive LPM Support aktiviert? - SATA Mode steht auf AHCI oder RST (nur aus Interesse)? - Peripherals > Network Stack deaktivieren - Peripherals > Serial Port deaktivieren - Peripherals > Super IO deaktivieren - Peripherals > Serial Port Redirection deaktivieren - Power > PEG, PCH und DMI ASPM alle aktiv? - Power Loading > Am besten auf Auto lassen, ich hatte mal bei meinem Board disabled probiert und es hatte den enabled Effekt ^^

A friend of mine had this problem and I tried many things to bypass this problem without rebooting, but I was not successful. As the others posted, these commands don't return anything: root@Tower:~# fuser -s "/mnt/user/system/libvirt/libvirt.img" root@Tower:~# losetup -j "/mnt/user/system/libvirt/libvirt.img" But the libvirt.img is still attached as block device (even after the VM service has been stopped): root@Tower:~# losetup -l NAME SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE DIO LOG-SEC /dev/loop1 0 0 1 1 /boot/bzmodules 0 512 /dev/loop2 0 0 1 0 /mnt/cache/system/libvirt/libvirt.img 1 512 /dev/loop0 0 0 1 1 /boot/bzfirmware 0 512 root@Tower:~# losetup -a /dev/loop1: [2049]:11 (/boot/bzmodules) /dev/loop2: [66305]:536871053 (/mnt/cache/system/libvirt/libvirt.img) /dev/loop0: [2049]:9 (/boot/bzfirmware) root@Tower:~# dmsetup info No devices found Nothing is using this loop device as all commands return nothing: fuser -c /dev/loop2 fuser -f /dev/loop2 lsof | grep loop2 No error detaching the block device: losetup -d /dev/loop2 dmsetup fails as well: root@Tower:~# dmsetup remove --force loop2 device-mapper: table ioctl on loop2 failed: No such device or address device-mapper: reload ioctl on loop2 failed: No such device or address device-mapper: remove ioctl on loop2 failed: No such device or address I was able to mount/read/unmount it: root@Tower:~# fdisk /dev/loop2 -l Disk /dev/loop2: 1 GiB, 1073741824 bytes, 2097152 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes root@Tower:~# blkid | grep loop2 /dev/loop2: UUID="2791640b-f2f7-4b5d-be92-b7715a2268b7" UUID_SUB="73b862f5-df27-432d-9f14-d46bdffe239f" BLOCK_SIZE="4096" TYPE="btrfs" root@Tower:~# mkdir /mnt/disks/libvirt root@Tower:~# mount /dev/loop2 /mnt/disks/libvirt root@Tower:~# ls /mnt/disks/libvirt/ hooks/ qemu-lockd.conf virtlockd.conf virtqemud.conf libvirt-admin.conf qemu.conf virtlogd.conf virtsecretd.conf libvirt.conf secrets/ virtnetworkd.conf virtstoraged.conf libvirtd.conf virt-login-shell.conf virtnodedevd.conf nwfilter/ virtchd.conf virtnwfilterd.conf qemu/ virtinterfaced.conf virtproxyd.conf root@Tower:~# mountpoint /mnt/disks/libvirt /mnt/disks/libvirt is a mountpoint root@Tower:~# umount /mnt/disks/libvirt root@Tower:~# rmdir /mnt/disks/libvirt Deleting the file does not help: root@Tower:~# cp -a /mnt/cache/system/libvirt/libvirt.img /mnt/cache/system/libvirt/libvirt.img.copy root@Tower:~# rm /mnt/cache/system/libvirt/libvirt.img root@Tower:~# losetup -l NAME SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE DIO LOG-SEC /dev/loop1 0 0 1 1 /boot/bzmodules 0 512 /dev/loop2 0 0 1 0 /mnt/cache/system/libvirt/libvirt.img (deleted) 1 512 /dev/loop0 0 0 1 1 /boot/bzfirmware 0 512 Later I found a method to get more verbose output, but I'm not sure if "No such file or directory" was returned as I deleted the file?! root@Tower:~# LOOPDEV_DEBUG=all losetup -vd /dev/loop2 31598: loopdev: CXT: [0x7ffe409acdd0]: initialize context 31598: loopdev: CXT: [0x7ffe409acdd0]: init: ignore ioctls 31598: loopdev: CXT: [0x7ffe409acdd0]: init: loop-control detected 31598: loopdev: CXT: [0x7ffe409acdd0]: /dev/loop2 name assigned 31598: loopdev: CXT: [0x7ffe409acdd0]: open /dev/loop2 [ro]: No such file or directory 31598: loopdev: CXT: [0x7ffe409acdd0]: device removed 31598: loopdev: CXT: [0x7ffe409acdd0]: de-initialize 31598: loopdev: CXT: [0x7ffe409acdd0]: closing old open fd 31598: loopdev: ITER: [0x7ffe409acfa8]: de-initialize So the next user which has this problem should try to execute those two commands (while VM service has been stopped), loopX must be replaced by the output of "losetup -l": losetup -l LOOPDEV_DEBUG=all losetup -vd /dev/loopX By that we can verify if it's "No such file" in any case. Another thing which I was not able to test is to stop the array and to check how it does influence the "losetup -l" output. And the next time I like to test if the installation of kpartx and the command "kpartx -d /dev/loopX" could help.

Der linke ist LAN2 und läuft über einen extra Controller. Ich würde den rechten nehmen. Außerdem mal ohne USB Platte testen.

Die erste GPU ist die primäre Karte. Die nimmt sich unRAID. Die zweite Karte wird von gar nichts genommen. Die ist also im Betriebsmodus und wartet darauf, dass sie per Treiber angesprochen wird. Daher die zweite an VFIO binden und dann zb an eine Ubuntu VM binden und diese starten. Ohne VM ist die GPU wieder heimatlos und dreht auf.

Korrekt

Backup wiederherstellen und damit booten. Rest geht automatisch.

Follow the "Debug Errors" steps: https://forums.unraid.net/topic/110245-support-nginx-proxy-manager-npm-official/#comments