mgutt

Ja. Aber nur wenn ich die Shares alle manuell erstelle. Wobei dann wieder die Frage ist wegen Speed. Ich brauche dafür eigentlich ein separates SSD Array.

Ich brauche echt mehr Platten. Dann kann ich auch auf Disk Shares umstellen. 😋

Ja aber das belegt doch, dass es geht. Würde es erst zu deinem Laptop gehen und dann zurück, wäre es ja deutlich langsamer.

Hast du denn 10G Anbindung? Weil von Disk zu Disk sind doch 160 MB/s passabel. Wobei ich das schon echt viel finde. Du hast doch eine Parität?!

Ich habe gestern meinen Cache ersetzt. Beim Heruntergefahren hing der Server und das Erstellen der Diagnose nahm kein Ende. Also habe ich hart abgeschaltet. Seitdem kann ich mich mit keinem SMB User mehr anmelden, außer ich ändere das Passwort in das eigentlich bereits existierende?! Weiß jemand wo die SMB Passwörter gespeichert werden oder wie könnte ich dahinter kommen, was hier los ist? Noch habe ich nicht alle Passwörter "geändert".

The root password is only visible on the very first start. You started the container twice or installed it again without removing the appdata folder of MariaDB. A) If you don't have any data in the db, then remove the container and use the appdata cleanup plugin to remove the mariadb appdata folder: Then install the container again and check the logs directly. The password will be visible: B) If you already have data in the db, then change your root password. The method is described here: https://forums.unraid.net/topic/110019-support-mariadb-official/?tab=comments#comment-1004285 Note: You get the best performance if you change the paths of your db to /mnt/cache...:

Du hast "https" im Browser eingegeben? Weil deine Regel umfasst nur Port 443. "http" wird entsprechend nicht gehen. Öffne die Konsole von Swag und führe eines der beiden Kommandos aus um zu testen ob du nextcloud über den Hostnamen nextcloud erreichen kannst: ping nextcloud curl nextcloud Du solltest übrigens darüber nachdenken den Original Nextcloud Container zu verwenden (knex666 ist der Maintainer). Es macht nämlich wenig Sinn, dass SWAG mit Nextcloud über Port 443, also verschlüsselt, kommunizieren muss. Verursacht nur unnötig CPU Last.

Jo Das wäre das Optimum. Bei einer Kaufberatung weisen wir auch immer darauf hin, dass man auch gleich das passende Mainboard kauft: https://forums.unraid.net/topic/99393-häufig-gestellte-fragen/?tab=comments#comment-1021228 Daran solltest du auch nichts ändern. Das wäre dein Backup. Eine Parität wäre dagegen für die Ausfallsicherheit, also wenn eine Disk kaputt geht. Der Unterschied ist, dass wenn jemand deine Dateien löscht, dass du dann eine Kopie der Dateien auf deiner Backup-Platte hast und sie wiederherstellen kannst. Die Parität hilft dagegen nicht bei gelöschten Dateien, da sie nur den aktuellen Ist-Zustand gegen Ausfälle schützt. Daher kann man sagen, dass eine Parität eher Luxus ist. Sie soll einfach nur gewährleisten, dass das System trotz kaputter Platte weiter läuft. Damit verschlechterst du deine Backup-Sicherheit. Sagen wir mal, du hast einen Trojaner auf dem PC und ein Angreifer liest dein Unraid Passwort mit. Jetzt meldet er sich unbemerkt an und schreddert beide Platten. Was dann? Auch wenn es unbequem ist, gilt ein Offline-Backup immer noch als das sicherste überhaupt. Am besten sogar an einem anderen Standort, damit man zusätzlich noch den Schutz gegen Feuer und Einbrecher hat.

Das ist mir vorher gar nicht aufgefallen, dass die so stark bei 4K sind. Allerdings ist das mit Vorsicht zu genießen. Seagate macht das wie bei SMR HDDs, in dem zufällige Schreibprozesse nicht zufällig, sondern sequentiell auf eine separate Spur geschrieben werden: https://www.seagate.com/www-content/product-content/enterprise-hdd-fam/exos-x-16/en-us/docs/100855248a.pdf Wenn der Bereich vollgeschrieben wurde, verpufft der Vorteil natürlich sofort wieder. Ist die Frage wie groß der wirklich ist. Erstaunlich, dass genau das natürlich keiner getestet hat.

