MAM59

Ja, da würde ich auch mal einen kritischen Blick in die GPOs empfehlen. Gerade die Domänenvorgaben sind recht streng und Microsoft versucht es immer wieder Fremdanbieter zu verhindern indem sie neue Features in SMB einbauen und die dann auch erzwingen. Kann man alles aber wieder abschalten. SUCHEN!!! (hier würde ich mal das Augenmerk auf "SMB-Direct" legen, das ist recht neu und mWn im aktuellen SAMBA noch nicht enthalten. Können aber auch diverse andere Features in Frage kommen ("Datenverkehr immer digital signieren" oder ähnliche))

jep. das gibts auf reinen static maschinen überhaupt nicht.

also ersmal schalten wir dann "host access to custom Networks" AN, dann sollte schon mal der Docker erreichbar sein. Also irgendwas ist da faul... Deine Kiste redet immer noch mit dem DHCP Server, trotz statischer Adresse! Kriegt die Adresse 192.168.1.179, wird traurig und löscht alles wieder :-( Das ist nicht normal! Und WLAN pfuscht da auch noch mit rein, das ist doch Chaos pur. Allerdings fehlt mir die kriminelle Phantasie wie man sowas hinbekommt. Du solltest mal besser runterfahren, alles was "network*" heißt aus der config löschen (auf einem anderen Rechner) und neu booten. Dann kommt er zwar nicht mir Deinen Wunschwerten hoch, aber sollte wieder ordentlich im LAN funktionieren. Die statische Adresse kann man auch noch später (vorsichtig) reinmachen...

Du redest recht wirr... was will uns der Dichter damit sagen? Was willst Du eigentlich alles erreichen? Adguard, HA.... sehr mystisch... Schick neue Diagnose und noch die aktuelle Routingtabelle ("netstat -nr")

Also ich sehe da ein "kleines Problem": Sep 15 12:00:56 Firespray dhcpcd[1479]: eth0: IAID 3c:b9:6b:d0 Sep 15 12:00:57 Firespray dhcpcd[1479]: eth0: soliciting an IPv6 router Sep 15 12:00:57 Firespray dhcpcd[1479]: eth0: Router Advertisement from fe80::4262:31ff:fe02:d040 Sep 15 12:00:57 Firespray dhcpcd[1479]: eth0: adding address 2003:e7:1706:6700:XXXX:XXXX:XXXX:6bd0/56 Sep 15 12:00:57 Firespray dhcpcd[1479]: eth0: adding route to 2003:e7:1706:6700::/56 Sep 15 12:00:57 Firespray dhcpcd[1479]: eth0: soliciting a DHCPv6 lease Sep 15 12:00:57 Firespray dhcpcd[1479]: eth0: adding default route via fe80::4262:31ff:fe02:d040 Sep 15 12:00:57 Firespray dhcpcd[1479]: eth0: Router Advertisement from fe80::828a:f7ff:fe09:3202 Sep 15 12:00:58 Firespray dhcpcd[1479]: eth0: REPLY6 received from fe80::4262:31ff:fe02:d040 Sep 15 12:00:58 Firespray dhcpcd[1479]: eth0: adding address 2003:e7:1706:6700:XXXX:XXXX:XXXX:1ba9/128 Sep 15 12:00:58 Firespray dhcpcd[1479]: eth0: renew in 2250, rebind in 3600, expire in 7200 seconds Sep 15 12:00:58 Firespray rc.inet1: ip -4 route add default via 192.168.1.1 dev eth0 metric 1 Du hast da offensichtlich zwei verschiedene Router für IPV6 im Netz. Einer (...d040) vergibt "normale" Adressen (/56), der andere (...3202) nur einen Point To Point Link (wahrscheinlich Tunnel Endpunkt). Im Moment wird der Trafik über den "richtigen" Router geleitet, aber, das kann sich ändern, wenn er z.B. nicht zyklisch sich wieder ankündigt (die Ankündigungen werden mit der Zeit seltener wenn keine neuen Kisten hinzukommen) oder der andere häufiger die Leute vollbrabbelt. Wenn sie dann auch noch, wie üblich, gleiche Priorität haben, übernimmt der 2te das Routing und die Pakete gehen über den Tunnel raus (wo immer der auch hingehen mag) Die Leitung wird stündlich neu gecheckt und nach 2 Stunden ohne zufriedenstellende Antwort dann gelöscht/übertragen. Wenn das Dein Problem sein sollte, dann such mal den 2ten Router und guck ihm streng ins Blauauge oder tritt ihm auf die dreckigen Füsse. Der sollte da nix zu suchen haben.

Also die 2025 ist etwas zu dünn (2,5mm statt der erforderlichen 3,2mm). Je nach Sockel sollte sie dennoch Kontakt haben, zur Not eben noch etwas auffüttern. Die Batterien der 20xx Serie haben alle 3 V und 20mm Durchmesser. Die Dicke kann variieren. Es gibt mWn 16, 20, 25 und 32 (setzt ein "," zwischen die Zahlen und ihr habt die Dicke in mm). Natürlich haben die Typen dann unterschiedliche Kapazitäten (aka: dicker hält länger). Bei PCs sind die 2032 üblich, aber z.B. in Fotoapparaten oder Grußkarten findest Du mehr die dünneren Typen.

Because you forgot to add Step 1 :-) 1) MOVE UNRAID away from Port 80! This can be done HERE Change HTTP and HTTPS Port to a value that you like (and remember!). Now NPM can run in Host mode and take over these ports. Btw, you still cannot access Port 300x from the internet, NPM only tunnels 80 and 443.

