mgutt

Das sind Snapshot-Kopien (reflinks), die keinen Speicherplatz verbrauchen. Zumindest nicht, solange nicht sehr viele appdata Dateien des Containers geändert werden. Da wäre dann aber eh die Frage wann das wieder gelöscht werden sollte. Welchen Vorteil erwartest du dadurch?

Dann Check doch Mal Tools > Syslog. Was sehr oft Auftritt wirst du ja selbst schnell erkennen.

Ja kannst du. Mach am besten so lange den Array Autostart aus. Sofern du keinen syslog mirror aktiv hast, solltest du aber JETZT eine Diagnostics erstellen, weil sonst deine Logs nach einem Neustart weg sind.

Ich überlege gerade ob ich etwas als Plugin umsetze. Und zwar soll kurz bevor das Update eines Containers installiert wird, ein Update vom entsprechenden appdata-Ordner erstellt werden. Das ist noch eine sehr frühe Phase. Wer mag kann mal diesen Code ausführen (Rückgängig machen, siehe unten): sed -i '/communityApplications/i\ execCommand("docker inspect $Name | grep :/ | grep -oP \x27/mnt/[^/]+/appdata/[^/:]+\x27 | sort -u | xargs -I{} sh -c \x27rm -r {}_before_update 2>/dev/null; cp -a --reflink=always {} {}_before_update\x27", $echo); ' /usr/local/emhttp/plugins/dynamix.docker.manager/include/CreateDocker.php Nun geht man auf irgendeinen Container, aktiviert die erweiterte Ansicht und macht ein Force Update. Man sieht nun nach dem Herunterladen der neuesten Images und dem Stoppen des Containers einen neuen "Command" Block und je nachdem wie viele Dateien gesichert werden, wird für ein paar Sekunden das "Please wait..." angezeigt: Um dann im Anschluss wie gehabt mit Removing Container und dem Neustart des Containers fortzufahren: Doch was ist nun dadurch passiert? Nun wenn man in den Appdata-Ordner reinschaut, sieht man, dass ein neuer Ordner /containername_before_update erstellt wurde, welcher eben eine Kopie aller Dateien des Containers enthält, bevor das Update gemacht wurde: Schlussendlich wäre dann die Idee (ist jetzt noch nicht im Code enthalten), dass man über einen neuen Menü-Eintrag ein Update zurückrollen kann: Dazu müsste ich dann aber noch die Version des Repositories von vor dem Update ermitteln und die XML entsprechend so ändern, dass sie bei einem Rollback zB nextcloud:latest gegen nextcloud:23.0.1 oder was auch immer ersetzt, bevor der Container damit dann neu gestartet wird. Was haltet ihr von der Idee? Wie man oben genannten Code wieder entfernt: sed -i '/execCommand("docker/d' /usr/local/emhttp/plugins/dynamix.docker.manager/include/CreateDocker.php

Ähh, nein: Passives DAC 0.1 bis 0.2W Aktives DAC 0.5W AOC 1 bis 2W Quellen: https://community.fs.com/de/blog/guide-to-10g-dac-and-aoc-cables.html#:~:text=Systemausfall zu vermeiden.-,Stromverbrauch,-Normalerweise ist der https://www.optcore.net/article020/ Von den 0.1W darf man sich übrigens nicht blenden lassen, denn die aktiven PCIe Lanes und die schlechteren CPU-C-States durch Installation der PCIe Karte erhöhen den Verbrauch bei allen drei Varianten um 2 bis 3W.

777 bzw drwxrwx--- ist in jedem Fall richtig. Ist bei mir auch so. Aber jetzt sehe ich was. Warum gehört dein /data Ordner dem User 99 und der Gruppe 100?! Bitte wie folgt korrigieren: chown 33:33 /mnt/user/nextcloud

Bevor man solche Experimente macht, würde ich dir auch dazu raten noch mal Backups zu erstellen. Dh diese VMs sind bisher nicht in unRAID gelaufen oder warum dieser Schritt? Was genau läuft eigentlich nicht?

