MAM59

Das wirft einen nicht um, JEDES Board (bzw JEDER Prozessor) der letzten 10 Jahre bietet ein internes TPM an. Das Problem damit ist allerdings, dass bei einigen BIOS Updates kritische Einstellungen überschrieben wurden und dabei das TPM gelöscht wurde. Gespeicherte Lizenzen gingen dabei verloren!!! Inzwischen warnen ja alle Hersteller vor BIOS Update ist unbedingt der Bitlocker Key zu sichern. Dasselbe kann Dir dann auch mit UNRAID passieren. Ich würde nicht vor Juli umschalten, bis dahin sollten die alten Zertifikate von Microsoft überall ersetzt worden sein, danach wird hoffentlich Ruhe einkehren. Im Moment ist es also ein Risiko. (wer aber in den letzten Wochen ein neues BIOS eingespielt hat, könnte durchaus auf der guten Seite sein, genau die Änderungen durchlesen!)

yeah, the daily email from cron is really annoying... # Generated system data collection schedule: */1 * * * * /usr/local/emhttp/plugins/dynamix.system.stats/scripts/sa1 1 1 &> /dev/null # Flash backup schedules 0 7 * * * sh -c 'SCHEDULE_ID=schedule_1774242723 /usr/bin/php -f /usr/local/emhttp/plugins/flash-backup/helpers/run_schedule.php ' # Generated cron schedule for user.scripts */4 6-10 * * * /usr/local/emhttp/plugins/user.scripts/startCustom.php /boot/config/plugins/user.scripts/scripts/WakeupDisks/script > /dev/null 2>&1 add >/dev/null 2>&1 to your job please like all other jobs have already

hmm, 3 * NVMe ? Die Anschlüsse dafür sind sicherlich nicht auf dem Motherboard, oder? Solltest Du "aus Versehen" so eine Asus 4*NMVe Karte im GraKa Slot (16 Lanes) betreiben, so check Deine Bios Einstellungen. "PCIe Raid" muss dann aktiviert sein, aber von der Karte dürfen nur die Ports 1,2 & 4 bestückt sein (Port 3 ist fest an die IGPU des 5700G gekoppelt und extern nicht beschaltet). Ansonsten checke das BIOS auf "Überlappungen". Viele dieser MoBos sind "overdressed", sie enthalten mehr Geräte, als gleichzeitig betrieben werden können. Da gibt es dann im Manual entsprechende Fußnoten, GENAU lesen und befolgen! Die Einstellungen werden ja bei einem BIOS Update alle gelöscht, da kommt es schon häufiger vor, dass man hinterher vergisst, das Richtige wieder einzustellen...

note that there is a long-time-known-but-never-got-fixed bug: when using "spindown groups", the last drive of the group never spins down (Disabling spindown groups fixes this, but of course you also lose the feature that all drives of a group wake up together)

I have almost the same Mikrotik (just with 24 ports only, and 2 SFP+), but I am running it just as a switch. I've got some more Mikrotiks, but none of them runs as a router here. Too complicated and, most important, cannot handle IPV6 with dynamic prefixes. This is a no-go in Germany... (Hmm, maybe it NOW can handle it? dunno, but does not matter anymore...)

You have already done this. Selecting "Private" means: "only known people allowed, guests forbidden". And yeah, I agree, Mikrotik is not for the simple user, it is hardcore. But almost every other brand has defaults for firewalls that are set to "nobody is allowed to be in from the internet". You have to enable access one by one manually. So forget your paranoia, unless you open "DMZ access to machine..." or "allow anybody in" in your firewall, you are safe. It does not need UNRAID then too to filter, the router will keep any baddy outside already.

yeah, looks like your flash drive does not like to be (over)written by linux. Never heard about this before, but of course "s@it can happen everywhere"... Either try a different flash, or wait for 7.3. There they say you can install UNRAID on an normal internal drive and do not need an USB stick anymore. But so far no time for release or betas are known yet...

DNS settings are/can only be applied to ETH0. That's not a bug because DNS works above routing and therefor is global to all NICs. If you want to make the 10G card your main nic, define network rules and rename it there to eth0. (you can switch the MAC addresses with the drop boxes)