you can put it into the smb-extra tab in the gui Note 1: the array needs to be stopped before you can edit Note 2: you need to supply each option into a seperate line! like these configs are saved and restored automatically after a reboot (after edit restart the array to see the changes)

Sep 15 21:34:46 RENZO kernel: igb 0000:06:00.0 eth1: renamed from eth0 He manually has (re)named eth0 to eth1 Be aware that DNS servers and so on are ONLY taken from eth0's config! So, it is very likely that you now run without any. Rename it back (in network rules) and you should be up and running again. (or delete the network.rules file in the config and reboot)

I would not agree that xfs actively supports ADS. Its just a side effect because it allows "up to 64kb of additional data" to be stored into the file. Real ADS is not limited in size. So you may have already problems that you are not aware of. (ADS Data cut off) The only filesystem with real ADS is NTFS, which will be available to UNRAID soon too (version 7.2 offers it for the first time). But be aware too that ADS is a lame duck. Microsoft has already put it on their deprecated list, sooner or later it will be dropped completely. I only know a handfull of applications that ever used it although the "keep together what belongs together" idea was not bad. But users like it more to have a folder with several files to copy instead of one file with hidden subfiles. I dont really understand your approach to disable ADS in the SMB config? If your cache strips it already, it never makes it to the xfs disks. So it makes no difference. And, does your application still work without the ADS data? anyway, you may take a look at https://www.samba.org/samba/docs/current/man-html/vfs_streams_xattr.8.html Maybe this helps you with your problem?

Cool bleiben, Platten sind billig :-) Du wirst es HASSEN, wenn Du ein komprimiertes (und auch noch verschlüsseltes?) Backup mit einschlägigen Tools (z.B das beliebte "BORG Backup") gemacht hast und im entscheidenden Zeitpunkt das Tool Dich nicht mehr liebhat, Du den Schlüssel verlegt hast oder ein paar Stunden warten musst, weil die defekte Datei ganz hinten im Archiv ist und erstmal alles davor entpackt werden muß... KISS (Keep it simple and stupid) ! Mein Backup Server z.B. hat 1:1 dieselben Platten wie der UNRAID Server und kopiert einmal täglich die Unterschiede zum Vortage rüber (sowas wie rsync). (die restlichen 23:30 Stunden ist er physikalisch AUS) Beim Ausfall einer Platte brauch ich die nur dort rauszuziehen und in den UNRAID Server reinzupacken. Weiter gehts. Dann kann ich in aller Ruhe die Platte mal plätten oder sonstige Versuche damit machen, oder auch ne neue kaufen und die dann in den Backupserver packen. Am nächsten Tag (bzw von Hand gestartet) werden die fehlenden Daten dann wieder nachgezogen.

