MAM59

If you pool it "the usual way" (aka RAID 1 / Mirror), you will degrate speed to SSD level because writes have to be done on both of the drives.
So "the lower lance wins" (for those who still know the game "Joust").
 
Obviously this is NOT what you like to have...
 

Yeah, one nice feature of UNRAID: even if you do it wrong, usually there is a way to recover without loss.
So in your case, you need to delete the array config and reassign all drives like before again. parity needs rebuilding (because of your format action)
read about "new config" in the manual. it is the same like you did at the beginning.
Hint: write down the serial numbers of the drives before. Use the same ones for the new config (don't put a data disk as parity or vice versa!!!)
 

wrong sequence.
You should first have replaced the parity drive (either with the described procedure, or the "hard way" (turn off parity, replace drive, turn on parity, wait for rebuild to complete), then the data drive.
But things hopefully are not ruined now. Put back the 1Tb drive and assign it again to the array. Start array (should work again) and then start over.
If it is messed up already you have to accept the penalty time of rebuilding the 1Tb first because you can start over.
 
 

this depends a bit on the used controller hardware.
 
Usually UNRAID uses the unique serial number of the disk to find it back again. So you can move the drives anywhere and their meaning stays the same.
 
But some strange (mostly external USB cases) controllers catch this call and present their own ideas of the number. This, of course, leads to trouble when the drive is moved later on because UNRAID has stored the fake number and now gets the real one, or another fake...
 
Luckily these cases are rare, so usually, yes, you can swap them freely and they still will be recognized.
(beware to stop the array before you move them!!! else you will run into big problems...)
 

You should better have bought a Connect X-3 instead (the latest edition).
This is because the X-4 needs 8 Lanes for the PCIe slot, else it will slow down by half.
The 450Mb you see  tells me, that you have put the card either into the wrong slot (4x only), or you bios settings somehow prevent the usage of the full lanes.
With 10G you should expect to see ~1,1Gb/s not much less.
 
Look at the manuals of your Motherboards to see if there is an apropriate free slot (watch out for (*) notes many many have restriction with several combinations.) Mostly there is only one real 16x slot which is used for the Grafics card.
 
What you need is a Connect X-3 with PCIe3.0x4. (Warning! Many models of this card are PCIe2.0x8, these wont work well the same...)
 
 

Your "problem" is that you want to copy stuff (ACLs) that UNIX does not honor. The target file is not capable to attach Window's security settings to that file.
That is pretty much normal, the SAMBA server on UNRAID uses it's own security settings (that you can control from the GUI), they cannot be overwritten from the LAN.
 
So, change your robocopy command line, NOT to include security stuff (for instance use /copy:DAT not /copy:DATS, not /COPYALL and no /SEC too)
 
Keep in mind that UNRAID and Windows use different users. So the windows security for user X has no meaning to linux user X.)
 

note that some drives have "negative" activity LEDs.
They are always on (if spun up and initialized) and flash if there is real activty.
Manufacturers can save a "power on" LED this way.
So read the manual of the drive, if it is a combined LED, there is nothing wrong with your installation.
 

Nein, der ist fest und tief in der Docker Runtime vergraben.
Docker ist bei IPV6 noch eine ziemliche Diaspora. Die jetzige "Lösung" ist nur ein "geht so" Patch. Noch weit von richtiger Implementation entfernt.
Beim Dockerdesign wurde das gar nicht mit beachtet und nur halbherzig später draufgepfropt.
IPV6 und NAT, da schaudert es mich...

this effect may happen if flow control does not work correctly. Usually a transmission problem. The card gets the "Shut up!" packet but the "You may continue!" order is lost in transmission somehow. The port is blocked this way, usually until the cows come home.
 
Un-/Replugging resets the state usally. But if the line is bad, it will happen again sooner or later.
 
So in general: CHECK YOUR CABLES!!!
(hint: even Direct Attached lines can fail!)
 

its not syslog.
look into /var/log/unraid-api to see the evildoer
Install today's update of the plugin to silence it down again (may need to reboot afterwards to clear the logs)
 

he used zfs on the array... that should explain everything!
BAD MISTAKE!!!
(ZFS + Parity do not go well together, zfs tends to "optimize" during free time and parity needs to be updated all the time, this slows things down to the knees... )
 
(this is overkill! UNRAID  Parity  + zfs mirror. Get rid of one of them ASAP!)

check the cables. maybe one plug is lose, if a contact fails, but still 4 lines are ok, 100M is still possible to go. All 8 lines are needed for 1G.
Before you reboot, try to pull out the cable and replug it. This should usually "cure" the problem for some time. Try to find you which plug maybe lose, hot glue can be your friend then.
 

Dunno, could be a cloudflare address assigned to your tunnel (also: NOT USABLE)
 
try https://whatismyipaddress.com/
from any machine in your LAN, it will show you the valid address to use
 

ok, with this router you cannot expect more than 1G on that port. Buy a switch like https://www.amazon.de/VIMIN-Ethernet-Base-T-Ports-Switching-Kapazität-Kompatibel/dp/B0C5D2Y4FH/ref=sr_1_1_sspa?crid=2AFG1LIF0Y4E4&keywords=switch%2B2.5gbit%2B8%2Bport&qid=1704015991&sprefix=switch%2B2%2Caps%2C129&sr=8-1-spons&sp_csd=d2lkZ2V0TmFtZT1zcF9hdGY&th=1
Put it on the 2,5G port of your router (instead of the Mac), add Mac, Unraid and maybe more to that switch, Throw away that tplink 105 switch (not needed anymore, the new 2.5g switch has enough ports for all devices)
 
(PS: with the supposed switch you could even buy a SFP+ 10G RJ45 module,plug it in, and attach your mac to it to get full 10G on this connection, but it will not speed up things very much, so it is more a hypothetical addon. It would allow you to get full (2.5) speed to your router AND to unraid at the same time, without it, 2.5 speed would be spread among them. So before you buy the module ask yourself how often you will use both connections concurrently)

Uiiihjuijui... so ziemlich alles 😁
 
* die NVMe hat im Array nix zu suchen, die ist ja wohl die schnellste aller Platten, also ein würdiger "Cache"
* die Samsung SSD (jetzt Cache) gehört da aber auch nicht hin, im Array wird kein "Trim" ausgeführt, mit der Zeit wird sie also grottenlahm werden. SSDs gehören in separate "Pools"
* die 4Tb Datenklo sind da richtig plaziert.
 
* die system shares "system", "appdata" usw. gehören nicht ins Array. So viel Lebenszeit wirst Du nicht über haben. Idealerweise sind sie auf der NVme, alternativ geht auch die "Pool SSD" AUF KEINEN FALL DÜRFEN SIE VERSCHOBEN WERDEN!!! (was dann passiert, lernst Du ja jetzt gerade durch Schmerzen).
 
Ich geh mal davon aus, dass da noch keine wichtigen Daten drauf sind, deshalb würde ich sagen, am Besten löscht Du die gesamte Konfiguration und fängst nochmal von vorne an:
* 4TB ins Array
* NVMe SSD als "Cache"
* SATA SSD als Pool
* SystemShares entweder nur auf "primary Cache" lassen, oder "primary SSD" einstellen (und die automatisch erzeugten Ordner vom Cache von Hand auf die SSD verschieben).
 
Natürlich hat dieses Setup weder viel Speicher, noch irgendeine Art von Datensicherheit. Aber, das ist Dir ja wohl bewußt, oder?
 
Ach ja, noch eine Ergänzung zu "Mover steht": Klar steht er, er will eine VM verschieben, muß aber warten, bis sie "frei" wird. Das passiert aber niemals, solange die VM läuft. Also wartet er, und wartet, und wartet... Und wenn Du nicht gestorben bis, wartet er weiter 🙂
 
 

no.
What you see is the typical "chicken & egg" problem, that so many dockers have. If PiHole or Adguard, they are always started last on UNRAID, so they are not available at boot time.
 
What you can do is to give UNRAID a static address and use google (8.8.8.8) or one (1.1.1.1) as a static dns server.
 
All other machines can use your adguard, but UNRAID itself not.
 
The other thing you could yourself get a real pi, put pihole or adguard on it and let it run inside your lan. This way even UNRAID can use it.
 

you could create a share on the array and mount it on the vm.
Either mount it via SMB, or mount it directly in the VM's settings.
(Note that a permanent mount can give you troubles / hangs when stopping the array. Make sure to stop the VM before or you could face a long timeout period if you are unlucky.)
(Note2: although you could use the whole 32Tb this way, there is a limit that no single file can cross disk boundaries. In the share you can configure the splitting mode for files an directories, pick one that best suits your needs)

äääh, kennst Du den Film "Highlander" ?
Da gibts den weisen Spruch "es kann nur einen geben!" und der stimmt auch für Netzwerke.
Eine doppelte Verbindung funktioniert nicht, sie wird als Schleife erkannt und deaktiviert.
 
Ausserdem nimmst Du da "root", das ist kein erlaubter User für SMB Shares.
Leg einen neuen Benutzer an, gib ihm Zugrifssrechte für den Share, und dann wirds auch gehen.

Vor ZFS auf UNRAID sei hier ausdrücklich gewarnt!
Google kann viel spucken, aber hier spuckt es fake news.
 
ZFS benutzt RAID Arrays, UNRAID benutzt sie eben nicht (daher der Name).
Der Unterschied liegt in der Plattenverteilung:
Bei RAID Arrays müssen alle Festplatten identische Größe haben (hat eine mehr, wird dieser Teil nicht benutzt), bei UNRAID können beliebige Platten mitspielen, einzige Einschränkung: "die Paritätsplatte muss immer die Größte sein".
UNRAID ist also mittelfristig deutlich flexibler, dadurch dass "normale" Filesysteme benutzt werden, kommt man auch ausserhalb von UNRAID noch an die Daten ran im Notfall.
Selbst wenn mehr als eine Festplatte kapput gehen, kann man die restlichen Daten noch weiterverwenden.
 
ZFS ist moderner, hat einen Cache (UNRAID hat maximal einen optionalen Schreibcache) und überprüft dauernd die Datenintegrität. Dafür sind die beteiligten Festplatten immer voneinander abhängig. Geht mehr als eine kapput, droht der komplette Datenverlust.
 
Dazu kommt, dass (zumindest im Moment) die Performance von ZFS im UNRAID Array grottenschlecht ist, nur etwas für wirklich leidensfähige Leute. Als Pool Laufwerk(e) geht ZFS, sagen die meisten. Meine Erfahrungen waren aber auch grottenschlecht. Als Cache ist es völlig ungeeignet, bzw, es bringt keinerlei Vorteile gegenüber anderen Filesystemen. Dazu sind die Daten einfach zu kurzlebig auf einem Cachelaufwerk.
 

STOP! 😁
Many people like me tried it, got completely disappointed and had to take the long way back to XFS!
ZFS write "speeds" within the array are ridiculously low, mine were at ~70Mb/s (maximum!).
They say ZFS can be used in pool drives, my tests were also disappointing, so, after some weeks of fighting, this is a ZFS-free zone again.
 
 

This all reads a bit wrong and false.
With DHCP-PD you usually get a prefix "delivered" which you can use to forward to internal routers.
But, if you already get a /64, there is no way to forward anything anymore. So, you dont have -PD (and usually also do not need it).
 
Also, all addresses FE80::... are internally only, never can cross the router.
 
May it be that you have a castrated ISP connection which uses NAT on V6???
 
and what means "cannot get normally"
Does it get an address or not (and no, FE80:: are NOT valid addresses!!!) ? I dont see any in the list.
 
There should be at least ONE public address in the list like:
root@F:~# ifconfig |grep inet6 inet6 2001:470:70af:1::4 prefixlen 64 scopeid 0x0<global> inet6 fe80::202:c9ff:fea5:a990 prefixlen 64 scopeid 0x20<link> inet6 fe80::42:80ff:fe81:3781 prefixlen 64 scopeid 0x20<link> inet6 fe80::1 prefixlen 64 scopeid 0x20<link> inet6 fd17::1 prefixlen 64 scopeid 0x0<global> inet6 fe80::202:c9ff:fea5:a990 prefixlen 64 scopeid 0x20<link> inet6 ::1 prefixlen 128 scopeid 0x10<host> inet6 fe80::403b:1dff:fe21:35e9 prefixlen 64 scopeid 0x20<link> inet6 fe80::2c71:99ff:feec:e5d4 prefixlen 64 scopeid 0x20<link> inet6 fe80::cc61:d5ff:fe30:531b prefixlen 64 scopeid 0x20<link> inet6 fe80::78bd:33ff:fec3:bec9 prefixlen 64 scopeid 0x20<link> inet6 fe80::fc54:ff:fecd:f8ac prefixlen 64 scopeid 0x20<link> Everything starting with "Fxxx" is local only. The real address is 2001:470:.... (no need to mask it, its well known and static) You can also see it at the end of the lines. Unless there is a <global> you can forget this address.
 
I guess (just a guess), your router does not seriously announce the prefix, it grants addresses per dhcp, but does not inform the lan via "router advertisement protocol". Unless the lease time for DHCP is halfly used up, Linux (and therefor UNRAID ) do not try to re-register the boot time given address. Your smartphone does this over and over (it assumes you have changed nets). With RTA Unraid also would renew the address instantly (and get a new one).
Check the settings of your router, maybe there is some config wrong or missing.
 
(* the address fd17::1 is also been shown as global. This is a general mistake in Linux. It should be written "<link global>" because it can be used within your subnets, but never leave the router to the outside world. So it is more link but global)
 

Also, HA MUSS im Hostmodus betrieben werden und er kann niemals Geräte in andern Subnetzen finden und benutzen.
Das liegt an der zumeist von den Geräten verwendeten "Plug & Pray" Schnittstelle zur Erkennung.
Routing ist dort nicht vorgesehen.

in between I have tracked down the issue a bit more.
It looks like the usb plug of the UPS cable was a bit too sloppy. It did not fit in place anymore and due to the vibrations of all these fans and drives, it loses contact now and then.
It seems that the kernel went crazy with all these "on" / "off" transitions of the device and turned off the usb controller.
The flash drive was using a port on the same controller.
 
I have now pulled out the UPS, squeezed the plug a bit with some pliers, and have put it into a raspberry in the same rack as the unraid box.
Installed NUT on the PI in master mode and NUT on UNRAID in slave mode.
We will see if this was the evildoer, the PI does not care about "ports running wild".
 
@JorgeB all ports, sticks and controllers are USB 2.0 only. I have learned my lesson last year already. And the flash drive is not corrupted (yet) at all, it was just disabled.
 

yeah, just use the gui. it is simple
Stop the array, go to network settings, deselect bonding from eth1 first, then
click here, checkmark eth1 and YOU ARE DONE
 
 
 

yeah, thats 3 times faster than 10G Lan :-)))
The real question is: how long can it sustain that speed?
Many cheap drives run out on cache fast and then the write speed drops to ridiculous low (even down to 0) values and slowly resumes afterwards.
For 10G LAN and transfers of bigger files without hickups, you need a very good nvme cache drive.