MAM59

First of all, you need to rearrange your LAN cards.
Look down the Network Setting Page (or change to the "Rules for LAN Cards" Tab, depending on your GUI Settings)

Here you can see and change WHICH card gets the name "eth0". Change this to your 10G card and reboot.
The IP Settings will then be applied to your 10G card and the rest will be named eth1 to eth4. If you don't need them, you can disable them completly.
 
But first rearrange and reboot!
 

Yep 🙂
but beware, if you create a new cache pool, it will format your drives and the data is lost!
Although its already zfs, UNRAID demands a certain partition size/structure, else it will refuse the drives and demands formatting.
You may try but it depends dramatically how and with which os your "tank" has been created originally
 
Usually ZFS pools on UNraid are one RAID 1 (mirrored) drives for beeing used as cache. I prefer XFS filesystems, even for cache (no need for Mirror, most files are moved off the caches and my faith in NVMe SSDs is huge 🙂 )
ZFS sometimes gives mysterious troubles, I dont like troubles.
 

First of all you should ask yourself why both machines are not within the same LAN (subnet) and WHO is transfering packets between both LANs.
I have strong doubts that this is a single router, maybe your packets are forwarded to mars and return through a different gateway?
 
Check your routing, you may get a surprise.

From what I can see at a first glance are 2 problems:
 
a) you have set your network to use IPV4+IPV6, but you do not have any V6 router in your LAN. Although this is not a real error, you can save some time of wasted tries by disabling V6 completely in you network settings
 
a) the machine tries to send you error messages but fails miserably because you have entered the wrong credentials for your google mail accout. Without these messages it is hard to guess what is going wrong.
 
c) one of your disks has bad sectors:
Oct  9 22:06:38 Tower kernel: ata4.00: exception Emask 0x50 SAct 0x0 SErr 0x280900 action 0x6 frozen
Oct  9 22:06:38 Tower kernel: ata4.00: irq_stat 0x08000000, interface fatal error
Oct  9 22:06:38 Tower kernel: ata4: SError: { UnrecovData HostInt 10B8B BadCRC }
Oct  9 22:06:38 Tower kernel: ata4.00: failed command: READ DMA
Oct  9 22:06:38 Tower kernel: ata4.00: cmd c8/00:78:c8:00:00/00:00:00:00:00/e0 tag 7 dma 61440 in
Oct  9 22:06:38 Tower kernel:         res 50/00:00:b7:00:00/00:00:00:00:00/e0 Emask 0x50 (ATA bus error)
Oct  9 22:06:38 Tower kernel: ata4.00: status: { DRDY }
Oct  9 22:06:38 Tower kernel: ata4: hard resetting link
Oct  9 22:06:38 Tower kernel: ata4: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Oct  9 22:06:38 Tower kernel: ata4.00: configured for UDMA/133
Oct  9 22:06:38 Tower kernel: ata4: EH complete
Oct  9 22:06:39 Tower kernel: ata4.00: exception Emask 0x50 SAct 0x0 SErr 0x280900 action 0x6 frozen
Oct  9 22:06:39 Tower kernel: ata4.00: irq_stat 0x08000000, interface fatal error
Oct  9 22:06:39 Tower kernel: ata4: SError: { UnrecovData HostInt 10B8B BadCRC }
Oct  9 22:06:39 Tower kernel: ata4.00: failed command: READ DMA
Oct  9 22:06:39 Tower kernel: ata4.00: cmd c8/00:f8:48:03:00/00:00:00:00:00/e0 tag 10 dma 126976 in
Oct  9 22:06:39 Tower kernel:         res 50/00:00:47:03:00/00:00:00:00:00/e0 Emask 0x50 (ATA bus error)
Oct  9 22:06:39 Tower kernel: ata4.00: status: { DRDY }
Oct  9 22:06:39 Tower kernel: ata4: hard resetting link
Oct  9 22:06:39 Tower kernel: ata4: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Oct  9 22:06:39 Tower kernel: ata4.00: configured for UDMA/133
Oct  9 22:06:39 Tower kernel: ata4: EH complete
 
