superschlundi

@psychofaktory es gibt auch einen Bug Report dazu, ein User hat wohl einen Workaround gefunden (habe ich aber selbst nicht getestet). Bin selbst nicht auf 6.13 zurück gerollt, sondern nutze jetzt einfach weiter die Lösung mit 2 NICs, da gehts komischerweise mit IPv6 weiterhin.

Same problem here, but with macvlan - link to my post in the German section: There is also another user in the linked post with similar problem using ipvlan - so it should be a problem with the vlan-driver from docker. It seems like the GUI-Setting for IPv6 on the custom network does not work correctly, because an "docker network inspect eth0" shows that IPv6 is not enabled on the custom network: [ { "Name": "eth0", "Id": "63da494650cf9f1286cee6c0dec5f55b2e6fbbfbfee66d20c0bc582b51fbc2f0", "Created": "2023-09-02T13:47:25.953225226+02:00", "Scope": "local", "Driver": "macvlan", "EnableIPv6": false, ...

Ich habe das gleiche (oder ähnliches) Problem. Nutze MacVLAN, Hatte vorher den Workaround über 2 NICs genutzt und alles nach Anleitung umgestellt. Network-Settings: ETH0 Bridge No Docker: Host access to custom networks = Enabled Und natürlich das custom network auf interface eth0 gesetzt (IPv4 und IPv6). Bei Containern die nun auf dem ETH0 laufen sollen, wird mir schon gar kein IPv6 Subnet angezeigt, nur das IPv4. docker network ls liefert: NETWORK ID NAME DRIVER SCOPE 3668b800d293 bridge bridge local 63da494650cf eth0 macvlan local 38032617e576 host host local b305b4508d25 none null local docker network inspect eth0: [ { "Name": "eth0", "Id": "63da494650cf9f1286cee6c0dec5f55b2e6fbbfbfee66d20c0bc582b51fbc2f0", "Created": "2023-09-02T13:47:25.953225226+02:00", "Scope": "local", "Driver": "macvlan", "EnableIPv6": false, "IPAM": { "Driver": "default", "Options": {}, "Config": [ { "Subnet": "192.168.10.0/24", "Gateway": "192.168.10.1", "AuxiliaryAddresses": { "server": "192.168.10.10" } } ] }, "Internal": false, "Attachable": false, "Ingress": false, "ConfigFrom": { "Network": "" }, "ConfigOnly": false, "Containers": { "c19fa74eb5fa27d5da193ead777c670ae553439c7132ae3dcabc1e4c4446bcb2": { "Name": "pihole", "EndpointID": "f357777c307d523ce06b75daea1290cbfc7272e3456a2acd7f2b0e04fd0d530d", "MacAddress": "02:42:c0:a8:0a:fd", "IPv4Address": "192.168.10.253/24", "IPv6Address": "" } }, "Options": { "parent": "vhost0" }, "Labels": {} } ] Es scheint als würde die GUI-Einstellung für die IPv6 nicht greifen, da "EnableIPv6": false eingestellt wird. Mehrfaches Neustarten, Einstellung raus und rein nehmen, etc. ändert nichts.

Sowohl als auch: 1. Hardware: Wenn du über User-Shares auf deine Freigaben zugreifst, erzeugst du zusätzliche Last auf dem System, bei der schwachen CPU kann das durchaus nen Unterschied machen. Schneller wäre es Disk-Shares zu verwenden, sofern deine Files nur auf einer Disk im Array liegen und du den Cache nicht verwenden willst. 2. SMB-Einstellungen: Das ist so eine Sache, da scheiden sich mMn. die Geister. Es gibt hier einige Threads über die perfekte SMB-Einstellung und Feintuning, angeblich soll die Geschwindigkeit auch mal besser geworden sein mit den letzten Releases. Wichtig ist dass du unter den SMB-Settings "Enhanced macOS interoperability: Yes" eingestellt hast. Unter der Extra-Configuration kannst du noch zusätzlich Einstellungen angeben. Ich fahre für mich (keine Garantie) mit folgenden Settings ganz gut: [global] vfs objects = catia fruit streams_xattr fruit:nfs_aces = no fruit:zero_file_id = yes fruit:encoding = native fruit:metadata = stream fruit:posix_rename = yes readdir_attr:aapl_max_access = no readdir_attr:aapl_finder_info = no readdir_attr:aapl_rsize = no Für meine Shares definiere ich noch individuell: [share-name] path = /mnt/pfad/zum/share veto files = /._*/.DS_Store/ delete veto files = yes Damit ist SMB für den täglichen Gebrauch ganz okay unter MacOS (getestet mit Ventura). Ich nutze Unraid vor allem als Archiv für RAW-Daten in Lightroom, da kommt SMB dann aber schon mal an seine Grenzen bzw. wird schnell recht träge. NFS ist hier deutlich flinker unterwegs (nicht von der maximalen Übertragungsgeschwindigkeit, aber was das Laden von einzelnen Dateien angeht). Damit erkaufst du dir aber andere Probleme, vor allem dass NFS unter MacOS alles mit einer UMASK von 022 anlegt ( = 755 Dateiberechtigungen ). Das beißt sich dann mit SMB in der Unraid-Welt, weil du hier Verzeichnisse und Dateien, die per NFS erstellt wurden, nicht mehr löschen kannst. Einziger Workaround, der halbwegs praktikabel ist: auf meinen Archiv-Shares arbeite ich ausschließlich mit NFS, das Alltagszeug läuft nur über SMB. Und in regelmäßigen Abständen wird per User-Script wieder eine 777-Berechtigung über die Archiv-Shares gebügelt.

It's working again, thanks! But i had to restart my unraid machine to get it working again properly after the update.

6.11.5

After several days still no data and inconsistent representation of the graphs.

Unfortunately it doesn’t work for me like before: I updated the package and rebooted the system. No System Stats were available. So i uninstalled an reinstalled the plugin (with purging the old plugin files via „Apps“ -> „Previously installed“). After that i rebooted the system again to be safe. The System Stats are now working for the Real-Time view, but not for the static views.

Same here, running Unraid 6.11.5 on an QNAP TS-453Be, but I don't get any Syslog Errors after a reboot. System Stats are just blank.

Ich würde darauf tippen, dass das durch die Weboberfläche von Unraid selbst passiert. Mein TS-453BE läuft mit knapp 10 Docker-Containern und 2 Linux VMs im Idle bei kontinuierlichen 7-8 Prozent CPU Last, sobald ich das Webdashboard öffne, hab ich alle paar Sekunden Sprünge auf 15-20% auf einem oder zwei Kernen. Verbinde dich mal mit SSH (z.b. mit Putty) auf das System ohne die Weboberfläche offen zu haben. Dann mit top / htop mal die Auslastung beobachten.

Lad dir das Plugin "unBALANCE" aus den Apps herunter. Nach dem Start kannst du unter dem Reiter "GATHER" deine Shares auswählen, die zu verschieben möchtest. unBALANCE prüft dann alle Disks und schaut, wo Dateien des Shares liegen. Danach gibst du einfach die Disk an, auf der du die Daten am Ende haben willst. Anschließend passt du noch die Settings vom Share an, dass nur noch die entsprechende Disk auf "include" gesetzt ist. (Ich meine, dass man das auch vorher machen kann, ist aber mMn. irrelevant solange während dem Move durch unBalance nichts ins Share geschrieben wird.).

Hello @ich777, at first thanks for providing such a number of great plugins and apps to the community, I really appreciate it! I am running Unraid 6.10.3 on a QNAP TS-453Be, latest BIOS, and tried the QNAP-EC plugin to control the fan. It works (with fancontrol via terminal, or with the dynamix fan control). But I recognized that the plugin is reporting errors to syslog every time the fan speed is changed: Aug 19 08:49:44 QUBE qnap-ec[27142]: calling ec_sys_set_fan_speed function with 0 and 64 arguments Aug 19 08:49:44 QUBE qnap-ec[27142]: unexpected call to simulated Ini_Conf_Get_Field_Int function Aug 19 08:49:44 QUBE qnap-ec[27142]: function ec_sys_set_fan_speed returned 0 Aug 19 08:49:49 QUBE autofan: Highest disk temp is 36C, adjusting fan speed from: OFF (0% @ 0rpm) to: 64 (25% @ 638rpm) So syslog space will be full in a few days. I also tried to change the fan control behavior in the bios, but "automatic" and "manual" resulting in the same error.