Nein Kommt auf den USB Controller an. Manche verändern die HDD Bezeichnung, andere schleifen sie 1:1 durch. Mach Array Autostart aus, bau um und starte. Entweder wird sie im Parity Slot angezeigt oder nicht. Dann ist sie dauerhaft raus und die Parität wird neu aufgebaut. Aber man kann Trick 17 machen. Beim Starten kann man angeben, dass die Parity bereits korrekt sei. Dann startet man einen Parity Check mit Korrektur und evtl Differenzen werden berichtigt.

Ist das denn so vorgesehen? In der FAQ war meine ich von 8000 oder 9000 die Rede?!

In dem Post hattest du aber noch eine?! https://forums.unraid.net/topic/129369-nextcloud-dein-datenverzeichnis-kann-von-anderen-benutzern-gelesen-werden/?do=findComment&comment=1178521 Setz auf jeden Fall noch User und Dateirechte wie sie sein müssen: chmod 644 /mnt/user/nextcloud/.ocdata chown 33:33 /mnt/user/nextcloud/.ocdata

Ok und wo war jetzt noch Mal die Datei .ocdata?

Läuft der Stream über WLAN oder LAN? Manche Router sind mit hohem Traffic so überlastet, dass das WLAN davon beeinflusst wird. Ein Grund warum ich irgendwann das WLAN der Fritz!box abgeschaltet und Ubiquiti APs verbaut habe.

Bitte das Ergebnis posten: ls -an /mnt/user/nextcloud Jetzt bemängelt er ja "nur" noch, dass die ".ocdata" fehlt bzw nicht die richtigen Rechte hätte. Geh auch mal bitte hin und öffne die Console des Containers und führe das aus: ps aux Bei USER sollte "www-data" stehen: USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.0 270084 38216 ? Ss 11:31 0:00 apache2 -DFOREGROUND www-data 71 0.0 0.0 270124 9536 ? S 11:31 0:00 apache2 -DFOREGROUND www-data 72 0.0 0.0 270124 9536 ? S 11:31 0:00 apache2 -DFOREGROUND www-data 73 0.0 0.0 270124 9536 ? S 11:31 0:00 apache2 -DFOREGROUND www-data 74 0.0 0.0 270124 9536 ? S 11:31 0:00 apache2 -DFOREGROUND www-data 75 0.0 0.0 270124 9536 ? S 11:31 0:00 apache2 -DFOREGROUND root 76 0.0 0.0 2484 580 pts/0 Ss+ 14:17 0:00 sh root 87 0.5 0.0 2484 516 pts/1 Ss 14:20 0:00 sh root 94 0.0 0.0 6760 2816 pts/1 R+ 14:20 0:00 ps aux Und das: id www-data Sollte die ID 33 zeigen: uid=33(www-data) gid=33(www-data) groups=33(www-data)

ach so ja klar. 0770 natürlich. Oder 770. Ist das selbe.

Ne sorry. Ich habe mir eine gebrauchte X710-DA2 gekauft, bin aber immer noch nicht dazu gekommen das zu messen...

Ich hatte mal was mit iptables versucht, aber nie wirklich hinbekommen. Spontan hätte ich fast gesagt, dass man den Server mit zwei LAN-Kabeln verbindet und eth0 auf 100 Mbit/s drosselt. Setzt aber natürlich voraus, dass deine Internetleitung schneller ist, damit das überhaupt einen Effekt hat. Oder man geht sogar auf 4 Adern und erzwingt nur 10 Mbit/s ^^ Ansonsten gehen meine Ideen auch eher Richtung Hardware (smarter Switch, neuer Router, etc) oder man muss wirklich nach Lösungen in der jeweiligen Applikation suchen. Wenn es diese Überlastung gibt, resultiert die denn evtl aus NAT-Loopback/Hairpinning Traffic oder kann der Smart 4 das überhaupt... finde nichts dazu. Oder ist das wirklich schon bei simplem Upload in eine Cloud ein Problem? Sorry, aber dann würde ich den Router echt entsorgen.

Dann musst du nur noch das machen: chmod 777 /mnt/user/nextcloud Durch den vorherigen find + chmod Befehl hatte der Ordner nämlich auch 755 bekommen.