Ja also Option wäre super. Dann muss man nicht googlen. Einfach auf "false". Passwortschutz direkt als Variable wäre auch super. Da passiert dann komischerweise einfach gar nichts (also root = false und dann irgendeinen appdata Ordner löschen, wo es mehr Rechte braucht). NOVNC_RESIZE steht bei mir auf remote, falls du das meinst. Erst wenn ich root auf false setze, passt die Auflösung wieder.

Von disk1 auf disk2 geht nicht?

Nein. HDDs kommen ins Array als Disk 1, Disk 2 etc und die SSD kommt in einen separaten Pool. Das macht man deswegen, weil man im Array normalerweise eine Paritäts-HDD verwendet, um das Array zu schützen (hast du noch nicht?!) und diese verlangsamt das Array auf 40 bis 100 MB/s. Entsprechend langsam wäre dann auch die SSD, was natürlich keiner haben will. Daher packt man die SSD in einen separaten Pool. Allerdings auch hier vorzugweise zwei SSDs im RAID1, damit man auch hier eine Ausfallsicherheit hat. Wie sieht es hier mit deiner Planung aus? Man kann auch regelmäßig Backups von der SSD ins Array machen. Ist dann aber eben zeitversetzt.

Warum ist das eigentlich nicht Standard? Habe mich gerade gewundert, dass ich was nicht löschen konnte. Fehler bekommt man auch keine zurück, obwohl eine Löschaktion nicht ausgeführt wird (und in den Container Logs steht auch nichts). Übrigens wird die eingestellte Auflösung nicht gesetzt, wenn man als Root aktiv ist:

Dass das vorkommen kann, ist mir ja durchaus klar, aber bei CPUs und SSDs ist das doch bekannt. Kennt man ja aus verschiedenen Rezensionen, dass sogar Aufkleber getauscht werden. Aber einfach gar keine SSD in der Packung... Also entweder hat sich ein Mitarbeiter bedient oder die hatte schon mal jemand als WHD gekauft und es wurde nicht bei der Rückgabe kontrolliert. Da hat nämlich auf jeden Fall jemand versucht den Klebestreifen abzumachen und insgesamt waren mindestens zwei verschiedene Klebestreifen drauf. Also mehr als 1x verschlossen worden.

Upgrade 😁 Leider Normalpreis, aber ich brauchte einfach mehr Platz. Übrigens habe ich erst über Amazon Warehouse gekauft. Da kam, ohne Witz, eine leere Verpackung an. Ich schlage mich jetzt mit Amazon herum, dass ich kein Lügner bin. Total geil. 😒 Noch was neues: Ich werde ab Mittwoch eine neue Arbeitsstelle antreten. Das heißt dann weniger Zeit fürs Forum. 🙈

Eigentlich nicht. SMB erkennt, dass Quelle und Ziel auf dem selben Server liegen und verschiebt dann unabhängig von der Netzwerk-Geschwindigkeit des Laptops direkt auf dem Server. Ich habe allerdings wieder vergessen bei welchen Pfaden das nicht geht @hawihoney wo ging das noch mal nicht? 😅

Wenn ich ZSTD richtig verstehe, dann ist das ja einfach nur ein besonders schnelles Archiv. Also für einzelne Dateien. Da sehe ich jetzt keinen Ansatz, wie ich das verwenden könnte. Aber ZRAM sieht interessant aus. Kann man /dev/zram0 dann auch ohne /swapfile nutzen, also ohne in Unraid allgemein Swap aktivieren zu müssen? Im Netz wird meist beides zusammen erwähnt.