Ja, DAS ist das Hauptproblem von Nextcloud. Es liegt eigentlich ALLES in /data (bis auf config). UNRAID erlaubt ja nur mounts und shares auf top level, das ist nicht so gut vereinbar damit. Eigentlich bräuchte man untergeordnete Mounts in data, damit man mal später die eine oder andere Platte nachschieben kann. Kann man etwas mit symbolischen Links kaschieren, wird aber schnell sehr unübersichtlich... VORSICHT!

na denn, dann betrachtet meinen Hinweis nur als Warnung, dass man nicht einfach beliebige Pfade reinschreiben kann, sondern ggf. diese dann auch noch zuordnen muß :-)

das wird aber nur die halbe Miete sein, da muss man wohl dem Docker auch noch einen zusätzlichen Pfad reinkonfigurieren, und den auf einen (SSD) Share zeigen lassen. Sonst landest Du ja immer weiterhin im Docker, also auf der Datendisk.

also nach USB 2.0 brauchst Du nicht mehr suchen. Es reicht, einen Stick in ein USB2 Port des Computers zu setzen (oder zur Not einen 2.0 Hub dazwischen zu packen). Dann schalten die Sticks runter, bleiben cool und halten hoffentlich länger. Oder einfach NIX tun, und abwarten. LimeTech arbeitet Gerüchten zufolge schon an einer Ablösung des USB Sticks. Allerdings, "keiner weis Genaues nicht" und einen Terminplan gibt es auch nicht.

buy a simple and cheap 4 port sata card (PCIe 1x) and put it into the slot. Then you also need 3* "Mini SAS SFF-8087 > 4 x SATA 7 Pin Reverse" Cables (they look like the more common 1*SAS->4*Sata Cables, but do the opposite!). Connect 4 ports of each cables to motherboard + PCIe Sata Controller and the 3 ends of the cable to your backplane. There are not many "flying cables" around then. But beware: the small pics from the case look like as if there is a different connect-type then the widespread SFF-8087 beeing used! Its hard to tell, so make sure you read the manual that comes with the case CAREFULLY!. But in any case, you need REVERSE cables!!! Example of Cable: https://www.delock.de/produkt/83319/merkmale.html?setLanguage=en

Sollte es auch. Viele USB Gehäuse modifizieren die Plattenparameter (Name, Partitionen o.ä), dann können die Daten bei direktem Anschluß nicht mehr erkannt und gefunden werden. Also: Glück gehabt! Genau, Nextcloud ist eh ein zartes Blümchen das sich schon gerne mal zerlegt...

Dabei zu beachten ist, dass, wenn vorher die Platten über USB formatiert und bespielt worden sind, sie eventuell intern (also bei direktem Anschluß) gar nicht mehr lesbar sind! Wenn also "cannot mount, unformatted or..." beim Array Start kommt, oder unassigned Devices gar kein Dateisystem erkennen kann auf allen Platten, hast Du ein grösseres Problem, das nur mit deutlich mehr Aufwand zu lösen ist.

You could enable "Spinup Groups" and put all Array Disks into one Group. This means "if any of these disks is spun up, the others are waking up too". But beware! My experiences with this feature are a bit painful. Waking up works well, but going to sleep again seems to keep one drive of the group always on here. I have tried several times, never got it to run correctly. But maybe I was too stupid and you are more lucky? Give it a try. Cannot hurt or harm anything.