Then ZFS-RAID will be best for you I think. You may even try the designated SATA SSD as "cache" but there are good chances that it wont be needed and can be used for other issues instead. But of course, do not forget that you need an external means for "backup". Neither RAID or parity is a substitute for a real offline backup...

I have to add a bit more info: The type of Array you should choose depends on the type of your expected usage. The UNRAID array (though beeing "slow") is ultimately great when it comes to "datagraves" that grow over the time like video collections and so on. They are usually written once and read very often. Here is where the cache comes in, it speeds up the initial writing. The advantage of this type is that it can grow almost unlimited. You can always add a disk, or replace a smaller one with a newer, larger drive (data will be rebuild from parity then, but it takes ages...) The ZRAID array is faster, also comes with a buildin cache for reading AND writing (taken from the available RAM). It can also "grow" but you are limited to the size of the smallest disk (adding a newer, larger drive will waste the new free sectors). This is good if data changes frequently like home directories or something. Your NAS case is limited to 4 drives, so the "unlimited grow" of UNRAID' array is not really unlimited for you. Thats why I think, ZRAID will be best for you, but of course, you are free to choose, so analyse your usage before you decide...

"no array" is fine, actually "zfs within the UNRAID array" would be the worst choice of all. EITHER use a "ZFS-Raid Pool" OR an "UNRAID Array with parity" But I would consider to use ZFS instead of BTRFS for the cache SSD too. BTRFS is older and maybe rise some problems later. It star is going down already as you can read here everywhere. So better use the most modern and fancy filesystem, even wihout any RAID stuff.

also RAID1 Pools mit NVME+SATA SSD (in der Annahme dass "NVME" wirklich PCIe-NVME meint) sind recht sinnfrei. Sie erzeugen zwar Redundanz, aber alle Geschwindigkeitsvorteile von NVMe sind dahin wie Butter an der heißen Sommersonne :-( Auch als Cache macht sie nur Sinn, wenn Du dauernd NEUE Dateien schreibst (oder die alten vor Überschreiben manuell löscht). Ansonsten verpufft auch hier der Speedbonus ganz schnell. Wahrscheinlich ist es für die Schwuppdizität am Besten, die SATA SSD als Cache und die NVMe SSD für Appdata/System usw shares zu nehmen. Die profitieren von der hohen Geschwindigkeit, wobei SATA SSDs mit 500Mb/s noch schnell genug für übliche LANs mit 1, 2.5 oder 5G sind. Erst bei 10G und mehr wird NVMe gebraucht.

yeah, its is not a problem at all. (new) shares need to be exported manually at export time you can (and have to) select the permissions manually too That guest access still an option for shares has historical reasons. Old installations need it. Removing it would break those on update.

I have seen this error (5 parity errors reuccuring constantly in the same sectors) before. If I remember correctly, it came from a certain chipset of the SATA controller. If UNRAID is shutdown, it flushes all caches, including parity to the drive but this controller did not write the data out before power was turned off. The effected sectors were harmless (no data or directory info missing), but still very annoying. I thought, the no flush bug was corrected long ago already, but reading this makes me think it is either back or still there. Try: do correcting parity check repeat until no error shows up anymore shutdown and reboot unraid do correcting parity check again if the last one shows the errors again, you may should look for a replacement controller or rearrange drives to other controllers that might be already in the box and not used yet.

Kupfer ist das eigentliche Problem. Für längere Strecken nicht verlässlich. Ich musste das auch mal auf die harte und teure Tour lernen, aber seit Umstieg auf Fiber gibt es keine Probleme mehr. Deshalb ist SFP+ auf jeden Fall die bessere Wahl. Das Wort "stromsparend" sollte man sich allerdings im Zusammenhang mit 10G verkneifen. Das geht technisch einfach nicht. Je höher die Frequenz, desto mehr Energie braucht man um dieselbe Datenmenge zu übertragen. Und bei Kupfer kann man das auch deutlich fühlen. LWL Module brauchen nur so 2-4ma, Kupfer fängt bei 50 an und ist nach oben offen. Soviel Strom auf der kleinen Fläche ist eben ein Glühfix. Es gibt übrigens auch Mobos und MiniPCs direkt mit SFP+ Anschlüssen. Habe gerad letzte Woche für die Frau einen neuen MiniPC mit I13900, 32Gb Ram und bis zu 3 NVMes gekauft. Der hat 2*SFP+ mit 10G und 2*2,5G Kupfer onboard. Ich benutz nur 1 SFP+ davon, aber war eben alles fest mit eingebaut... (hab auch schon ähnliche Teile mit N100 und N350 in Betrieb, aber da möchte man das Desktop nich benutzen, zu lahm die Teile, aber gut als Server / Router / Firewall)

this has nothing to do with unraid, its just about the limits of your hardware. BTW: before you through the M4 away, send it to me (just kidding :-) ). I still have only M3 at work, but at full speed...