This is a very special use case when you only need to run small and temporary containers with small disk usage and don't want to use your Array Disks (HDDs). Note: The RAM-Disk, all containers, their data and docker.img are lost after reboot / power-outage. So you maybe want to add the code to your Go-File to automatically re-create the RAM-Disk on reboot. Of course the containers will be still lost. This means, this guide is only useful for containers which contain tools for temporary usage. Feel free to use a persistent appdata path, but of course the containers will be re-downloaded on every reboot. In this example we use a 2GB RAM Disk (change count=2000 if you need more): mkdir -p /mnt/disks/docker/appdata mkdir /mnt/disks/docker/service mount -t ramfs ramfs /mnt/disks/docker/appdata/ dd if=/dev/zero of=/mnt/disks/docker/appdata/docker.img bs=1M count=2000 mkfs.xfs /mnt/disks/docker/appdata/docker.img mount -o loop /mnt/disks/docker/appdata/docker.img /mnt/disks/docker/service Now /mnt/disks/docker/appdata/ is a RAM-Disk. In this path we created a 2GB xfs-formatted docker.img file, which is mounted on /mnt/disks/docker/service. By that we need to change the docker settings as follows: After installing a "jlesage/mkvtoolnix" container, it returns the following usage: du -hd1 /mnt/disks/docker 2.0G /mnt/disks/docker/appdata 651M /mnt/disks/docker/service 2.6G /mnt/disks/docker df -ah | grep /mnt/disks/docker none 0 0 0 - /mnt/disks/docker/appdata /dev/loop2 2.0G 386M 1.6G 20% /mnt/disks/docker/service tmpfs 7.7G 68K 7.7G 1% /mnt/disks/docker/service/containers overlay 2.0G 386M 1.6G 20% /mnt/disks/docker/service/overlay2/3e72cc7e467ed786983b98fbb8273ac2f922be7dd087c87811a5dadf30c0c19a/merged This means we used 651MB of the 2GB docker.img. Any data which would be written to /appdata would raise the RAM usage! You want to reset everything? Execute this: umount /mnt/disks/docker/service umount /mnt/disks/docker/appdata rm -r /mnt/disks/docker/*

Dazu eine Anmerkung. Wirklich M.2 SATA oder SATA nehmen und keinen NVMe Adapter. Ich hatte mal so einen und die NVMe glüht vor sich hin, weil der Adapter das Sleep Kommando nicht weiterleitet. Keine Ahnung ob es da mittlerweile bessere Adapter gibt?!