when read, machine stops, resets drive and retries. if this happens during playback, it will surely stop
The question is if this  is a real bad sector or just a loose/bad cable. Anyway, it will slow down anything for a while (I guess ~10s or so)
This happens quite often and afterwards the box tries to do a filesystem recovery (which will halt the playback for a much longer time)
So at the end, it is only trying to fix your broken disk and does not serve data anymore...
 
Watch the cabling and check the drives.
 
 

aahhh, from your diagnostics i see that you do more or less russian roulette.
You have set your 1G card to use dhcp, your 10G card to use a static address. 
So far, so good, but they are both connected to the same lan and get (dhcp) an address from the same subnet!
So what you have is a host with 2 seperate addresses within the same net.
 
This is not a general error, but it grants the clients to pick one of the cards randomly. So one may favour the 1G the other one may use the 10G for a while (and switch back somewhat later).
 
I cannot think that this is the behaviour that you have in mind?
 
Pull out the cable of the 1G and use the 10G only! (configure UNRAID to switch the cards and then deactivate eth1).
 
Theroreitcally you could put both cards into a bond, but thats stupid too. Again it is not predictable then which one is used, so you may realize the same strange behaviour as you have now. (never put members with different speeds into a bond (unless it is a backup only bond))
 
 
 

AAAARRGGGGHH! woke up this morning, started the machines, rechecked the bug: GONE! 😞
Now even the formerly not working workstations can flawlessly connect to 6.11.
Besides sleeping I have not done or changed anything!
Just 2 days of waiting and testing.
(and maybe deleting some old GPOs, but obviously it took very long for them to produce a visible change)
 
Just did a recapture and now the marked fields are all zero too in the login packet.
Both private and public shares work from either wks I have tested this morning already.
Maybe I should give the update another chance???
 
GEEE, I DO HATE THESE BUGS THAT COME OUT OF NOWHERE AND VANISH THE SAME WAY A FEW DAYS LATER!
Still no clue what happened and why...

lösch mal deinen Browsercache und versuchs nochmal.

public is a bit critical, sometimes it works, often not.
And, of course, do not forget to assign read/write permissions to the share.
Also your printer may need a different syntax for the "URL". Its not a http url, but a smb (cifs) share! Maybe you need to prepend it with something like "smb://192.168.x.x" ?
(Or you need to supply it in a completely different part of the printer setup, my printer has different sections for different protocols)
 
If it still does not work, try to make the share private and create a user that is capable to write to the share. Configure the same workgroup/username/password into the printer and retry.
 
Here it works without any hassle (but I have Kyocera printer, maybe OKI behaves different, no idea).
 

depending on the used version and your hardware, it might seriously kill your sata connections now and then.
It programs the SATA port to "auto" power saving which does not really work reliable on many controllers. Symptoms are loss of contact, unstable data transmission, degregation in link speed (like you are currently suffering from).
It saves little, but can cause a lot of grief.
 

some more improvements led to this result:

Turned off SMB Multichannel support and AIO
(transfer speed was doubled again, now it uses ~280Mb/s, the maximum the target drive can handle)
 
(all Screens show the same usage, permanent copy of huge files over lan with robocopy as the receiver)
 

as long as eth1 is in the bonding list of eth0, no local setting is applied. its just a clone of eth0
(the gui could be a bit more helpful by disabling all these entries)
But, as I said above, things may change if you start the eth1 interface by hitting the "Port up" button (no cable needed for this!)
 

OOh, just "back to back". Then it might be helpfull to you to turn off "flow control" within the lan cards. It MIGHT happen, that one card issues a "please stop!" frame, and then gets turned off. Coming back on may find a still blocked partner and because the rebooted one does not send a "please continue!" frame, it is locked until the cows come home.
Just give it a try, its a useless feature anyway if only two machines are in the net.