You have a serious LAN loop configured, this will kill the box sooner or later Sep 8 19:02:47 Tower kernel: br0: received packet on eth0 with own address as source address (addr:a4:ba:db:19:b2:c2, vlan:0) Sep 8 19:02:47 Tower kernel: br0: received packet on eth2 with own address as source address (addr:a4:ba:db:19:b2:c2, vlan:0) Sep 8 19:02:47 Tower kernel: br0: received packet on eth0 with own address as source address (addr:a4:ba:db:19:b2:be, vlan:0) Sep 8 19:02:47 Tower kernel: br0: received packet on eth0 with own address as source address (addr:a4:ba:db:19:b2:c2, vlan:0) Sep 8 19:02:47 Tower kernel: br0: received packet on eth2 with own address as source address (addr:a4:ba:db:19:b2:be, vlan:0) Sep 8 19:02:47 Tower kernel: br0: received packet on eth3 with own address as source address (addr:a4:ba:db:19:b2:be, vlan:0) Sep 8 19:02:47 Tower kernel: br0: received packet on eth2 with own address as source address (addr:a4:ba:db:19:b2:c2, vlan:0) Sep 8 19:02:47 Tower kernel: br0: received packet on eth0 with own address as source address (addr:a4:ba:db:19:b2:c2, vlan:0) Sep 8 19:02:47 Tower kernel: br0: received packet on eth0 with own address as source address (addr:a4:ba:db:19:b2:be, vlan:0) Sep 8 19:02:47 Tower kernel: br0: received packet on eth3 with own address as source address (addr:a4:ba:db:19:b2:c2, vlan:0) Looks like you have attached all ports to the same switch (or to different switches but these are interconnected too). I assume, you want to do some kind of bonding, but either you have not told your switch about it, or it does not support this kind of setup. The only valid option would be to pull out 3 of those cables or to set bond mode to "active backup". All will result in only one card beeing used anymore.

Na ja, ich benutz beides. Wobei der Backup Server unter Windows läuft, die Platten also nicht einfach austauschbar sind. Und um das lange Umkopieren möglichst zu vermeiden (zumal es auch noch mit reichlich Dackeln verbunden ist, da weit getrennte Lokalitäten) gibt es noch die Parity. Im nächsten Leben könnte ich allerdings auch dazu tendieren, sie abzuschaffen. Wozu jemand 2 Parity Platten haben muss, hab ich bis heute nicht wirklich verstanden...

zu erwähnen, dass da noch 2 haken zu setzen sind 😁 (was nun gar nix mit Parity oder nicht zu tun hat) Zumindest konnte der unbedarfte Leser dies nicht so direkt erkennen, deshalb gehe ich bei seinen Fehlversuchen mal von einem "Bedienungfehler" aus. (und ja, nicht grämen, ich hab auch anfangs 3 mal danebengelangt und geflucht, bis ich die etwas merkwürdige Logik dieses Menüpunktes endlich begriffen hatte (Lernen durch Schmerzen))

Ihr sagt ihm zwar dauernd richtigigerweise was "new config", aber Ihr vergesst dabei, dass man dann auch AKTIV noch 2 Haken setzen muss, damit das große Vergessen dann wirklich eintritt! Er wird wohl immer nur "new config" und dann OK gemacht haben, dann ändert sich natürlich NIX.

Use it but keep an eye on the values. If reallocated sectors increase more and more, its time to exchange the drive. But for now it looks harmless, its normal that drives have a few bad sectors. There are spare ones that are automatically remapped and used instead.

These 90 errors are most likely the result of unwritten buffers due to your unclean shutdown. UNRAID first writes the data, then the parity. So, if interrupted, it is a good chance, that the data is already correct on disk, just the parity is out of sync. To check (and fix) this (as @trurl already said): start a parity check with "write corrections" wait until it is finished (should show the 90 errors again) start another parity check without corrections The result of the latter should be 0, this means the data is correct and the parity is back in sync again. Avoid unclean shutdowns, they will always kill the parity. If you produce them often, consider to tick the "write corrections" mark in the settings to allow direct corrections in the pass that is always fired up after a restart following an unclean shutdown. This CAN cover real errors, but this is very rare. (use at your own risk)