Tatsächlich lief der Vanilla die ganze Zeit mit dem 1GB XMX Limit. 😅 Da waren meine ich sogar schon 5 Spieler gleichzeitig drauf und wenn viele Spieler drauf waren, dann stieg auch der RAM-Verbrauch auf über 3GB laut Container-Übersicht, was ich ja schon irgendwie komisch finde, wenn man doch eigentlich 1GB eingestellt hat. Jedenfalls wird nun hauptsächlich der Paper-Server genutzt, der nun zum ersten mal mit dem Out of Memory Error abgestürzt ist, wie ich auch den Logs entnehmen kann: [12:35:08] [Server thread/WARN]: abc moved too quickly! 11.484660118942482,-13.344199657193855,19.297132411591548 [12:36:01] [WorldEdit Session Manager/WARN]: Exception in thread "WorldEdit Session Manager" java.lang.OutOfMemoryError: Java heap space [12:36:01] [Netty Epoll Server IO #3/WARN]: [io.netty.channel.AbstractChannelHandlerContext] An exception 'java.lang.OutOfMemoryError: Java heap space' [enable DEBUG level for full stacktrace] was thrown by a user handler's exceptionCaught() method while handling the following exception: java.lang.OutOfMemoryError: Java heap space [12:36:10] [User Authenticator #3/INFO]: UUID of player abc is abc-abc-abc-abc-abc Bei dem habe ich nun neben --memory=8G auch die 8GB bei den XMS und XMX Werten angepasst. Wo vorher im Ruhezustand 1.6GB genutzt wurden, steht er nun auf 6.7GB: Mehr RAM wird also offensichtlich dankbar angenommen. Mal sehen ob es in Zukunft wieder einen Absturz gibt.

Siehe Beitrag zuvor. Habe ich korrigiert. War denn 1GB mein Problem? Weil die 9GB bei Virtual Memory Used irritieren mich.

Ok, darauf soll ich mich schon mal nicht verlassen: https://docs.docker.com/config/containers/resource_constraints/#--memory-swap-details Außer --memory finde ich in der Doku nichts. Muss ich evtl dem Minecraft Server selbst mitteilen wie viel RAM es wirklich gibt?! EDIT: Ok, also hier steht, dass man die server.jar mit Xmx und Xms limitieren kann: https://www.mvps.net/docs/how-to-increase-the-minecraft-server-ram-allocation/ Laut dem Crash Report steht beides auf 1GB: JVM Flags: 2 total; -Xmx1024M -Xms1024M EDIT2: Ok, man sollte die Config eines Containers auch lesen ^^ Gut, da habe ich nun ebenfalls 8GB eingestellt: Wobei ich mich jetzt immer noch Frage ob 1GB oder 8GB mein Problem waren. Die 9052 "Virtual Memory Used" deuten ja eher daraufhin, dass er die 8GB überschritten hat?!

Mein Minecraft Server ist laut Crash Report mit folgendem Fehler abgestürzt: java.lang.OutOfMemoryError: Java heap space Das scheint darauf hinzudeuten, dass der Container zu wenig RAM zugewiesen bekommen hat. Ich habe über "--memory" 8GB als Limit hinterlegt: Was ich nun nicht verstehe ist die Memory Zeile im Crash Report: Memory: 1336928 bytes (1 MiB) / 1073741824 bytes (1024 MiB) up to 1073741824 bytes (1024 MiB) Laut meiner Recherche sollte da eigentlich eher sowas stehen: Memory : 8.00GB (7.83 GB Usable) Weiter unten finde ich dann noch diese Werte, die auf 32GB RAM hinweisen: Virtual memory max (MB): 32080.43 Virtual memory used (MB): 9052.07 Swap memory total (MB): 0.00 Swap memory used (MB): 0.00 Dabei hat mein Server aber 64GB verbaut. Also wie kommt der auf 32GB bzw wieso nimmt der überhaupt an, dass das das Maximum sei, wo ich doch 8GB als Limit eingestellt habe? Wenn ich innerhalb des Containers die RAM-Auslastung prüfe, sieht der Container ebenfalls meine 64GB: free -h total used free shared buff/cache available Mem: 62Gi 3.8Gi 443Mi 1.7Gi 58Gi 56Gi Swap: 0B 0B 0B Gibt es keine Möglichkeit den RAM so zu begrenzen, dass das Container wirklich von 8GB als Maximum ausgeht? Weil es erscheint ja logisch, dass der abschmiert, wenn er denkt, dass er eigentlich mehr belegen könnte.

@hawihoney Noch ca 2GB RAM frei? Dann führe folgendes aus: mkdir -p /mnt/disks/docker/appdata mkdir /mnt/disks/docker/service mount -t ramfs ramfs /mnt/disks/docker/appdata/ dd if=/dev/zero of=/mnt/disks/docker/appdata/docker.img bs=1M count=2000 mkfs.xfs /mnt/disks/docker/appdata/docker.img mount -o loop /mnt/disks/docker/appdata/docker.img /mnt/disks/docker/service /mnt/disks/docker/appdata/ ist nun eine RAM-Disk in der das 2GB große XFS formatierte docker.img liegt, was wir über /mnt/disks/docker/service mounten. Entsprechend müssen nun auch die Pfade in den Docker Einstellungen gesetzt werden: Nachdem Docker gestartet ist, kannst du mkvtoolnix wie folgt installieren (oder über ein Template anlegen): docker_options=( run -d --name=mkvtoolnix -e TZ=Europe/Berlin -v "/mnt/disks/docker/appdata/mkvtoolnix:/config:rw" -v "/mnt/user/movie:/mnt/user/movie:rw" jlesage/mkvtoolnix ) docker "${docker_options[@]}" Und so liest du zB die Track-Daten aus: docker exec mkvtoolnix /usr/bin/mkvmerge -J "/mnt/user/movie/E/Das erstaunliche Leben des Walter Mitty (2013)/Das erstaunliche Leben des Walter Mitty (2013).mkv" Nach der Installation und Ausführung des Befehls belegt /service 651MB, passt also problemlos in die 2GB RAM-Disk: du -hd1 /mnt/disks/docker 2.0G /mnt/disks/docker/appdata 651M /mnt/disks/docker/service 2.6G /mnt/disks/docker df -ah | grep /mnt/disks/docker none 0 0 0 - /mnt/disks/docker/appdata /dev/loop2 2.0G 386M 1.6G 20% /mnt/disks/docker/service tmpfs 7.7G 68K 7.7G 1% /mnt/disks/docker/service/containers overlay 2.0G 386M 1.6G 20% /mnt/disks/docker/service/overlay2/3e72cc7e467ed786983b98fbb8273ac2f922be7dd087c87811a5dadf30c0c19a/merged Natürlich ist alles nach einem Neustart weg. Man sollte also die oben genannten Befehle in die Go-Datei packen, damit nach einem Neustart die RAM-Disk neu erstellt wird. Alles auf Anfang? Dann Docker stoppen und das ausführen: umount /mnt/disks/docker/service umount /mnt/disks/docker/appdata rm -r /mnt/disks/docker/*