Die sparsamsten Karten sind SFP+ Karten, welche mit DAC Kabeln betrieben werden. Wenn der Client aber nicht mit DAC verbunden werden kann, hilft dir das natürlich wenig. Danach kommen die RJ45 10G Karten. Egal ob nun Aquantia oder Intel Chipsatz, die verbrauchen alle um die 6W. Wo man bei RJ45 10G richtig sparen kann ist, wenn man auf den 10G Switch verzichtet und Client und Server direkt verbindet. Dadurch ist die 10G Verbindung nämlich vollständig deaktiviert, wenn der Client abgeschaltet wird (anders bei einem Switch, wo die Buchsen vom Switch und vom Server immer aktiv sind). Das setzt aber voraus, dass der Client zwei LAN-Kabel oder ein LAN-Kabel plus WLAN nutzen kann, damit er noch ins Internet kommt.

Du hast da ein kleines Verständnisproblem. Die 33 ist die User ID. Also Nutzerrechte. Die sind alle richtig (99:100 wäre besser, aber spielt in deinem Fall keine Rolle, weil der Container aktuell mit 33:33 läuft). Dein Problem sind die Dateirechte. Also was du in deiner Ausgabe als drwxr-xr-x siehst. Das entspricht zB chmod 755 Das macht er auch bei einem User-Ordner? Poste bitte ein Beispiel. Wenn er sagt "retained as 0755 (rwxr-xr-x)", dann hat ja der Ordner das Recht 755 und behält es auch, aber wie gesagt haben alle deine User-Ordner laut deinem letzten Post 777 (rwxrwxrwx): Und genau das darf nicht sein. Warum also wurden die Rechte nicht durch das Kommando geändert? Das sollte dir eigentlich angezeigt werden. Wenn es zu viele Logs sind, dann mach es so: find /mnt/user/nextcloud -type d -exec chmod -v 755 {} \; > /mnt/user/appdata/chmod.log Dann lad dir die chmod.log herunter und schau was er bei den User-Ordnern gemacht hat.

Das ist aber nach wie vor falsch: rwxrwxrwx = 777 Wenn du nur suchst, siehst du dann die Userordner? find /mnt/user/nextcloud -type d Du kannst dir auch anzeigen lassen, was er für Rechte setzt, in dem du -v ergänzt: find /mnt/user/nextcloud -type d -exec chmod -v 755 {} \;

Ich habe gerade mal eine Testinstallation gemacht. Bei mir ist alles 777: # ls -an /mnt/cache/appdata/nextcloudtest total 8 drwxrwxrwx 7 0 0 69 Oct 10 11:31 ./ drwxrwxrwx 21 99 100 4096 Oct 10 11:31 ../ drwxrwxrwx 2 33 33 6 Oct 10 11:31 apps/ drwxrwxrwx 2 33 33 296 Oct 10 11:31 config/ drwxrwxrwx 2 33 33 6 Oct 10 11:31 data/ drwxrwxrwx 15 33 33 4096 Oct 10 11:31 html/ drwxrwxrwx 2 99 100 6 Oct 10 11:31 share/ Komisch, dass der bei dir dann sagt, dass "Datenverzeichnis von anderen Benutzern gelesen werden" kann. EDIT: Ah jetzt glaube ich weiß ich was das Problem ist. /data muss 777 haben, aber nicht /data/username. Die müssen alle 755 sein. Die sind/waren (?) bei dir aber 777: Wobei du ja das Kommando ausgeführt hast oder nicht? find /mnt/user/nextcloud -type d -exec chmod 755 {} \; Dann sollten die eigentlich jetzt richtig sein 🤔 Poste vielleicht noch mal alle Ordnerrechte.

Wir müssen wissen welche Rechte /data selbst hat. Also mach ls -n /mnt/user/trash/ncTEST/nextcloud

Und die Rechte von /data? Um die geht es ja.

Da unRAID kein Antivirus Programm mitbringt, gibt es keine solche Einstellung. Da müsste man sich selbst was bauen. Zb könnte man das SMB Loglevel erhöhen und bei entsprechenden Einträgen in den Logs den Virenscanner triggern. Muss man aber von Hand realisieren.

Es ist keine gute Idee das Home Verzeichnis extern zu mounten. Dort legt Linux eine große Zahl an Config Files ab, die ab dem Mount weg sind. Mounts gehören außerdem grundsätzlich nach /mnt Es wird ja denke ich möglich sein die Software so anzupassen, dass sie in bestimmte Verzeichnisse schreibt. Also zb nach /mnt/user/sharename?