I was afraid that you do not have an apropriate slot for it... There will be NO options I think. the 8gigs you have seen, are PCIe Speed only. Not LAN speed. But with one lane only the cards can never deliver full 10G. Older cards wont work at all (like the MCX312C you have tested), newer cards contain brighte switches that can step down, but of course the maximum line speed cannot be gained with them. Your original approach with 2*25G was really bold and naive I think :-) (unless you through out the graphics card)

This is NOT the GUID! I doubt that UNRAID will accept it as a valid boot device now. (Later versions MAY work, they say there are changes ahead that will lift the barrier someday. But for now they are only rumours...)

I can understand his complains. Even if you know what you want, it is often not easy to do/find out what is needed for a certain checkbox to appear. This is spread all over the gui and it makes it hard for users and for helpers in the forum here too. If they have a problem and send in a screenshot, not every relevant info is always shown. Sure, you can dig deeply through the diagnostics, but this takes time. Also if you tell them to "turn on this and that" you always need to also tell them how to enable those items. I personally would encourage the gui to "contain everything but to grey out the inactive parts". The screen is filled more but everybody instantly sees that there is something hidden in the back and they just have to ask how to enable it.

Weil man zu faul ist für die "einmalige Einrichtung" und sie so nicht vergessen kann 😁 (ab dem 100ten Server ist man dankbar dafür, glaubs mir 😘) und weil man dann eine zentrale Liste hat, wo alle Zuweisungen schön aufgelistet sind. (Fritzboxen haben hier keine Berechtigungen, DHCP Server zu spielen. Sie sind viel zu dumm für kompliziertere Setups) Aber ich geb zu, dass ist nicht der Normalfalle eines "kleinen Anwenders". Nö, ich red schon von "richtigen" Servern, das bei meinem Screenshot nur IoT Geräte aufgeführt waren, ist Zufall bzw. dem Umstand geschuldet, dass die dauernd "schlafen" und beim Aufwachen erstmal mit dem DHCP Server reden wollen. Allerdings werden auch bei bestimmten IoT Geräten rein statische Adressen empfohlen weil der DHCP Kram eben Zeit kostet und auch Batterie/Akku mehr belastet.

Na ja, das geht eigentlich bei ALLEN DHCP Servern (manche mit GUI sind nur zu faul dazu). Der "Charme" davon die fixe Adresse vom DHCP Server austeilen zu lassen, liegt meist darin, dass er dann auch gleich den DynDNS Eintrag für den Server huckepack mit erledigen kann. z.B. Feb 12 08:26:23 l3router dhcpd[75713]: DHCPREQUEST for 192.168.0.111 (192.168.0.3) from 80:64:6f:c9:d6:14 (shellyplusht-80646fc9d614) via ix0 Feb 12 08:26:23 l3router dhcpd[75713]: DHCPACK on 192.168.0.111 to 80:64:6f:c9:d6:14 (shellyplusht-80646fc9d614) via ix0 Feb 12 08:26:23 l3router dhcpd[75713]: Added new forward map from shellyplusht-80646fc9d614.Shelly.meiszl.de to 192.168.0.111 Feb 12 08:26:23 l3router dhcpd[75713]: Added reverse map from 111.0.168.192.in-addr.arpa. to shellyplusht-80646fc9d614.Shelly.meiszl.de Feb 12 08:31:19 l3router dhcpd[75713]: DHCPREQUEST for 192.168.0.135 from fc:49:2d:6d:c8:c4 (amazon-6366cb2d3) via ix0 Feb 12 08:31:19 l3router dhcpd[75713]: DHCPACK on 192.168.0.135 to fc:49:2d:6d:c8:c4 (amazon-6366cb2d3) via ix0 Feb 12 08:31:19 l3router dhcpd[75713]: Added new forward map from amazon-6366cb2d3.Amazon.meiszl.de to 192.168.0.135 Feb 12 08:31:19 l3router dhcpd[75713]: Added reverse map from 135.0.168.192.in-addr.arpa. to amazon-6366cb2d3.Amazon.meiszl.de Leider gibts üblicherweise keine V6 DHCP Server mehr, so dass der "Trick" hier nicht funktioniert. Muss man dann doch noch ein extra Skript auf jeder Kiste laufen lassen. Wenn man allerdings bei UNRAID die Adress rein statisch vergibt, wird kein DHCP angestossen, es erfolgt also keine Registrierung Back to Topic... Ich vermute bei ihm einen misskonfigurierten Docker, der Port 80 und 443 belegt und damit der UNRAID GUI den Boden unter den Füßen wegzieht. Diagnostics und Docker Einstellungen könnten helfen. Um solche Probleme im Vorfeld zu vermeiden, empfehle ich es UNRAID "auf andere Ports umzulagern". Dann muss man zwar immer über Port 800 gehen, aber das ist nicht so frequentiert wie 80,8080 usw...

Ja, zwar sinnlos mit nur einer Karte, aber stört auch nicht gewaltig. Probleme treten erst auf, wenn mehr Karten hinzukommen. Heutige Kisten haben oft 2 oder mehr LAN Ports onboard... (Ich plädiere auch schon lange für das Abschaffen des "default Bonds")

Na ja, man sollte die Warnung schon ernst nehmen. Ich kenne Geräte, die scheren sich einen Dreck darum, ob die Adresse schon anderweitig in Betrieb ist. Die grätschen einfach mit rein und erzeugen totales Chaos. Ist nicht normgerecht, aber shit happens (am "bösesten" sind sogenannte "Smart TVs". Die probieren jeden fiesen Trick um "nach Hause telefonieren" zu können. Scheren sich nicht um DHCP Zuweisungen, DNS Server usw. Nur das Gateway können sie zum Glück nicht faken. Hab gerade 3 Tage lang gegen meinen LG im Wohnzimmer gekämpft, sinnlos. Nun hat er wieder kein LAN mehr, nur das gibt wirklich Ruhe) Es macht gemeinhin keinen Sinn, EINE Adresse aus dem DHCP Block rausschneiden zu wollen, es ist besser, die statischen Adressen gleich ausserhalb des Pools anzusiedeln.

Note again that the card you have ordered needs a "real" PCIe 8x slot with all lanes attached! These are usually server cards and most consumer motherboards have no slot for it (the 16x slot for the graphics card will work, but then, only buildin IGPU graphics). There maybe slots that can physically take the card, but usually they are electrically castrated and only contain 2 or 4 lanes. Consult your manual!!! If put into a wrong slot the card may either not work at all or slowdown like hell... (Note that there is also a 4x Version of the card available, this may work better in consumer boards) DAC cables usually work unless they are too long. Everything >3m is tricky. The longer cables usually are called "active", they contain amplifiers. Your explicit BIOS settings are nice work, but usually useless for others unless they have the same board with the same bios. The manufactures of the BIOS often use their specific names so that some settings are not directly transportable. You talk about "CSM enable" but your screenshot shows "disabled" ??? (and many other points also differ between your text and your screenshots) (which is fairly better because CSM is a transition technology and will disappear soon) Anyway, if it boots now, its ok. Once the OS is booted and takes over, all stuff will be renewed and fixed...

it would be helpful for others to know WHICH one of the list really helped.. !?!?! (some advices sound utterly stupid, but then, it came from an AI, what could we expect?) Also, if it was one with "switch UEFI mode off", be aware that soon "Legacy Mode" will disappear from the BIOS and UEFI will be the only choice available. So it might be better to get it to run now already. If you forget about it and update someday you may be locked out by the machine... Anyway, the detour is closed, now back to your orginal LAN problem...